linux-stable.git/include/linux, branch v4.1.50

x86/retpoline: Avoid retpolines for built-in __init functions

2018-03-04T15:28:33+00:00

[ Upstream commit 66f793099a636862a71c59d4a6ba91387b155e0c ]

There's no point in building init code with retpolines, since it runs before
any potentially hostile userspace does. And before the retpoline is actually
ALTERNATIVEd into place, for much of it.

Signed-off-by: David Woodhouse 
Signed-off-by: Thomas Gleixner 
Cc: karahmed@amazon.de
Cc: peterz@infradead.org
Cc: bp@alien8.de
Link: https://lkml.kernel.org/r/1517484441-1420-2-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Sasha Levin

vfs, fdtable: Prevent bounds-check bypass via speculative execution

2018-03-04T15:28:33+00:00

[ Upstream commit 56c30ba7b348b90484969054d561f711ba196507 ]

'fd' is a user controlled value that is used as a data dependency to
read from the 'fdt->fd' array.  In order to avoid potential leaks of
kernel memory values, block speculative execution of the instruction
stream that could issue reads based on an invalid 'file *' returned from
__fcheck_files.

Co-developed-by: Elena Reshetova 
Signed-off-by: Dan Williams 
Signed-off-by: Thomas Gleixner 
Cc: linux-arch@vger.kernel.org
Cc: kernel-hardening@lists.openwall.com
Cc: gregkh@linuxfoundation.org
Cc: Al Viro 
Cc: torvalds@linux-foundation.org
Cc: alan@linux.intel.com
Link: https://lkml.kernel.org/r/151727418500.33451.17392199002892248656.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Sasha Levin

array_index_nospec: Sanitize speculative array de-references

2018-03-04T15:28:33+00:00

[ Upstream commit f3804203306e098dae9ca51540fcd5eb700d7f40 ]

array_index_nospec() is proposed as a generic mechanism to mitigate
against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary
checks via speculative execution. The array_index_nospec()
implementation is expected to be safe for current generation CPUs across
multiple architectures (ARM, x86).

Based on an original implementation by Linus Torvalds, tweaked to remove
speculative flows by Alexei Starovoitov, and tweaked again by Linus to
introduce an x86 assembly implementation for the mask generation.

Co-developed-by: Linus Torvalds 
Co-developed-by: Alexei Starovoitov 
Suggested-by: Cyril Novikov 
Signed-off-by: Dan Williams 
Signed-off-by: Thomas Gleixner 
Cc: linux-arch@vger.kernel.org
Cc: kernel-hardening@lists.openwall.com
Cc: Peter Zijlstra 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Russell King 
Cc: gregkh@linuxfoundation.org
Cc: torvalds@linux-foundation.org
Cc: alan@linux.intel.com
Link: https://lkml.kernel.org/r/151727414229.33451.18411580953862676575.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Sasha Levin

mtd: sh_flctl: pass FIFO as physical address

2018-03-04T15:28:30+00:00

[ Upstream commit 1873315fb156cbc8e46f28e8b128f17ff6c31728 ]

By convention, the FIFO address we pass using dmaengine_slave_config
is a physical address in the form that is understood by the DMA
engine, as a dma_addr_t, phys_addr_t or resource_size_t.

The sh_flctl driver however passes a virtual __iomem address that
gets cast to dma_addr_t in the slave driver. This happens to work
on shmobile because that platform sets up an identity mapping for
its MMIO regions, but such code is not portable to other platforms,
and prevents us from ever changing the platform mapping or reusing
the driver on other architectures like ARM64 that might not have the
mapping.

We also get a warning about a type mismatch for the case that
dma_addr_t is wider than a pointer, i.e. when CONFIG_LPAE is set:

drivers/mtd/nand/sh_flctl.c: In function 'flctl_setup_dma':
drivers/mtd/nand/sh_flctl.c:163:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl);

This changes the driver to instead pass the physical address of
the FIFO that is extracted from the MMIO resource, making the
code more portable and avoiding the warning.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Brian Norris 
Signed-off-by: Sasha Levin

driver-core: use 'dev' argument in dev_dbg_ratelimited stub

2018-03-04T15:28:30+00:00

[ Upstream commit 1f62ff34a90471d1b735bac2c79e894afc7c59bc ]

dev_dbg_ratelimited() is a macro that ignores its first argument when DEBUG is
not set, which can lead to unused variable warnings:

ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cqe_sdq_handle':
ethernet/mellanox/mlxsw/pci.c:646:18: warning: unused variable 'pdev' [-Wunused-variable]
ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cqe_rdq_handle':
ethernet/mellanox/mlxsw/pci.c:671:18: warning: unused variable 'pdev' [-Wunused-variable]

The macro already ensures that all its other arguments are silently
ignored by the compiler without triggering a warning, through the
use of the no_printk() macro, but the dev argument is not passed into
that.

This changes the definition to use the same trick as no_printk() with
an if(0) that leads the compiler to not evaluate the side-effects but
still see that 'dev' might not be unused.

Signed-off-by: Arnd Bergmann 
Suggested-by: Andrew Lunn 
Fixes: 6f586e663e3b ("driver-core: Shut up dev_dbg_reatelimited() without DEBUG")
Reviewed-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Provide a function to create a NUL-terminated string from unterminated data

2018-03-04T15:28:24+00:00

[ Upstream commit f35157417215ec138c920320c746fdb3e04ef1d5 ]

Provide a function, kmemdup_nul(), that will create a NUL-terminated string
from an unterminated character array where the length is known in advance.

This is better than kstrndup() in situations where we already know the
string length as the strnlen() in kstrndup() is superfluous.

Signed-off-by: David Howells 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

mtd: cfi: convert inline functions to macros

2018-03-01T03:09:51+00:00

[ Upstream commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 ]

The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.

This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes.  Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.

With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.

It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann 
Acked-by: Richard Weinberger 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin

tcp: __tcp_hdrlen() helper

2018-03-01T03:09:43+00:00

[ Upstream commit d9b3fca27385eafe61c3ca6feab6cb1e7dc77482 ]

tcp_hdrlen is wasteful if you already have a pointer to struct tcphdr.
This splits the size calculation into a helper function that can be
used if a struct tcphdr is already available.

Signed-off-by: Craig Gallek 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

Revert "module: Add retpoline tag to VERMAGIC"

2018-03-01T03:09:42+00:00

[ Upstream commit 5132ede0fe8092b043dae09a7cc32b8ae7272baa ]

This reverts commit 6cfb521ac0d5b97470883ff9b7facae264b7ab12.

Turns out distros do not want to make retpoline as part of their "ABI",
so this patch should not have been merged.  Sorry Andi, this was my
fault, I suggested it when your original patch was the "correct" way of
doing this instead.

Reported-by: Jiri Kosina 
Fixes: 6cfb521ac0d5 ("module: Add retpoline tag to VERMAGIC")
Acked-by: Andi Kleen 
Cc: Thomas Gleixner 
Cc: David Woodhouse 
Cc: rusty@rustcorp.com.au
Cc: arjan.van.de.ven@intel.com
Cc: jeyu@kernel.org
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled

2018-03-01T03:09:41+00:00

[ Upstream commit fac51482577d5e05bbb0efa8d602a3c2111098bf ]

With CONFIG_OF enabled on x86, we get the following error on boot:
"
	Failed to find cpu0 device node
 	Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.

In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.

This patch also sets that boolean for x86.

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin