linux.git/include, branch v3.18.128

can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb()

2018-12-01T08:47:59+00:00

commit a4310fa2f24687888ce80fdb0e88583561a23700 upstream.

This patch factors out all non sending parts of can_get_echo_skb() into
a seperate function __can_get_echo_skb(), so that it can be re-used in
an upcoming patch.

Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

new helper: uaccess_kernel()

2018-11-27T15:05:38+00:00

commit db68ce10c4f0a27c1ff9fa0e789e5c41f8c4ea63 upstream.

Signed-off-by: Al Viro 
[only take the include/linux/uaccess.h portion - gregkh]
Signed-off-by: Greg Kroah-Hartman

libceph: bump CEPH_MSG_MAX_DATA_LEN

2018-11-22T06:32:46+00:00

commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.

If the read is large enough, we end up spinning in the messenger:

  libceph: osd0 192.168.122.1:6801 io error
  libceph: osd0 192.168.122.1:6801 io error
  libceph: osd0 192.168.122.1:6801 io error

This is a receive side limit, so only reads were affected.

Cc: stable@vger.kernel.org
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

TC: Set DMA masks for devices

2018-11-22T06:32:44+00:00

commit 3f2aa244ee1a0d17ed5b6c86564d2c1b24d1c96b upstream.

Fix a TURBOchannel support regression with commit 205e1b7f51e4
("dma-mapping: warn when there is no coherent_dma_mask") that caused
coherent DMA allocations to produce a warning such as:

defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
tc1: DEFTA at MMIO addr = 0x1e900000, IRQ = 20, Hardware addr = 08-00-2b-a3-a3-29
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dfx_dev_register+0x670/0x678
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
Stack : ffffffff8009ffc0 fffffffffffffec0 0000000000000000 ffffffff80647650
        0000000000000000 0000000000000000 ffffffff806f5f80 ffffffffffffffff
        0000000000000000 0000000000000000 0000000000000001 ffffffff8065d4e8
        98000000031b6300 ffffffff80563478 ffffffff805685b0 ffffffffffffffff
        0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
        0000000000000000 0000000000000009 ffffffff8053efd0 ffffffff806657d0
        0000000000000000 ffffffff803177f8 0000000000000000 ffffffff806d0000
        9800000003078000 980000000307b9e0 000000001e900000 ffffffff80067940
        0000000000000000 ffffffff805d6720 0000000000000204 ffffffff80388df8
        ffffffff805176c0 ffffffff8004dc78 0000000000000000 ffffffff80067940
        ...
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---

This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.

Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol supports a 34-bit (16GiB) DMA address
space, by interpreting the value presented in the address cycle across
the 32 `ad' lines as a 32-bit word rather than byte address[1].  The
architectural size of the TURBOchannel DMA address space exceeds the
maximum amount of RAM any actual TURBOchannel system in existence may
have, hence both masks are the same.

This removes the warning shown above.

References:

[1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital
    Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17

Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/20835/
Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
Cc: stable@vger.kernel.org # 4.16+
Cc: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

unix: correctly track in-flight fds in sending process user_struct

2018-11-10T15:39:21+00:00

[ Upstream commit 415e3d3e90ce9e18727e8843ae343eda5a58fad6 ]

The commit referenced in the Fixes tag incorrectly accounted the number
of in-flight fds over a unix domain socket to the original opener
of the file-descriptor. This allows another process to arbitrary
deplete the original file-openers resource limit for the maximum of
open files. Instead the sending processes and its struct cred should
be credited.

To do so, we add a reference counted struct user_struct pointer to the
scm_fp_list and use it to account for the number of inflight unix fds.

Fixes: 712f4aad406bb1 ("unix: properly account for FDs passed over unix sockets")
Reported-by: David Herrmann 
Cc: David Herrmann 
Cc: Willy Tarreau 
Cc: Linus Torvalds 
Suggested-by: Linus Torvalds 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: fix warnings in 'make htmldocs' by moving macro definition out of field declaration

2018-11-10T15:39:21+00:00

[ Upstream commit 7bbadd2d1009575dad675afc16650ebb5aa10612 ]

Docbook does not like the definition of macros inside a field declaration
and adds a warning. Move the definition out.

Fixes: 79462ad02e86180 ("net: add validation for the socket syscall protocol argument")
Reported-by: kbuild test robot 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

tty: audit: Fix audit source

2018-11-10T15:39:19+00:00

[ Upstream commit 6b2a3d628aa752f0ab825fc6d4d07b09e274d1c1 ]

The data to audit/record is in the 'from' buffer (ie., the input
read buffer).

Fixes: 72586c6061ab ("n_tty: Fix auditing support for cannonical mode")
Cc: stable  # 4.1+
Cc: Miloslav Trmač 
Signed-off-by: Peter Hurley 
Acked-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

lib: make memzero_explicit more robust against dead store elimination

2018-11-10T15:39:19+00:00

[ Upstream commit 7829fb09a2b4268b30dd9bc782fa5ebee278b137 ]

In commit 0b053c951829 ("lib: memzero_explicit: use barrier instead
of OPTIMIZER_HIDE_VAR"), we made memzero_explicit() more robust in
case LTO would decide to inline memzero_explicit() and eventually
find out it could be elimiated as dead store.

While using barrier() works well for the case of gcc, recent efforts
from LLVMLinux people suggest to use llvm as an alternative to gcc,
and there, Stephan found in a simple stand-alone user space example
that llvm could nevertheless optimize and thus elimitate the memset().
A similar issue has been observed in the referenced llvm bug report,
which is regarded as not-a-bug.

Based on some experiments, icc is a bit special on its own, while it
doesn't seem to eliminate the memset(), it could do so with an own
implementation, and then result in similar findings as with llvm.

The fix in this patch now works for all three compilers (also tested
with more aggressive optimization levels). Arguably, in the current
kernel tree it's more of a theoretical issue, but imho, it's better
to be pedantic about it.

It's clearly visible with gcc/llvm though, with the below code: if we
would have used barrier() only here, llvm would have omitted clearing,
not so with barrier_data() variant:

  static inline void memzero_explicit(void *s, size_t count)
  {
    memset(s, 0, count);
    barrier_data(s);
  }

  int main(void)
  {
    char buff[20];
    memzero_explicit(buff, sizeof(buff));
    return 0;
  }

  $ gcc -O2 test.c
  $ gdb a.out
  (gdb) disassemble main
  Dump of assembler code for function main:
   0x0000000000400400  <+0>: lea   -0x28(%rsp),%rax
   0x0000000000400405  <+5>: movq  $0x0,-0x28(%rsp)
   0x000000000040040e <+14>: movq  $0x0,-0x20(%rsp)
   0x0000000000400417 <+23>: movl  $0x0,-0x18(%rsp)
   0x000000000040041f <+31>: xor   %eax,%eax
   0x0000000000400421 <+33>: retq
  End of assembler dump.

  $ clang -O2 test.c
  $ gdb a.out
  (gdb) disassemble main
  Dump of assembler code for function main:
   0x00000000004004f0  <+0>: xorps  %xmm0,%xmm0
   0x00000000004004f3  <+3>: movaps %xmm0,-0x18(%rsp)
   0x00000000004004f8  <+8>: movl   $0x0,-0x8(%rsp)
   0x0000000000400500 <+16>: lea    -0x18(%rsp),%rax
   0x0000000000400505 <+21>: xor    %eax,%eax
   0x0000000000400507 <+23>: retq
  End of assembler dump.

As gcc, clang, but also icc defines __GNUC__, it's sufficient to define
this in compiler-gcc.h only to be picked up. For a fallback or otherwise
unsupported compiler, we define it as a barrier. Similarly, for ecc which
does not support gcc inline asm.

Reference: https://llvm.org/bugs/show_bug.cgi?id=15495
Reported-by: Stephan Mueller 
Tested-by: Stephan Mueller 
Signed-off-by: Daniel Borkmann 
Cc: Theodore Ts'o 
Cc: Stephan Mueller 
Cc: Hannes Frederic Sowa 
Cc: mancha security 
Cc: Mark Charlebois 
Cc: Behan Webster 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

NFSv4: Cache the NFSv4/v4.1 client owner_id in the struct nfs_client

2018-11-10T15:39:15+00:00

[ Upstream commit ceb3a16c070c403f5f9ca46b46cf2bb79ea11750 ]

Ensure that we cache the NFSv4/v4.1 client owner_id so that we can
verify it when we're doing trunking detection.

Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

phy: phy-ti-pipe3: fix inconsistent enumeration of PCIe gen2 cards

2018-11-10T15:39:14+00:00

[ Upstream commit 0bc09f9cdc589e0b54724096138996a00b19babb ]

Prior to DRA74x silicon rev 1.1, pcie_pcs register bits 8-15 and bits 16-23
were used to configure RC delay count for phy1 and phy2 respectively.
phyid was used as index to distinguish the phys and to configure the delay
values appropriately.

As of DRA74x silicon rev 1.1, pcie_pcs register definition has changed.
Bits 16-23 are used to configure delay values for *both* phy1 and phy2.

Hence phyid is no longer required.

So, drop id field from ti_pipe3 structure and its subsequent references
for configuring pcie_pcs register.

Also, pcie_pcs register now needs to be configured with delay value of 0x96
at bit positions 16-23. See register description of CTRL_CORE_PCIE_PCS in
ARM572x TRM, SPRUHZ6, October 2014, section 18.5.2.2, table 18-1804.

This is needed to ensure Gen2 cards are enumerated consistently.

DRA72x silicon behaves same way as DRA74x rev 1.1 as far as this functionality
is considered.

Test results on DRA74x and DRA72x EVMs:

Before patch
------------
DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to
silicon errata)
DRA74x ES 1.1: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect
programming of register

DRA72x: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect
programming of register

After patch
-----------
DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to
silicon errata)
DRA74x ES 1.1: Gen1 cards work, Gen2 cards work consistently.

DRA72x: Gen1 and Gen2 cards enumerate consistently.

Signed-off-by: Vignesh R 
Signed-off-by: Kishon Vijay Abraham I 

Signed-off-by: Sasha Levin