1. 13 Dec, 2015 40 commits
    • Takashi Sakamoto's avatar
      ALSA: bebob: use correct type for __be32 data · 5fa79e58
      Takashi Sakamoto authored
      commit fef586d5 upstream.
      
      In former commit, metering is supported for BeBoB based models
      customized by M-Audio. The data in transaction is aligned to
      big-endianness, while in the driver code u16 typed variable is assigned
      to the data. This causes sparse warnings.
      
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      bebob_maudio.c:651:31: warning: cast to restricted __be16
      
      This commit fixes this bug by using __be16 variable for the data.
      
      Fixes: 3149ac48('ALSA: bebob: Add support for M-Audio special Firewire series')
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5fa79e58
    • Takashi Sakamoto's avatar
      ALSA: fireworks: use u32 type for be32_to_cpup() macro · a4a98b71
      Takashi Sakamoto authored
      commit 463543ac upstream.
      
      In former commit, snd_efw_command_get_phys_meters() was added to handle
      metering data. The given buffer is used to save transaction result and to
      convert between endianness. But this causes sparse warnings.
      
      fireworks_command.c:269:25: warning: incorrect type in argument 1 (different base types)
      fireworks_command.c:269:25:    expected unsigned int [usertype] *p
      fireworks_command.c:269:25:    got restricted __be32 [usertype] *
      
      This commit fixes this bug.
      
      Fixes: bde8a8f2('ALSA: fireworks: Add transaction and some commands')
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a4a98b71
    • Lukas Wunner's avatar
      drm: Fix return value of drm_framebuffer_init() · 4c632181
      Lukas Wunner authored
      commit 3c67d839 upstream.
      
      In its original version, drm_framebuffer_init() returned a negative int
      if drm_mode_object_get() failed (f453ba04, "DRM: add mode setting
      support").
      
      This was accidentally disabled by commit 4b096ac1 ("drm: revamp
      locking around fb creation/destruction"). Thus, drm_framebuffer_init()
      pretends success if drm_mode_object_get() failed.
      
      Reinstate the original behaviour. Also fix erroneous kernel-doc of
      drm_mode_object_get().
      
      Fixes: 4b096ac1 ("drm: revamp locking around fb creation/
          destruction")
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4c632181
    • Takashi Sakamoto's avatar
      ALSA: fireworks/bebob/oxfw/dice: enable to make as built-in · ef5a14ba
      Takashi Sakamoto authored
      commit df483388 upstream.
      
      When committed to upstream, these four modules had wrong entries for
      Makefile. This forces them to be loadable modules even if they're set
      as built-in.
      
      This commit fixes this bug.
      
      Fixes: b5b04336('ALSA: fireworks: Add skelton for Fireworks based devices')
      Fixes: fd6f4b0d('ALSA: bebob: Add skelton for BeBoB based devices')
      Fixes: 1a4e39c2('ALSA: oxfw: Move to its own directory')
      Fixes: 14ff6a09('ALSA: dice: Move file to its own directory')
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ luis: backported to 3.16:
        - dropped changes to oxfw and dice modules as they do not exist in
          the 3.16 kernel ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ef5a14ba
    • Arnd Bergmann's avatar
      ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode · 56c118a7
      Arnd Bergmann authored
      commit 54c09889 upstream.
      
      The z2 machine calls pxa27x_set_pwrmode() in order to power off
      the machine, but this function gets discarded early at boot because
      it is marked __init, as pointed out by kbuild:
      
      WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode()
      The function z2_power_off() references
      the function __init pxa27x_set_pwrmode().
      This is often because z2_power_off lacks a __init
      annotation or the annotation of pxa27x_set_pwrmode is wrong.
      
      This removes the __init section modifier to fix rebooting and the
      build error.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: ba4a90a6 ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available")
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      56c118a7
    • Roger Quadros's avatar
      hsi: omap_ssi_port: Prevent warning if cawake_gpio is not defined. · ae5595f9
      Roger Quadros authored
      commit e74eba04 upstream.
      
      The error handling path is broken as cawake_gpio was defined as
      unsigned integer causing the following warnings on boards that don't
      use SSI port and so don't have cawake_gpio defined. e.g. beagleboard C4.
      
      [   30.094635] WARNING: CPU: 0 PID: 322 at drivers/gpio/gpiolib.c:86 gpio_to_desc+0xa4/0xb8()
      [   30.103363] invalid GPIO -2
      [   30.106292] Modules linked in: omap_ssi_port(+) cpufreq_dt cfbfillrect cfbimgblt leds_gpio cfbcopyarea thermal_sys led_class hwmon gpio_keys encoder_tfp410 connector_analog_tv connector_dvi omap_hdq snd phy_i
      [   30.145477] CPU: 0 PID: 322 Comm: modprobe Not tainted 4.3.0-rc4-00030-gca978c0-dirty #335
      [   30.154174] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
      [   30.160827] [<c0016ef4>] (unwind_backtrace) from [<c00131f4>] (show_stack+0x10/0x14)
      [   30.168975] [<c00131f4>] (show_stack) from [<c033cf08>] (dump_stack+0x80/0x9c)
      [   30.176635] [<c033cf08>] (dump_stack) from [<c003e920>] (warn_slowpath_common+0x7c/0xb8)
      [   30.185180] [<c003e920>] (warn_slowpath_common) from [<c003e9f0>] (warn_slowpath_fmt+0x30/0x40)
      [   30.194366] [<c003e9f0>] (warn_slowpath_fmt) from [<c0376314>] (gpio_to_desc+0xa4/0xb8)
      [   30.202819] [<c0376314>] (gpio_to_desc) from [<c0376ac8>] (gpio_request_one+0x14/0x11c)
      [   30.211273] [<c0376ac8>] (gpio_request_one) from [<c037370c>] (devm_gpio_request_one+0x3c/0x78)
      [   30.220458] [<c037370c>] (devm_gpio_request_one) from [<bf184210>] (ssi_port_probe+0x118/0x504 [omap_ssi_port])
      [   30.231170] [<bf184210>] (ssi_port_probe [omap_ssi_port]) from [<c03d4cfc>] (platform_drv_probe+0x48/0xa4)
      [   30.241424] [<c03d4cfc>] (platform_drv_probe) from [<c03d3678>] (driver_probe_device+0x1dc/0x2a0)
      [   30.250793] [<c03d3678>] (driver_probe_device) from [<c03d37d0>] (__driver_attach+0x94/0x98)
      [   30.259643] [<c03d37d0>] (__driver_attach) from [<c03d1d60>] (bus_for_each_dev+0x54/0x88)
      [   30.268249] [<c03d1d60>] (bus_for_each_dev) from [<c03d2d50>] (bus_add_driver+0xe8/0x1f8)
      [   30.276916] [<c03d2d50>] (bus_add_driver) from [<c03d4118>] (driver_register+0x78/0xf4)
      [   30.285369] [<c03d4118>] (driver_register) from [<c03d5380>] (__platform_driver_probe+0x34/0xd8)
      [   30.294647] [<c03d5380>] (__platform_driver_probe) from [<c00097e4>] (do_one_initcall+0x80/0x1d8)
      [   30.303985] [<c00097e4>] (do_one_initcall) from [<c011617c>] (do_init_module+0x5c/0x1cc)
      [   30.312561] [<c011617c>] (do_init_module) from [<c00c7a68>] (load_module+0x18c8/0x1f0c)
      [   30.320983] [<c00c7a68>] (load_module) from [<c00c8188>] (SyS_init_module+0xdc/0x150)
      [   30.329223] [<c00c8188>] (SyS_init_module) from [<c000f7e0>] (ret_fast_syscall+0x0/0x1c)
      
      Fixes: b209e047 ("HSI: Introduce OMAP SSI driver")
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ae5595f9
    • Geliang Tang's avatar
      hsi: fix double kfree · 5b42c135
      Geliang Tang authored
      commit f098a045 upstream.
      
      When device_register() fails, kfree() is called in hsi_client_release(),
      hence there is no need to call kfree in err3 again.
      
      Fixes: a2aa2473 ("HSI: Add common DT binding for HSI client devices")
      Signed-off-by: default avatarGeliang Tang <geliangtang@163.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5b42c135
    • Eric Dumazet's avatar
      packet: fix match_fanout_group() · d1011c5c
      Eric Dumazet authored
      commit 161642e2 upstream.
      
      Recent TCP listener patches exposed a prior af_packet bug :
      match_fanout_group() blindly assumes it is always safe
      to cast sk to a packet socket to compare fanout with af_packet_priv
      
      But SYNACK packets can be sent while attached to request_sock, which
      are smaller than a "struct sock".
      
      We can read non existent memory and crash.
      
      Fixes: c0de08d0 ("af_packet: don't emit packet on orig fanout group")
      Fixes: ca6fb065 ("tcp: attach SYNACK messages to request sockets instead of listener")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: Eric Leblond <eric@regit.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d1011c5c
    • Eric W. Biederman's avatar
      ipv4: Fix ip_queue_xmit to pass sk into ip_local_out_sk · 9c84eab0
      Eric W. Biederman authored
      commit 850dcc4d upstream.
      
      After a packet has been encapsulated by a tunnel we should use the
      tunnel sockets local multicast loopback flag to control if the
      encapsulated packet should be locally loopback back.
      
      Pass sk into ip_local_out_sk so that in the rare case we are dealing
      with a tunneled packet whose tunnel destination address is a multicast
      address the kernel properly decides to loopback this packet.
      
      In practice I don't think this matters as ip_queue_xmit is used by
      tcp, l2tp and sctp none of which I am aware of uses ip level
      multicasting as they are all point to point communications protocols.
      Let's fix this before someone uses ip_queue_xmit for a tunnel protocol
      that does use multicast.
      
      Fixes: aad88724 ("ipv4: add a sock pointer to dst->output() path.")
      Fixes: b0270e91 ("ipv4: add a sock pointer to ip_queue_xmit()")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9c84eab0
    • Flavio Leitner's avatar
      netfilter: remove dead code · cce5d4d5
      Flavio Leitner authored
      commit 0647e708 upstream.
      
      Remove __nf_conntrack_find() from headers.
      
      Fixes: dcd93ed4 ("netfilter: nf_conntrack: remove dead code")
      Signed-off-by: default avatarFlavio Leitner <fbl@sysclose.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cce5d4d5
    • Dan Carpenter's avatar
      devres: fix a for loop bounds check · e06124bc
      Dan Carpenter authored
      commit 1f35d04a upstream.
      
      The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
      DEVICE_COUNT_RESOURCE (16).  This bug was found using a static checker.
      It may be that the "if (!(mask & (1 << i)))" check means we never
      actually go past the end of the array in real life.
      
      Fixes: ec04b075 ('iomap: implement pcim_iounmap_regions()')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e06124bc
    • Jonas Gorski's avatar
      usb: ehci-orion: fix probe for !GENERIC_PHY · 33b81c78
      Jonas Gorski authored
      commit db1319e1 upstream.
      
      Commit d445913c ("usb: ehci-orion: add optional PHY support")
      added support for optional phys, but devm_phy_optional_get returns
      -ENOSYS if GENERIC_PHY is not enabled.
      
      This causes probe failures, even when there are no phys specified:
      
      [    1.443365] orion-ehci f1058000.usb: init f1058000.usb fail, -38
      [    1.449403] orion-ehci: probe of f1058000.usb failed with error -38
      
      Similar to dwc3, treat -ENOSYS as no phy.
      
      Fixes: d445913c ("usb: ehci-orion: add optional PHY support")
      Signed-off-by: default avatarJonas Gorski <jogo@openwrt.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      33b81c78
    • Andy Shevchenko's avatar
      dmaengine: dw: convert to __ffs() · b50915b3
      Andy Shevchenko authored
      commit 39416677 upstream.
      
      We replace __fls() by __ffs() since we have to find a *minimum* data width that
      satisfies both source and destination.
      
      While here, rename dwc_fast_fls() to dwc_fast_ffs() which it really is.
      
      Fixes: 4c2d56c5 (dw_dmac: introduce dwc_fast_fls())
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b50915b3
    • Dan Carpenter's avatar
      mwifiex: fix mwifiex_rdeeprom_read() · 9a644012
      Dan Carpenter authored
      commit 1f9c6e1b upstream.
      
      There were several bugs here.
      
      1)  The done label was in the wrong place so we didn't copy any
          information out when there was no command given.
      
      2)  We were using PAGE_SIZE as the size of the buffer instead of
          "PAGE_SIZE - pos".
      
      3)  snprintf() returns the number of characters that would have been
          printed if there were enough space.  If there was not enough space
          (and we had fixed the memory corruption bug #2) then it would result
          in an information leak when we do simple_read_from_buffer().  I've
          changed it to use scnprintf() instead.
      
      I also removed the initialization at the start of the function, because
      I thought it made the code a little more clear.
      
      Fixes: 5e6e3a92 ('wireless: mwifiex: initial commit for Marvell mwifiex driver')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9a644012
    • Valentin Rothberg's avatar
      wm831x_power: Use IRQF_ONESHOT to request threaded IRQs · 95f16380
      Valentin Rothberg authored
      commit 90adf98d upstream.
      
      Since commit 1c6c6952 ("genirq: Reject bogus threaded irq requests")
      threaded IRQs without a primary handler need to be requested with
      IRQF_ONESHOT, otherwise the request will fail.
      
      scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue.
      
      Fixes: b5874f33 ("wm831x_power: Use genirq")
      Signed-off-by: default avatarValentin Rothberg <valentinrothberg@gmail.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      95f16380
    • Johannes Berg's avatar
      mac80211: fix driver RSSI event calculations · 7f886506
      Johannes Berg authored
      commit 8ec6d978 upstream.
      
      The ifmgd->ave_beacon_signal value cannot be taken as is for
      comparisons, it must be divided by since it's represented
      like that for better accuracy of the EWMA calculations. This
      would lead to invalid driver RSSI events. Fix the used value.
      
      Fixes: 615f7b9b ("mac80211: add driver RSSI threshold events")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7f886506
    • Christophe Leroy's avatar
      splice: sendfile() at once fails for big files · 32e87ff7
      Christophe Leroy authored
      commit 0ff28d9f upstream.
      
      Using sendfile with below small program to get MD5 sums of some files,
      it appear that big files (over 64kbytes with 4k pages system) get a
      wrong MD5 sum while small files get the correct sum.
      This program uses sendfile() to send a file to an AF_ALG socket
      for hashing.
      
      /* md5sum2.c */
      
      int main(int argc, char **argv)
      {
      	int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
      	struct stat st;
      	struct sockaddr_alg sa = {
      		.salg_family = AF_ALG,
      		.salg_type = "hash",
      		.salg_name = "md5",
      	};
      	int n;
      
      	bind(sk, (struct sockaddr*)&sa, sizeof(sa));
      
      	for (n = 1; n < argc; n++) {
      		int size;
      		int offset = 0;
      		char buf[4096];
      		int fd;
      		int sko;
      		int i;
      
      		fd = open(argv[n], O_RDONLY);
      		sko = accept(sk, NULL, 0);
      		fstat(fd, &st);
      		size = st.st_size;
      		sendfile(sko, fd, &offset, size);
      		size = read(sko, buf, sizeof(buf));
      		for (i = 0; i < size; i++)
      			printf("%2.2x", buf[i]);
      		printf("  %s\n", argv[n]);
      		close(fd);
      		close(sko);
      	}
      	exit(0);
      }
      
      Test below is done using official linux patch files. First result is
      with a software based md5sum. Second result is with the program above.
      
      root@vgoip:~# ls -l patch-3.6.*
      -rw-r--r--    1 root     root         64011 Aug 24 12:01 patch-3.6.2.gz
      -rw-r--r--    1 root     root         94131 Aug 24 12:01 patch-3.6.3.gz
      
      root@vgoip:~# md5sum patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
      
      root@vgoip:~# ./md5sum2 patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      5fd77b24e68bb24dcc72d6e57c64790e  patch-3.6.3.gz
      
      After investivation, it appears that sendfile() sends the files by blocks
      of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
      block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
      is reset as if it was the end of the file.
      
      This patch adds SPLICE_F_MORE to the flags when more data is pending.
      
      With the patch applied, we get the correct sums:
      
      root@vgoip:~# md5sum patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
      
      root@vgoip:~# ./md5sum2 patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      32e87ff7
    • Eric Biggers's avatar
      fs/pipe.c: return error code rather than 0 in pipe_write() · 1b29f8bd
      Eric Biggers authored
      commit 6ae08069 upstream.
      
      pipe_write() would return 0 if it failed to merge the beginning of the
      data to write with the last, partially filled pipe buffer.  It should
      return an error code instead.  Userspace programs could be confused by
      write() returning 0 when called with a nonzero 'count'.
      
      The EFAULT error case was a regression from f0d1bec9 ("new helper:
      copy_page_from_iter()"), while the ops->confirm() error case was a much
      older bug.
      
      Test program:
      
      	#include <assert.h>
      	#include <errno.h>
      	#include <unistd.h>
      
      	int main(void)
      	{
      		int fd[2];
      		char data[1] = {0};
      
      		assert(0 == pipe(fd));
      		assert(1 == write(fd[1], data, 1));
      
      		/* prior to this patch, write() returned 0 here  */
      		assert(-1 == write(fd[1], NULL, 1));
      		assert(errno == EFAULT);
      	}
      Signed-off-by: default avatarEric Biggers <ebiggers3@gmail.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1b29f8bd
    • Maciej W. Rozycki's avatar
      binfmt_elf: Don't clobber passed executable's file header · 091bb329
      Maciej W. Rozycki authored
      commit b582ef5c upstream.
      
      Do not clobber the buffer space passed from `search_binary_handler' and
      originally preloaded by `prepare_binprm' with the executable's file
      header by overwriting it with its interpreter's file header.  Instead
      keep the buffer space intact and directly use the data structure locally
      allocated for the interpreter's file header, fixing a bug introduced in
      2.1.14 with loadable module support (linux-mips.org commit beb11695
      [Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
      Adjust the amount of data read from the interpreter's file accordingly.
      
      This was not an issue before loadable module support, because back then
      `load_elf_binary' was executed only once for a given ELF executable,
      whether the function succeeded or failed.
      
      With loadable module support supported and enabled, upon a failure of
      `load_elf_binary' -- which may for example be caused by architecture
      code rejecting an executable due to a missing hardware feature requested
      in the file header -- a module load is attempted and then the function
      reexecuted by `search_binary_handler'.  With the executable's file
      header replaced with its interpreter's file header the executable can
      then be erroneously accepted in this subsequent attempt.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      091bb329
    • Kinglong Mee's avatar
      FS-Cache: Don't override netfs's primary_index if registering failed · 6c308044
      Kinglong Mee authored
      commit b130ed59 upstream.
      
      Only override netfs->primary_index when registering success.
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6c308044
    • Kinglong Mee's avatar
      FS-Cache: Increase reference of parent after registering, netfs success · dfee8e3b
      Kinglong Mee authored
      commit 86108c2e upstream.
      
      If netfs exist, fscache should not increase the reference of parent's
      usage and n_children, otherwise, never be decreased.
      
      v2: thanks David's suggest,
       move increasing reference of parent if success
       use kmem_cache_free() freeing primary_index directly
      
      v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;"
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      dfee8e3b
    • Egbert Eich's avatar
      drm/ast: Initialized data needed to map fbdev memory · 479b601b
      Egbert Eich authored
      commit 28fb4cb7 upstream.
      
      Due to a missing initialization there was no way to map fbdev memory.
      Thus for example using the Xserver with the fbdev driver failed.
      This fix adds initialization for fix.smem_start and fix.smem_len
      in the fb_info structure, which fixes this problem.
      Requested-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarEgbert Eich <eich@suse.de>
      [pulled from SuSE tree by me - airlied]
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      479b601b
    • Jason Liu's avatar
      drivers: of: of_reserved_mem: fixup the alignment with CMA setup · 5b7bf79a
      Jason Liu authored
      commit 1cc8e345 upstream.
      
      There is an alignment mismatch issue between the of_reserved_mem and
      the CMA setup requirement. The of_reserved_mem will try to get the
      alignment value from the DTS and pass it to __memblock_alloc_base to
      do the memory block base allocation, but the alignment value specified
      in the DTS may not satisfy the CAM setup requirement since CMA setup
      required the alignment as the following in the code:
      
      align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
      
      The sanity check in the function of rmem_cma_setup will fail if the
      alignment does not setup correctly and thus CMA will fail to setup.
      
      This patch is to fixup the alignment to meet the CMA setup required.
      
      Mailing-list-thread: https://lkml.org/lkml/2015/11/9/138Signed-off-by: default avatarJason Liu <r64343@freescale.com>
      Acked-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5b7bf79a
    • Paolo Bonzini's avatar
      KVM: svm: unconditionally intercept #DB · 13961a17
      Paolo Bonzini authored
      commit cbdb967a upstream.
      
      This is needed to avoid the possibility that the guest triggers
      an infinite stream of #DB exceptions (CVE-2015-8104).
      
      VMX is not affected: because it does not save DR6 in the VMCS,
      it already intercepts #DB unconditionally.
      Reported-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      13961a17
    • Eric Northup's avatar
      KVM: x86: work around infinite loop in microcode when #AC is delivered · 033edc3a
      Eric Northup authored
      commit 54a20552 upstream.
      
      It was found that a guest can DoS a host by triggering an infinite
      stream of "alignment check" (#AC) exceptions.  This causes the
      microcode to enter an infinite loop where the core never receives
      another interrupt.  The host kernel panics pretty quickly due to the
      effects (CVE-2015-5307).
      Signed-off-by: default avatarEric Northup <digitaleric@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      033edc3a
    • Nadav Amit's avatar
      KVM: x86: Defining missing x86 vectors · 428a49dd
      Nadav Amit authored
      commit c9cdd085 upstream.
      
      Defining XE, XM and VE vector numbers.
      Signed-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      428a49dd
    • K. Y. Srinivasan's avatar
      storvsc: Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag · 06f7484b
      K. Y. Srinivasan authored
      commit 8cf308e1 upstream.
      
      Don't set the SRB_FLAGS_QUEUE_ACTION_ENABLE flag since we are not specifying
      tags.  Without this, the qlogic driver doesn't work properly with storvsc.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      06f7484b
    • Hans de Goede's avatar
      ideapad-laptop: Add Lenovo Yoga 900 to no_hw_rfkill dmi list · 32592e53
      Hans de Goede authored
      commit f71c882d upstream.
      
      Like some of the other Yoga models the Lenovo Yoga 900 does not have a
      hw rfkill switch, and trying to read the hw rfkill switch through the
      ideapad module causes it to always reported blocking breaking wifi.
      
      This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing
      the wifi breakage.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490Reported-and-tested-by: default avatarKevin Fenzi <kevin@scrye.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      32592e53
    • Filipe Manana's avatar
      Btrfs: fix race when listing an inode's xattrs · 2a907a29
      Filipe Manana authored
      commit f1cd1f0b upstream.
      
      When listing a inode's xattrs we have a time window where we race against
      a concurrent operation for adding a new hard link for our inode that makes
      us not return any xattr to user space. In order for this to happen, the
      first xattr of our inode needs to be at slot 0 of a leaf and the previous
      leaf must still have room for an inode ref (or extref) item, and this can
      happen because an inode's listxattrs callback does not lock the inode's
      i_mutex (nor does the VFS does it for us), but adding a hard link to an
      inode makes the VFS lock the inode's i_mutex before calling the inode's
      link callback.
      
      If we have the following leafs:
      
                     Leaf X (has N items)                    Leaf Y
      
       [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 XATTR_ITEM 12345), ... ]
                 slot N - 2         slot N - 1              slot 0
      
      The race illustrated by the following sequence diagram is possible:
      
             CPU 1                                               CPU 2
      
        btrfs_listxattr()
      
          searches for key (257 XATTR_ITEM 0)
      
          gets path with path->nodes[0] == leaf X
          and path->slots[0] == N
      
          because path->slots[0] is >=
          btrfs_header_nritems(leaf X), it calls
          btrfs_next_leaf()
      
          btrfs_next_leaf()
            releases the path
      
                                                         adds key (257 INODE_REF 666)
                                                         to the end of leaf X (slot N),
                                                         and leaf X now has N + 1 items
      
            searches for the key (257 INODE_REF 256),
            with path->keep_locks == 1, because that
            is the last key it saw in leaf X before
            releasing the path
      
            ends up at leaf X again and it verifies
            that the key (257 INODE_REF 256) is no
            longer the last key in leaf X, so it
            returns with path->nodes[0] == leaf X
            and path->slots[0] == N, pointing to
            the new item with key (257 INODE_REF 666)
      
          btrfs_listxattr's loop iteration sees that
          the type of the key pointed by the path is
          different from the type BTRFS_XATTR_ITEM_KEY
          and so it breaks the loop and stops looking
          for more xattr items
            --> the application doesn't get any xattr
                listed for our inode
      
      So fix this by breaking the loop only if the key's type is greater than
      BTRFS_XATTR_ITEM_KEY and skip the current key if its type is smaller.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      [ luis: backported to 3.16:
        - drop btrfs_key_type(), which was dropped upstream by
          962a298f ("btrfs: kill the key type accessor helpers") ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2a907a29
    • Peter Oberparleiter's avatar
      scsi_sysfs: Fix queue_ramp_up_period return code · 8fc658bb
      Peter Oberparleiter authored
      commit 863e02d0 upstream.
      
      Writing a number to /sys/bus/scsi/devices/<sdev>/queue_ramp_up_period
      returns the value of that number instead of the number of bytes written.
      This behavior can confuse programs expecting POSIX write() semantics.
      Fix this by returning the number of bytes written instead.
      Signed-off-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8fc658bb
    • Peter Zijlstra's avatar
      perf: Fix inherited events vs. tracepoint filters · f7fc5a0c
      Peter Zijlstra authored
      commit b71b437e upstream.
      
      Arnaldo reported that tracepoint filters seem to misbehave (ie. not
      apply) on inherited events.
      
      The fix is obvious; filters are only set on the actual (parent)
      event, use the normal pattern of using this parent event for filters.
      This is safe because each child event has a reference to it.
      Reported-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20151102095051.GN17308@twins.programming.kicks-ass.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f7fc5a0c
    • Filipe Manana's avatar
      Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow · 4e7e67fb
      Filipe Manana authored
      commit 1d512cb7 upstream.
      
      If we are using the NO_HOLES feature, we have a tiny time window when
      running delalloc for a nodatacow inode where we can race with a concurrent
      link or xattr add operation leading to a BUG_ON.
      
      This happens because at run_delalloc_nocow() we end up casting a leaf item
      of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a
      file extent item (struct btrfs_file_extent_item) and then analyse its
      extent type field, which won't match any of the expected extent types
      (values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an
      explicit BUG_ON(1).
      
      The following sequence diagram shows how the race happens when running a
      no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following
      neighbour leafs:
      
                   Leaf X (has N items)                    Leaf Y
      
       [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
                    slot N - 2         slot N - 1              slot 0
      
       (Note the implicit hole for inode 257 regarding the [0, 8K[ range)
      
             CPU 1                                         CPU 2
      
       run_dealloc_nocow()
         btrfs_lookup_file_extent()
           --> searches for a key with value
               (257 EXTENT_DATA 4096) in the
               fs/subvol tree
           --> returns us a path with
               path->nodes[0] == leaf X and
               path->slots[0] == N
      
         because path->slots[0] is >=
         btrfs_header_nritems(leaf X), it
         calls btrfs_next_leaf()
      
         btrfs_next_leaf()
           --> releases the path
      
                                                    hard link added to our inode,
                                                    with key (257 INODE_REF 500)
                                                    added to the end of leaf X,
                                                    so leaf X now has N + 1 keys
      
           --> searches for the key
               (257 INODE_REF 256), because
               it was the last key in leaf X
               before it released the path,
               with path->keep_locks set to 1
      
           --> ends up at leaf X again and
               it verifies that the key
               (257 INODE_REF 256) is no longer
               the last key in the leaf, so it
               returns with path->nodes[0] ==
               leaf X and path->slots[0] == N,
               pointing to the new item with
               key (257 INODE_REF 500)
      
         the loop iteration of run_dealloc_nocow()
         does not break out the loop and continues
         because the key referenced in the path
         at path->nodes[0] and path->slots[0] is
         for inode 257, its type is < BTRFS_EXTENT_DATA_KEY
         and its offset (500) is less then our delalloc
         range's end (8192)
      
         the item pointed by the path, an inode reference item,
         is (incorrectly) interpreted as a file extent item and
         we get an invalid extent type, leading to the BUG_ON(1):
      
         if (extent_type == BTRFS_FILE_EXTENT_REG ||
            extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
             (...)
         } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
             (...)
         } else {
             BUG_ON(1)
         }
      
      The same can happen if a xattr is added concurrently and ends up having
      a key with an offset smaller then the delalloc's range end.
      
      So fix this by skipping keys with a type smaller than
      BTRFS_EXTENT_DATA_KEY.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4e7e67fb
    • Filipe Manana's avatar
      Btrfs: fix race leading to incorrect item deletion when dropping extents · 6128a5a6
      Filipe Manana authored
      commit aeafbf84 upstream.
      
      While running a stress test I got the following warning triggered:
      
        [191627.672810] ------------[ cut here ]------------
        [191627.673949] WARNING: CPU: 8 PID: 8447 at fs/btrfs/file.c:779 __btrfs_drop_extents+0x391/0xa50 [btrfs]()
        (...)
        [191627.701485] Call Trace:
        [191627.702037]  [<ffffffff8145f077>] dump_stack+0x4f/0x7b
        [191627.702992]  [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
        [191627.704091]  [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
        [191627.705380]  [<ffffffffa0664499>] ? __btrfs_drop_extents+0x391/0xa50 [btrfs]
        [191627.706637]  [<ffffffff8104b46d>] warn_slowpath_null+0x1a/0x1c
        [191627.707789]  [<ffffffffa0664499>] __btrfs_drop_extents+0x391/0xa50 [btrfs]
        [191627.709155]  [<ffffffff8115663c>] ? cache_alloc_debugcheck_after.isra.32+0x171/0x1d0
        [191627.712444]  [<ffffffff81155007>] ? kmemleak_alloc_recursive.constprop.40+0x16/0x18
        [191627.714162]  [<ffffffffa06570c9>] insert_reserved_file_extent.constprop.40+0x83/0x24e [btrfs]
        [191627.715887]  [<ffffffffa065422b>] ? start_transaction+0x3bb/0x610 [btrfs]
        [191627.717287]  [<ffffffffa065b604>] btrfs_finish_ordered_io+0x273/0x4e2 [btrfs]
        [191627.728865]  [<ffffffffa065b888>] finish_ordered_fn+0x15/0x17 [btrfs]
        [191627.730045]  [<ffffffffa067d688>] normal_work_helper+0x14c/0x32c [btrfs]
        [191627.731256]  [<ffffffffa067d96a>] btrfs_endio_write_helper+0x12/0x14 [btrfs]
        [191627.732661]  [<ffffffff81061119>] process_one_work+0x24c/0x4ae
        [191627.733822]  [<ffffffff810615b0>] worker_thread+0x206/0x2c2
        [191627.734857]  [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
        [191627.736052]  [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
        [191627.737349]  [<ffffffff810669a6>] kthread+0xef/0xf7
        [191627.738267]  [<ffffffff810f3b3a>] ? time_hardirqs_on+0x15/0x28
        [191627.739330]  [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
        [191627.741976]  [<ffffffff81465592>] ret_from_fork+0x42/0x70
        [191627.743080]  [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
        [191627.744206] ---[ end trace bbfddacb7aaada8d ]---
      
        $ cat -n fs/btrfs/file.c
        691  int __btrfs_drop_extents(struct btrfs_trans_handle *trans,
        (...)
        758                  btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
        759                  if (key.objectid > ino ||
        760                      key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
        761                          break;
        762
        763                  fi = btrfs_item_ptr(leaf, path->slots[0],
        764                                      struct btrfs_file_extent_item);
        765                  extent_type = btrfs_file_extent_type(leaf, fi);
        766
        767                  if (extent_type == BTRFS_FILE_EXTENT_REG ||
        768                      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
        (...)
        774                  } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
        (...)
        778                  } else {
        779                          WARN_ON(1);
        780                          extent_end = search_start;
        781                  }
        (...)
      
      This happened because the item we were processing did not match a file
      extent item (its key type != BTRFS_EXTENT_DATA_KEY), and even on this
      case we cast the item to a struct btrfs_file_extent_item pointer and
      then find a type field value that does not match any of the expected
      values (BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]). This scenario happens
      due to a tiny time window where a race can happen as exemplified below.
      For example, consider the following scenario where we're using the
      NO_HOLES feature and we have the following two neighbour leafs:
      
                     Leaf X (has N items)                    Leaf Y
      
      [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
                slot N - 2         slot N - 1              slot 0
      
      Our inode 257 has an implicit hole in the range [0, 8K[ (implicit rather
      than explicit because NO_HOLES is enabled). Now if our inode has an
      ordered extent for the range [4K, 8K[ that is finishing, the following
      can happen:
      
                CPU 1                                       CPU 2
      
        btrfs_finish_ordered_io()
          insert_reserved_file_extent()
            __btrfs_drop_extents()
               Searches for the key
                (257 EXTENT_DATA 4096) through
                btrfs_lookup_file_extent()
      
               Key not found and we get a path where
               path->nodes[0] == leaf X and
               path->slots[0] == N
      
               Because path->slots[0] is >=
               btrfs_header_nritems(leaf X), we call
               btrfs_next_leaf()
      
               btrfs_next_leaf() releases the path
      
                                                        inserts key
                                                        (257 INODE_REF 4096)
                                                        at the end of leaf X,
                                                        leaf X now has N + 1 keys,
                                                        and the new key is at
                                                        slot N
      
               btrfs_next_leaf() searches for
               key (257 INODE_REF 256), with
               path->keep_locks set to 1,
               because it was the last key it
               saw in leaf X
      
                 finds it in leaf X again and
                 notices it's no longer the last
                 key of the leaf, so it returns 0
                 with path->nodes[0] == leaf X and
                 path->slots[0] == N (which is now
                 < btrfs_header_nritems(leaf X)),
                 pointing to the new key
                 (257 INODE_REF 4096)
      
               __btrfs_drop_extents() casts the
               item at path->nodes[0], slot
               path->slots[0], to a struct
               btrfs_file_extent_item - it does
               not skip keys for the target
               inode with a type less than
               BTRFS_EXTENT_DATA_KEY
               (BTRFS_INODE_REF_KEY < BTRFS_EXTENT_DATA_KEY)
      
               sees a bogus value for the type
               field triggering the WARN_ON in
               the trace shown above, and sets
               extent_end = search_start (4096)
      
               does the if-then-else logic to
               fixup 0 length extent items created
               by a past bug from hole punching:
      
                 if (extent_end == key.offset &&
                     extent_end >= search_start)
                     goto delete_extent_item;
      
               that evaluates to true and it ends
               up deleting the key pointed to by
               path->slots[0], (257 INODE_REF 4096),
               from leaf X
      
      The same could happen for example for a xattr that ends up having a key
      with an offset value that matches search_start (very unlikely but not
      impossible).
      
      So fix this by ensuring that keys smaller than BTRFS_EXTENT_DATA_KEY are
      skipped, never casted to struct btrfs_file_extent_item and never deleted
      by accident. Also protect against the unexpected case of getting a key
      for a lower inode number by skipping that key and issuing a warning.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6128a5a6
    • Borislav Petkov's avatar
      x86/cpu: Call verify_cpu() after having entered long mode too · b80a164b
      Borislav Petkov authored
      commit 04633df0 upstream.
      
      When we get loaded by a 64-bit bootloader, kernel entry point is
      startup_64 in head_64.S. We don't trust any and all bootloaders because
      some will fiddle with CPU configuration so we go ahead and massage each
      CPU into sanity again.
      
      For example, some dell BIOSes have this XD disable feature which set
      IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
      for other OSes but Linux sure doesn't need it.
      
      A similar thing is present in the Surface 3 firmware - see
      https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
      only on the BSP:
      
        # rdmsr -a 0x1a0
        400850089
        850089
        850089
        850089
      
      I know, right?!
      
      There's not even an off switch in there.
      
      So fix all those cases by sanitizing the 64-bit entry point too. For
      that, make verify_cpu() callable in 64-bit mode also.
      Requested-and-debugged-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Reported-and-tested-by: default avatarBastien Nocera <bugzilla@hadess.net>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b80a164b
    • Krzysztof Mazur's avatar
      x86/setup: Fix low identity map for >= 2GB kernel range · e30dbbf3
      Krzysztof Mazur authored
      commit 68accac3 upstream.
      
      The commit f5f3497c extended the low identity mapping. However, if
      the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory
      split), the normal memory mapping is overwritten by the low identity
      mapping causing a crash. To avoid overwritting, limit the low identity
      map to cover only memory before kernel range (PAGE_OFFSET).
      
      Fixes: f5f3497c "x86/setup: Extend low identity map to cover whole kernel range
      Signed-off-by: default avatarKrzysztof Mazur <krzysiek@podlesie.net>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@podlesie.netSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e30dbbf3
    • Paolo Bonzini's avatar
      x86/setup: Extend low identity map to cover whole kernel range · a18887a2
      Paolo Bonzini authored
      commit f5f3497c upstream.
      
      On 32-bit systems, the initial_page_table is reused by
      efi_call_phys_prolog as an identity map to call
      SetVirtualAddressMap.  efi_call_phys_prolog takes care of
      converting the current CPU's GDT to a physical address too.
      
      For PAE kernels the identity mapping is achieved by aliasing the
      first PDPE for the kernel memory mapping into the first PDPE
      of initial_page_table.  This makes the EFI stub's trick "just work".
      
      However, for non-PAE kernels there is no guarantee that the identity
      mapping in the initial_page_table extends as far as the GDT; in this
      case, accesses to the GDT will cause a page fault (which quickly becomes
      a triple fault).  Fix this by copying the kernel mappings from
      swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
      identity mapping.
      
      For some reason, this is only reproducible with QEMU's dynamic translation
      mode, and not for example with KVM.  However, even under KVM one can clearly
      see that the page table is bogus:
      
          $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
          $ gdb
          (gdb) target remote localhost:1234
          (gdb) hb *0x02858f6f
          Hardware assisted breakpoint 1 at 0x2858f6f
          (gdb) c
          Continuing.
      
          Breakpoint 1, 0x02858f6f in ?? ()
          (gdb) monitor info registers
          ...
          GDT=     0724e000 000000ff
          IDT=     fffbb000 000007ff
          CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
          ...
      
      The page directory is sane:
      
          (gdb) x/4wx 0x32b7000
          0x32b7000:	0x03398063	0x03399063	0x0339a063	0x0339b063
          (gdb) x/4wx 0x3398000
          0x3398000:	0x00000163	0x00001163	0x00002163	0x00003163
          (gdb) x/4wx 0x3399000
          0x3399000:	0x00400003	0x00401003	0x00402003	0x00403003
      
      but our particular page directory entry is empty:
      
          (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
          0x32b7070:	0x00000000
      
      [ It appears that you can skate past this issue if you don't receive
        any interrupts while the bogus GDT pointer is loaded, or if you avoid
        reloading the segment registers in general.
      
        Andy Lutomirski provides some additional insight:
      
         "AFAICT it's entirely permissible for the GDTR and/or LDT
          descriptor to point to unmapped memory.  Any attempt to use them
          (segment loads, interrupts, IRET, etc) will try to access that memory
          as if the access came from CPL 0 and, if the access fails, will
          generate a valid page fault with CR2 pointing into the GDT or
          LDT."
      
        Up until commit 23a0d4e8 ("efi: Disable interrupts around EFI
        calls, not in the epilog/prolog calls") interrupts were disabled
        around the prolog and epilog calls, and the functional GDT was
        re-installed before interrupts were re-enabled.
      
        Which explains why no one has hit this issue until now. ]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reported-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      [ Updated changelog. ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a18887a2
    • Oleg Nesterov's avatar
      proc: actually make proc_fd_permission() thread-friendly · 720ae734
      Oleg Nesterov authored
      commit 54708d28 upstream.
      
      The commit 96d0df79 ("proc: make proc_fd_permission() thread-friendly")
      fixed the access to /proc/self/fd from sub-threads, but introduced another
      problem: a sub-thread can't access /proc/<tid>/fd/ or /proc/thread-self/fd
      if generic_permission() fails.
      
      Change proc_fd_permission() to check same_thread_group(pid_task(), current).
      
      Fixes: 96d0df79 ("proc: make proc_fd_permission() thread-friendly")
      Reported-by: default avatar"Jin, Yihua" <yihua.jin@intel.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      720ae734
    • Takashi Iwai's avatar
      Input: elantech - add Fujitsu Lifebook U745 to force crc_enabled · edd540a6
      Takashi Iwai authored
      commit 60603950 upstream.
      
      Another Lifebook machine that needs the same quirk as other similar
      models to make the driver working.
      
      Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=883192Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      edd540a6
    • Catalin Marinas's avatar
      mm: slab: only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE · ca317d04
      Catalin Marinas authored
      commit d4322d88 upstream.
      
      On systems with a KMALLOC_MIN_SIZE of 128 (arm64, some mips and powerpc
      configurations defining ARCH_DMA_MINALIGN to 128), the first
      kmalloc_caches[] entry to be initialised after slab_early_init = 0 is
      "kmalloc-128" with index 7.  Depending on the debug kernel configuration,
      sizeof(struct kmem_cache) can be larger than 128 resulting in an
      INDEX_NODE of 8.
      
      Commit 8fc9cf42 ("slab: make more slab management structure off the
      slab") enables off-slab management objects for sizes starting with
      PAGE_SIZE >> 5 (128 bytes for a 4KB page configuration) and the creation
      of the "kmalloc-128" cache would try to place the management objects
      off-slab.  However, since KMALLOC_MIN_SIZE is already 128 and
      freelist_size == 32 in __kmem_cache_create(), kmalloc_slab(freelist_size)
      returns NULL (kmalloc_caches[7] not populated yet).  This triggers the
      following bug on arm64:
      
        kernel BUG at /work/Linux/linux-2.6-aarch64/mm/slab.c:2283!
        Internal error: Oops - BUG: 0 [#1] SMP
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Not tainted 4.3.0-rc4+ #540
        Hardware name: Juno (DT)
        PC is at __kmem_cache_create+0x21c/0x280
        LR is at __kmem_cache_create+0x210/0x280
        [...]
        Call trace:
          __kmem_cache_create+0x21c/0x280
          create_boot_cache+0x48/0x80
          create_kmalloc_cache+0x50/0x88
          create_kmalloc_caches+0x4c/0xf4
          kmem_cache_init+0x100/0x118
          start_kernel+0x214/0x33c
      
      This patch introduces an OFF_SLAB_MIN_SIZE definition to avoid off-slab
      management objects for sizes equal to or smaller than KMALLOC_MIN_SIZE.
      
      Fixes: 8fc9cf42 ("slab: make more slab management structure off the slab")
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ca317d04
    • Christoph Hellwig's avatar
      scsi: restart list search after unlock in scsi_remove_target · 0c422a84
      Christoph Hellwig authored
      commit 40998193 upstream.
      
      When dropping a lock while iterating a list we must restart the search
      as other threads could have manipulated the list under us.  Without this
      we can get stuck in an endless loop.  This bug was introduced by
      
      commit bc3f02a7
      Author: Dan Williams <djbw@fb.com>
      Date:   Tue Aug 28 22:12:10 2012 -0700
      
          [SCSI] scsi_remove_target: fix softlockup regression on hot remove
      
      Which was itself trying to fix a reported soft lockup issue
      
      http://thread.gmane.org/gmane.linux.kernel/1348679
      
      However, we believe even with this revert of the original patch, the soft
      lockup problem has been fixed by
      
      commit f2495e22
      Author: James Bottomley <JBottomley@Parallels.com>
      Date:   Tue Jan 21 07:01:41 2014 -0800
      
          [SCSI] dual scan thread bug fix
      
      Thanks go to Dan Williams <dan.j.williams@intel.com> for tracking all this
      prior history down.
      Reported-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Tested-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Fixes: bc3f02a7Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0c422a84