1. 21 Apr, 2017 36 commits
    • Ben Hutchings's avatar
      pegasus: Use heap buffers for all register access · be570e55
      Ben Hutchings authored
      commit 5593523f upstream.
      
      Allocating USB buffers on the stack is not portable, and no longer
      works on x86_64 (with VMAP_STACK enabled as per default).
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      References: https://bugs.debian.org/852556Reported-by: default avatarLisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
      Tested-by: default avatarLisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be570e55
    • Omar Sandoval's avatar
      virtio-console: avoid DMA from stack · eb526765
      Omar Sandoval authored
      commit c4baad50 upstream.
      
      put_chars() stuffs the buffer it gets into an sg, but that buffer may be
      on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
      manifested as printks getting turned into NUL bytes).
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb526765
    • Stefan Brüns's avatar
      dvb-usb-firmware: don't do DMA on stack · 6be431f9
      Stefan Brüns authored
      commit 67b0503d upstream.
      
      The buffer allocation for the firmware data was changed in
      commit 43fab979 ("[media] dvb-usb: don't use stack for firmware load")
      but the same applies for the reset value.
      
      Fixes: 43fab979 ("[media] dvb-usb: don't use stack for firmware load")
      Signed-off-by: default avatarStefan Brüns <stefan.bruens@rwth-aachen.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6be431f9
    • Mauro Carvalho Chehab's avatar
      dvb-usb: don't use stack for firmware load · 50215745
      Mauro Carvalho Chehab authored
      commit 43fab979 upstream.
      
      As reported by Marc Duponcheel <marc@offline.be>, firmware load on
      dvb-usb is using the stack, with is not allowed anymore on default
      Kernel configurations:
      
      [ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware
      [ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
      [ 1025.958855] dvb-usb: could not stop the USB controller CPU.
      [ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3)
      [ 1025.958856] dvb-usb: firmware download failed at 8 with -22
      [ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u
      
      [    2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
      [    2.789905] ------------[ cut here ]------------
      [    2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
      [    2.789912] transfer buffer not dma capable
      [    2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod
      [    2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
      [    2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
      [    2.789938]  ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000
      [    2.789939]  ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000
      [    2.789941]  0000000000000000 0000000000000000 0000000000000001 ffff880116c08000
      [    2.789942] Call Trace:
      [    2.789945]  [<ffffffff812bd397>] dump_stack+0x4d/0x66
      [    2.789947]  [<ffffffff81055c86>] __warn+0xc6/0xe0
      [    2.789948]  [<ffffffff81055cea>] warn_slowpath_fmt+0x4a/0x50
      [    2.789952]  [<ffffffffa006d460>] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
      [    2.789954]  [<ffffffff814ed5a8>] ? io_schedule_timeout+0xd8/0x110
      [    2.789956]  [<ffffffffa006e09c>] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
      [    2.789958]  [<ffffffff812d0ebf>] ? copy_page_to_iter+0x14f/0x2b0
      [    2.789960]  [<ffffffff81126818>] ? pagecache_get_page+0x28/0x240
      [    2.789962]  [<ffffffff8118c2a0>] ? touch_atime+0x20/0xa0
      [    2.789964]  [<ffffffffa006f7c4>] usb_submit_urb+0x2c4/0x520 [usbcore]
      [    2.789967]  [<ffffffffa006feca>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
      [    2.789969]  [<ffffffffa007000c>] usb_control_msg+0xbc/0xf0 [usbcore]
      [    2.789970]  [<ffffffffa067903d>] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
      [    2.789972]  [<ffffffffa06791cf>] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb]
      [    2.789973]  [<ffffffff8109dbbe>] ? console_unlock+0x2fe/0x5d0
      [    2.789974]  [<ffffffff8109e10c>] ? vprintk_emit+0x27c/0x410
      [    2.789975]  [<ffffffff8109e40a>] ? vprintk_default+0x1a/0x20
      [    2.789976]  [<ffffffff81124d76>] ? printk+0x43/0x4b
      [    2.789977]  [<ffffffffa0679310>] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb]
      [    2.789979]  [<ffffffffa0679898>] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
      [    2.789981]  [<ffffffffa069e302>] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u]
      [    2.789984]  [<ffffffffa007420c>] usb_probe_interface+0xfc/0x270 [usbcore]
      [    2.789985]  [<ffffffff8138bf95>] driver_probe_device+0x215/0x2d0
      [    2.789986]  [<ffffffff8138c0e6>] __driver_attach+0x96/0xa0
      [    2.789987]  [<ffffffff8138c050>] ? driver_probe_device+0x2d0/0x2d0
      [    2.789988]  [<ffffffff81389ffb>] bus_for_each_dev+0x5b/0x90
      [    2.789989]  [<ffffffff8138b7b9>] driver_attach+0x19/0x20
      [    2.789990]  [<ffffffff8138b33c>] bus_add_driver+0x11c/0x220
      [    2.789991]  [<ffffffff8138c91b>] driver_register+0x5b/0xd0
      [    2.789994]  [<ffffffffa0072f6c>] usb_register_driver+0x7c/0x130 [usbcore]
      [    2.789994]  [<ffffffffa06a5000>] ? 0xffffffffa06a5000
      [    2.789996]  [<ffffffffa06a501e>] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u]
      [    2.789997]  [<ffffffff81000408>] do_one_initcall+0x38/0x140
      [    2.789998]  [<ffffffff8116001c>] ? __vunmap+0x7c/0xc0
      [    2.789999]  [<ffffffff81124fb0>] ? do_init_module+0x22/0x1d2
      [    2.790000]  [<ffffffff81124fe8>] do_init_module+0x5a/0x1d2
      [    2.790002]  [<ffffffff810c96b1>] load_module+0x1e11/0x2580
      [    2.790003]  [<ffffffff810c68b0>] ? show_taint+0x30/0x30
      [    2.790004]  [<ffffffff81177250>] ? kernel_read_file+0x100/0x190
      [    2.790005]  [<ffffffff810c9ffa>] SyS_finit_module+0xba/0xc0
      [    2.790007]  [<ffffffff814f13e0>] entry_SYSCALL_64_fastpath+0x13/0x94
      [    2.790008] ---[ end trace c78a74e78baec6fc ]---
      
      So, allocate the structure dynamically.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 4.9: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50215745
    • Kees Cook's avatar
      mm: Tighten x86 /dev/mem with zeroing reads · 6739cc12
      Kees Cook authored
      commit a4866aa8 upstream.
      
      Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
      disallowed. However, on x86, the first 1MB was always allowed for BIOS
      and similar things, regardless of it actually being System RAM. It was
      possible for heap to end up getting allocated in low 1MB RAM, and then
      read by things like x86info or dd, which would trip hardened usercopy:
      
      usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
      
      This changes the x86 exception for the low 1MB by reading back zeros for
      System RAM areas instead of blindly allowing them. More work is needed to
      extend this to mmap, but currently mmap doesn't go through usercopy, so
      hardened usercopy won't Oops the kernel.
      Reported-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Tested-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6739cc12
    • Thierry Reding's avatar
      rtc: tegra: Implement clock handling · ba027813
      Thierry Reding authored
      commit 5fa40869 upstream.
      
      Accessing the registers of the RTC block on Tegra requires the module
      clock to be enabled. This only works because the RTC module clock will
      be enabled by default during early boot. However, because the clock is
      unused, the CCF will disable it at late_init time. This causes the RTC
      to become unusable afterwards. This can easily be reproduced by trying
      to use the RTC:
      
      	$ hwclock --rtc /dev/rtc1
      
      This will hang the system. I ran into this by following up on a report
      by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
      turns out that the rtc-tegra driver's ->shutdown() implementation will
      hang the CPU, because of the disabled clock, before the system can be
      rebooted.
      
      What confused me for a while is that the same driver is used on prior
      Tegra generations where the hang can not be observed. However, as Peter
      De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
      clock is enabled by the tegra20_timer.c clocksource driver, which uses
      the RTC to provide a persistent clock. This code is never enabled on
      64-bit Tegra because the persistent clock infrastructure does not exist
      on 64-bit ARM.
      
      The proper fix for this is to add proper clock handling to the RTC
      driver in order to ensure that the clock is enabled when the driver
      requires it. All device trees contain the clock already, therefore
      no additional changes are required.
      Reported-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Acked-By Peter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      [bwh: Backported to 4.9: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba027813
    • Lee, Chun-Yi's avatar
      platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event · ccf0904c
      Lee, Chun-Yi authored
      commit 98d610c3 upstream.
      
      The accelerometer event relies on the ACERWMID_EVENT_GUID notify.
      So, this patch changes the codes to setup accelerometer input device
      when detected ACERWMID_EVENT_GUID. It avoids that the accel input
      device created on every Acer machines.
      
      In addition, patch adds a clearly parsing logic of accelerometer hid
      to acer_wmi_get_handle_cb callback function. It is positive matching
      the "SENR" name with "BST0001" device to avoid non-supported hardware.
      Reported-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: Darren Hart <dvhart@infradead.org>
      Signed-off-by: default avatarLee, Chun-Yi <jlee@suse.com>
      [andy: slightly massage commit message]
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ccf0904c
    • Daeho Jeong's avatar
      ext4: fix inode checksum calculation problem if i_extra_size is small · 51f8d95c
      Daeho Jeong authored
      commit 05ac5aa1 upstream.
      
      We've fixed the race condition problem in calculating ext4 checksum
      value in commit b47820ed ("ext4: avoid modifying checksum fields
      directly during checksum veficationon"). However, by this change,
      when calculating the checksum value of inode whose i_extra_size is
      less than 4, we couldn't calculate the checksum value in a proper way.
      This problem was found and reported by Nix, Thank you.
      Reported-by: default avatarNix <nix@esperi.org.uk>
      Signed-off-by: default avatarDaeho Jeong <daeho.jeong@samsung.com>
      Signed-off-by: default avatarYoungjin Gil <youngjin.gil@samsung.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51f8d95c
    • Arnd Bergmann's avatar
      dvb-usb-v2: avoid use-after-free · 0cb03b6e
      Arnd Bergmann authored
      commit 00514537 upstream.
      
      I ran into a stack frame size warning because of the on-stack copy of
      the USB device structure:
      
      drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usbv2_disconnect':
      drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1029:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      Copying a device structure like this is wrong for a number of other reasons
      too aside from the possible stack overflow. One of them is that the
      dev_info() call will print the name of the device later, but AFAICT
      we have only copied a pointer to the name earlier and the actual name
      has been freed by the time it gets printed.
      
      This removes the on-stack copy of the device and instead copies the
      device name using kstrdup(). I'm ignoring the possible failure here
      as both printk() and kfree() are able to deal with NULL pointers.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0cb03b6e
    • Miaoqing Pan's avatar
      ath9k: fix NULL pointer dereference · ea6d8d67
      Miaoqing Pan authored
      commit 40bea976 upstream.
      
      relay_open() may return NULL, check the return value to avoid the crash.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
      IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
      PGD 41cf28067 PUD 41be92067 PMD 0
      Oops: 0000 [#1] SMP
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
      Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15    07/04/2011
      task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
      RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
      RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
      RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
      Stack:
      0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
      000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
      0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60
      
      Call Trace:
      <IRQ>
      [<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
      [<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
      [<ffffffff8105dde2>] __do_softirq+0x92/0x2a0
      Reported-by: default avatarDevin Tuchsen <devin.tuchsen@gmail.com>
      Tested-by: default avatarDevin Tuchsen <devin.tuchsen@gmail.com>
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea6d8d67
    • Herbert Xu's avatar
      crypto: ahash - Fix EINPROGRESS notification callback · 2673d1c5
      Herbert Xu authored
      commit ef0579b6 upstream.
      
      The ahash API modifies the request's callback function in order
      to clean up after itself in some corner cases (unaligned final
      and missing finup).
      
      When the request is complete ahash will restore the original
      callback and everything is fine.  However, when the request gets
      an EBUSY on a full queue, an EINPROGRESS callback is made while
      the request is still ongoing.
      
      In this case the ahash API will incorrectly call its own callback.
      
      This patch fixes the problem by creating a temporary request
      object on the stack which is used to relay EINPROGRESS back to
      the original completion function.
      
      This patch also adds code to preserve the original flags value.
      
      Fixes: ab6bf4e5 ("crypto: hash - Fix the pointer voodoo in...")
      Reported-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Tested-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2673d1c5
    • Benjamin Herrenschmidt's avatar
      powerpc: Disable HFSCR[TM] if TM is not supported · 70e55aaf
      Benjamin Herrenschmidt authored
      commit 7ed23e1b upstream.
      
      On Power8 & Power9 the early CPU inititialisation in __init_HFSCR()
      turns on HFSCR[TM] (Hypervisor Facility Status and Control Register
      [Transactional Memory]), but that doesn't take into account that TM
      might be disabled by CPU features, or disabled by the kernel being built
      with CONFIG_PPC_TRANSACTIONAL_MEM=n.
      
      So later in boot, when we have setup the CPU features, clear HSCR[TM] if
      the TM CPU feature has been disabled. We use CPU_FTR_TM_COMP to account
      for the CONFIG_PPC_TRANSACTIONAL_MEM=n case.
      
      Without this a KVM guest might try use TM, even if told not to, and
      cause an oops in the host kernel. Typically the oops is seen in
      __kvmppc_vcore_entry() and may or may not be fatal to the host, but is
      always bad news.
      
      In practice all shipping CPU revisions do support TM, and all host
      kernels we are aware of build with TM support enabled, so no one should
      actually be able to hit this in the wild.
      
      Fixes: 2a3563b0 ("powerpc: Setup in HFSCR for POWER8")
      Cc: stable@vger.kernel.org # v3.10+
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Tested-by: default avatarSam Bobroff <sam.bobroff@au1.ibm.com>
      [mpe: Rewrite change log with input from Sam, add Fixes/stable]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      [sb: Backported to linux-4.4.y: adjusted context]
      Signed-off-by: default avatarSam Bobroff <sam.bobroff@au1.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70e55aaf
    • Minchan Kim's avatar
      zram: do not use copy_page with non-page aligned address · 9286385a
      Minchan Kim authored
      commit d72e9a7a upstream.
      
      The copy_page is optimized memcpy for page-alinged address.  If it is
      used with non-page aligned address, it can corrupt memory which means
      system corruption.  With zram, it can happen with
      
      1. 64K architecture
      2. partial IO
      3. slub debug
      
      Partial IO need to allocate a page and zram allocates it via kmalloc.
      With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
      address.  And finally, copy_page(mem, cmem) corrupts memory.
      
      So, this patch changes it to memcpy.
      
      Actuaully, we don't need to change zram_bvec_write part because zsmalloc
      returns page-aligned address in case of PAGE_SIZE class but it's not
      good to rely on the internal of zsmalloc.
      
      Note:
       When this patch is merged to stable, clear_page should be fixed, too.
       Unfortunately, recent zram removes it by "same page merge" feature so
       it's hard to backport this patch to -stable tree.
      
      I will handle it when I receive the mail from stable tree maintainer to
      merge this patch to backport.
      
      Fixes: 42e99bd9 ("zram: optimize memory operations with clear_page()/copy_page()")
      Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.orgSigned-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      9286385a
    • Paolo Bonzini's avatar
      kvm: fix page struct leak in handle_vmon · c1fc1d2f
      Paolo Bonzini authored
      commit 06ce521a upstream.
      
      handle_vmon gets a reference on VMXON region page,
      but does not release it. Release the reference.
      
      Found by syzkaller; based on a patch by Dmitry.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [bwh: Backported to 3.16: use skip_emulated_instruction()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1fc1d2f
    • Greg Kroah-Hartman's avatar
      Revert "MIPS: Lantiq: Fix cascaded IRQ setup" · 98c953a0
      Greg Kroah-Hartman authored
      This reverts commit 6280ac93 which is
      commit 6c356eda upstream.
      
      It shouldn't have been included in a stable release.
      Reported-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: John Crispin <john@phrozen.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98c953a0
    • Max Bires's avatar
      char: lack of bool string made CONFIG_DEVPORT always on · a32c5331
      Max Bires authored
      commit f2cfa58b upstream.
      
      Without a bool string present, using "# CONFIG_DEVPORT is not set" in
      defconfig files would not actually unset devport. This esnured that
      /dev/port was always on, but there are reasons a user may wish to
      disable it (smaller kernel, attack surface reduction) if it's not being
      used. Adding a message here in order to make this user visible.
      Signed-off-by: default avatarMax Bires <jbires@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a32c5331
    • Geert Uytterhoeven's avatar
      char: Drop bogus dependency of DEVPORT on !M68K · 0a6aa0d1
      Geert Uytterhoeven authored
      commit 309124e2 upstream.
      
      According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
      update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
      defined.
      
      However, commit 153dcc54 ("[PATCH] mem driver: fix conditional
      on isa i/o support") accidentally changed an "||" into an "&&",
      disabling it completely on m68k. This logic was retained when
      introducing the DEVPORT symbol in commit 4f911d64 ("Make
      /dev/port conditional on config symbol").
      
      Drop the bogus dependency on !M68K to fix this.
      
      Fixes: 153dcc54 ("[PATCH] mem driver: fix conditional on isa i/o support")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarAl Stone <ahs3@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a6aa0d1
    • Steven Rostedt (VMware)'s avatar
      ftrace: Fix removing of second function probe · 7fe57118
      Steven Rostedt (VMware) authored
      commit 82cc4fc2 upstream.
      
      When two function probes are added to set_ftrace_filter, and then one of
      them is removed, the update to the function locations is not performed, and
      the record keeping of the function states are corrupted, and causes an
      ftrace_bug() to occur.
      
      This is easily reproducable by adding two probes, removing one, and then
      adding it back again.
      
       # cd /sys/kernel/debug/tracing
       # echo schedule:traceoff > set_ftrace_filter
       # echo do_IRQ:traceoff > set_ftrace_filter
       # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
       # echo do_IRQ:traceoff > set_ftrace_filter
      
      Causes:
       ------------[ cut here ]------------
       WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 ftrace_get_addr_curr+0x143/0x220
       Modules linked in: [...]
       CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
       Call Trace:
        dump_stack+0x68/0x9f
        __warn+0x111/0x130
        ? trace_irq_work_interrupt+0xa0/0xa0
        warn_slowpath_null+0x1d/0x20
        ftrace_get_addr_curr+0x143/0x220
        ? __fentry__+0x10/0x10
        ftrace_replace_code+0xe3/0x4f0
        ? ftrace_int3_handler+0x90/0x90
        ? printk+0x99/0xb5
        ? 0xffffffff81000000
        ftrace_modify_all_code+0x97/0x110
        arch_ftrace_update_code+0x10/0x20
        ftrace_run_update_code+0x1c/0x60
        ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0
        register_ftrace_function_probe+0x4b6/0x590
        ? ftrace_startup+0x310/0x310
        ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30
        ? update_stack_state+0x88/0x110
        ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
        ? preempt_count_sub+0x18/0xd0
        ? mutex_lock_nested+0x104/0x800
        ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
        ? __unwind_start+0x1c0/0x1c0
        ? _mutex_lock_nest_lock+0x800/0x800
        ftrace_trace_probe_callback.isra.3+0xc0/0x130
        ? func_set_flag+0xe0/0xe0
        ? __lock_acquire+0x642/0x1790
        ? __might_fault+0x1e/0x20
        ? trace_get_user+0x398/0x470
        ? strcmp+0x35/0x60
        ftrace_trace_onoff_callback+0x48/0x70
        ftrace_regex_write.isra.43.part.44+0x251/0x320
        ? match_records+0x420/0x420
        ftrace_filter_write+0x2b/0x30
        __vfs_write+0xd7/0x330
        ? do_loop_readv_writev+0x120/0x120
        ? locks_remove_posix+0x90/0x2f0
        ? do_lock_file_wait+0x160/0x160
        ? __lock_is_held+0x93/0x100
        ? rcu_read_lock_sched_held+0x5c/0xb0
        ? preempt_count_sub+0x18/0xd0
        ? __sb_start_write+0x10a/0x230
        ? vfs_write+0x222/0x240
        vfs_write+0xef/0x240
        SyS_write+0xab/0x130
        ? SyS_read+0x130/0x130
        ? trace_hardirqs_on_caller+0x182/0x280
        ? trace_hardirqs_on_thunk+0x1a/0x1c
        entry_SYSCALL_64_fastpath+0x18/0xad
       RIP: 0033:0x7fe61c157c30
       RSP: 002b:00007ffe87890258 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
       RAX: ffffffffffffffda RBX: ffffffff8114a410 RCX: 00007fe61c157c30
       RDX: 0000000000000010 RSI: 000055814798f5e0 RDI: 0000000000000001
       RBP: ffff8800c9027f98 R08: 00007fe61c422740 R09: 00007fe61ca53700
       R10: 0000000000000073 R11: 0000000000000246 R12: 0000558147a36400
       R13: 00007ffe8788f160 R14: 0000000000000024 R15: 00007ffe8788f15c
        ? trace_hardirqs_off_caller+0xc0/0x110
       ---[ end trace 99fa09b3d9869c2c ]---
       Bad trampoline accounting at: ffffffff81cc3b00 (do_IRQ+0x0/0x150)
      
      Fixes: 59df055f ("ftrace: trace different functions with a different tracer")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fe57118
    • Tyler Baker's avatar
      irqchip/irq-imx-gpcv2: Fix spinlock initialization · c51451e4
      Tyler Baker authored
      commit 75eb5e1e upstream.
      
      The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before
      usage. That results in a lockdep splat:
      
        INFO: trying to register non-static key.
        the code is fine but needs lockdep annotation.
        turning off the locking correctness validator.
      
      Add the missing raw_spin_lock_init() to the setup code.
      
      Fixes: e324c4dc ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources")
      Signed-off-by: default avatarTyler Baker <tyler.baker@linaro.org>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: shawnguo@kernel.org
      Cc: andrew.smirnov@gmail.com
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c51451e4
    • Dan Williams's avatar
      libnvdimm: fix reconfig_mutex, mmap_sem, and jbd2_handle lockdep splat · 66b531d3
      Dan Williams authored
      commit 0beb2012 upstream.
      
      Holding the reconfig_mutex over a potential userspace fault sets up a
      lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl
      path. Move the user access outside of the lock.
      
           [ INFO: possible circular locking dependency detected ]
           4.11.0-rc3+ #13 Tainted: G        W  O
           -------------------------------------------------------
           fallocate/16656 is trying to acquire lock:
            (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffa00080b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm]
           but task is already holding lock:
            (jbd2_handle){++++..}, at: [<ffffffff813b4944>] start_this_handle+0x104/0x460
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #2 (jbd2_handle){++++..}:
                  lock_acquire+0xbd/0x200
                  start_this_handle+0x16a/0x460
                  jbd2__journal_start+0xe9/0x2d0
                  __ext4_journal_start_sb+0x89/0x1c0
                  ext4_dirty_inode+0x32/0x70
                  __mark_inode_dirty+0x235/0x670
                  generic_update_time+0x87/0xd0
                  touch_atime+0xa9/0xd0
                  ext4_file_mmap+0x90/0xb0
                  mmap_region+0x370/0x5b0
                  do_mmap+0x415/0x4f0
                  vm_mmap_pgoff+0xd7/0x120
                  SyS_mmap_pgoff+0x1c5/0x290
                  SyS_mmap+0x22/0x30
                  entry_SYSCALL_64_fastpath+0x1f/0xc2
      
          -> #1 (&mm->mmap_sem){++++++}:
                  lock_acquire+0xbd/0x200
                  __might_fault+0x70/0xa0
                  __nd_ioctl+0x683/0x720 [libnvdimm]
                  nvdimm_ioctl+0x8b/0xe0 [libnvdimm]
                  do_vfs_ioctl+0xa8/0x740
                  SyS_ioctl+0x79/0x90
                  do_syscall_64+0x6c/0x200
                  return_from_SYSCALL_64+0x0/0x7a
      
          -> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}:
                  __lock_acquire+0x16b6/0x1730
                  lock_acquire+0xbd/0x200
                  __mutex_lock+0x88/0x9b0
                  mutex_lock_nested+0x1b/0x20
                  nvdimm_bus_lock+0x21/0x30 [libnvdimm]
                  nvdimm_forget_poison+0x25/0x50 [libnvdimm]
                  nvdimm_clear_poison+0x106/0x140 [libnvdimm]
                  pmem_do_bvec+0x1c2/0x2b0 [nd_pmem]
                  pmem_make_request+0xf9/0x270 [nd_pmem]
                  generic_make_request+0x118/0x3b0
                  submit_bio+0x75/0x150
      
      Fixes: 62232e45 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices")
      Cc: Dave Jiang <dave.jiang@intel.com>
      Reported-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66b531d3
    • Juergen Gross's avatar
      xen, fbfront: fix connecting to backend · 6058cf99
      Juergen Gross authored
      commit 9121b15b upstream.
      
      Connecting to the backend isn't working reliably in xen-fbfront: in
      case XenbusStateInitWait of the backend has been missed the backend
      transition to XenbusStateConnected will trigger the connected state
      only without doing the actions required when the backend has
      connected.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6058cf99
    • Martin K. Petersen's avatar
      scsi: sd: Fix capacity calculation with 32-bit sector_t · b689dfbe
      Martin K. Petersen authored
      commit 7c856152 upstream.
      
      We previously made sure that the reported disk capacity was less than
      0xffffffff blocks when the kernel was not compiled with large sector_t
      support (CONFIG_LBDAF). However, this check assumed that the capacity
      was reported in units of 512 bytes.
      
      Add a sanity check function to ensure that we only enable disks if the
      entire reported capacity can be expressed in terms of sector_t.
      Reported-by: default avatarSteve Magnani <steve.magnani@digidescorp.com>
      Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>
      Reviewed-by: default avatarBart Van Assche <Bart.VanAssche@sandisk.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b689dfbe
    • Fam Zheng's avatar
      scsi: sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable · 44896195
      Fam Zheng authored
      commit 67804145 upstream.
      
      If device reports a small max_xfer_blocks and a zero opt_xfer_blocks, we
      end up using BLK_DEF_MAX_SECTORS, which is wrong and r/w of that size
      may get error.
      
      [mkp: tweaked to avoid setting rw_max twice and added typecast]
      
      Fixes: ca369d51 ("block/sd: Fix device-imposed transfer length limits")
      Signed-off-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44896195
    • Martin K. Petersen's avatar
      scsi: sr: Sanity check returned mode data · 925adae6
      Martin K. Petersen authored
      commit a00a7862 upstream.
      
      Kefeng Wang discovered that old versions of the QEMU CD driver would
      return mangled mode data causing us to walk off the end of the buffer in
      an attempt to parse it. Sanity check the returned mode sense data.
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Tested-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      925adae6
    • Nicholas Bellinger's avatar
      iscsi-target: Drop work-around for legacy GlobalSAN initiator · 1e1de2e8
      Nicholas Bellinger authored
      commit 1c99de98 upstream.
      
      Once upon a time back in 2009, a work-around was added to support
      the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
      did not propose nor respond to MaxBurstLength, FirstBurstLength,
      DefaultTime2Wait and DefaultTime2Retain keys.
      
      The work-around in iscsi_check_proposer_for_optional_reply()
      allowed the missing keys to be proposed, but did not require
      waiting for a response before moving to full feature phase
      operation.  This allowed GlobalSAN v3.3 to work out-of-the
      box, and for many years we didn't run into login interopt
      issues with any other initiators..
      
      Until recently, when Martin tried a QLogic 57840S iSCSI Offload
      HBA on Windows 2016 which completed login, but subsequently
      failed with:
      
          Got unknown iSCSI OpCode: 0x43
      
      The issue was QLogic MSFT side did not propose DefaultTime2Wait +
      DefaultTime2Retain, so LIO proposes them itself, and immediately
      transitions to full feature phase because of the GlobalSAN hack.
      However, the QLogic MSFT side still attempts to respond to
      DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
      ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
      in last login response.
      
      So while the QLogic MSFT side should have been proposing these
      two keys to start, it was doing the correct thing per RFC-3720
      attempting to respond to proposed keys before transitioning to
      full feature phase.
      
      All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
      does correctly propose the four keys during login, making the
      original work-around moot.
      
      So in order to allow QLogic MSFT to run unmodified as-is, go
      ahead and drop this long standing work-around.
      Reported-by: default avatarMartin Svec <martin.svec@zoner.cz>
      Cc: Martin Svec <martin.svec@zoner.cz>
      Cc: Himanshu Madhani <Himanshu.Madhani@cavium.com>
      Cc: Arun Easi <arun.easi@cavium.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e1de2e8
    • Nicholas Bellinger's avatar
      iscsi-target: Fix TMR reference leak during session shutdown · 05c5dd75
      Nicholas Bellinger authored
      commit efb2ea77 upstream.
      
      This patch fixes a iscsi-target specific TMR reference leak
      during session shutdown, that could occur when a TMR was
      quiesced before the hand-off back to iscsi-target code
      via transport_cmd_check_stop_to_fabric().
      
      The reference leak happens because iscsit_free_cmd() was
      incorrectly skipping the final target_put_sess_cmd() for
      TMRs when transport_generic_free_cmd() returned zero because
      the se_cmd->cmd_kref did not reach zero, due to the missing
      se_cmd assignment in original code.
      
      The result was iscsi_cmd and it's associated se_cmd memory
      would be freed once se_sess->sess_cmd_map where released,
      but the associated se_tmr_req was leaked and remained part
      of se_device->dev_tmr_list.
      
      This bug would manfiest itself as kernel paging request
      OOPsen in core_tmr_lun_reset(), when a left-over se_tmr_req
      attempted to dereference it's se_cmd pointer that had
      already been released during normal session shutdown.
      
      To address this bug, go ahead and treat ISCSI_OP_SCSI_CMD
      and ISCSI_OP_SCSI_TMFUNC the same when there is an extra
      se_cmd->cmd_kref to drop in iscsit_free_cmd(), and use
      op_scsi to signal __iscsit_free_cmd() when the former
      needs to clear any further iscsi related I/O state.
      Reported-by: default avatarRob Millner <rlm@daterainc.com>
      Cc: Rob Millner <rlm@daterainc.com>
      Reported-by: default avatarChu Yuan Lin <cyl@datera.io>
      Cc: Chu Yuan Lin <cyl@datera.io>
      Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05c5dd75
    • Dan Williams's avatar
      acpi, nfit, libnvdimm: fix interleave set cookie calculation (64-bit comparison) · 074bcc13
      Dan Williams authored
      commit b03b99a3 upstream.
      
      While reviewing the -stable patch for commit 86ef58a4 "nfit,
      libnvdimm: fix interleave set cookie calculation" Ben noted:
      
          "This is returning an int, thus it's effectively doing a 32-bit
           comparison and not the 64-bit comparison you say is needed."
      
      Update the compare operation to be immune to this integer demotion problem.
      
      Cc: Nicholas Moulin <nicholas.w.moulin@linux.intel.com>
      Fixes: 86ef58a4 ("nfit, libnvdimm: fix interleave set cookie calculation")
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      074bcc13
    • Thomas Gleixner's avatar
      x86/vdso: Plug race between mapping and ELF header setup · ec3978e1
      Thomas Gleixner authored
      commit 6fdc6dd9 upstream.
      
      The vsyscall32 sysctl can racy against a concurrent fork when it switches
      from disabled to enabled:
      
          arch_setup_additional_pages()
      	if (vdso32_enabled)
                 --> No mapping
                                              sysctl.vsysscall32()
                                                --> vdso32_enabled = true
          create_elf_tables()
            ARCH_DLINFO_IA32
              if (vdso32_enabled) {
                 --> Add VDSO entry with NULL pointer
      
      Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
      the newly forked process or not.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mathias Krause <minipli@googlemail.com>
      Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec3978e1
    • Mathias Krause's avatar
      x86/vdso: Ensure vdso32_enabled gets set to valid values only · f1c5d016
      Mathias Krause authored
      commit c06989da upstream.
      
      vdso_enabled can be set to arbitrary integer values via the kernel command
      line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'.
      
      load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32
      merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR
      auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which
      causes a segfault when the application tries to use the VDSO.
      
      Restrict the valid arguments on the command line and the sysctl to 0 and 1.
      
      Fixes: b0b49f26 ("x86, vdso: Remove compat vdso support")
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roland McGrath <roland@redhat.com>
      Link: http://lkml.kernel.org/r/1491424561-7187-1-git-send-email-minipli@googlemail.com
      Link: http://lkml.kernel.org/r/20170410151723.518412863@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1c5d016
    • Peter Zijlstra's avatar
      perf/x86: Avoid exposing wrong/stale data in intel_pmu_lbr_read_32() · f42be33f
      Peter Zijlstra authored
      commit f2200ac3 upstream.
      
      When the perf_branch_entry::{in_tx,abort,cycles} fields were added,
      intel_pmu_lbr_read_32() wasn't updated to initialize them.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Fixes: 135c5612 ("perf/x86/intel: Support Haswell/v4 LBR format")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f42be33f
    • Cameron Gutman's avatar
    • Germano Percossi's avatar
      CIFS: store results of cifs_reopen_file to avoid infinite wait · f0899d0e
      Germano Percossi authored
      commit 1fa839b4 upstream.
      
      This fixes Continuous Availability when errors during
      file reopen are encountered.
      
      cifs_user_readv and cifs_user_writev would wait for ever if
      results of cifs_reopen_file are not stored and for later inspection.
      
      In fact, results are checked and, in case of errors, a chain
      of function calls leading to reads and writes to be scheduled in
      a separate thread is skipped.
      These threads will wake up the corresponding waiters once reads
      and writes are done.
      
      However, given the return value is not stored, when rc is checked
      for errors a previous one (always zero) is inspected instead.
      This leads to pending reads/writes added to the list, making
      cifs_user_readv and cifs_user_writev wait for ever.
      Signed-off-by: default avatarGermano Percossi <germano.percossi@citrix.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0899d0e
    • Ilia Mirkin's avatar
      drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one · a11ab9dd
      Ilia Mirkin authored
      commit f94773b9 upstream.
      
      The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
      and PCI varieties, rather than a core PCIE chip with a bridge for
      AGP/PCI as necessary. As a result, it appears that the MMU is also
      non-functional. For AGP cards, the vast majority of the NV4A lineup,
      this worked out since we force AGP cards to use the nv04 mmu. However
      for PCI variants, this did not work.
      
      Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
      the suggestion. This should be a no-op for NV4A AGP boards, as they were
      using it already.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a11ab9dd
    • Ilia Mirkin's avatar
      drm/nouveau/mpeg: mthd returns true on success now · a737abe4
      Ilia Mirkin authored
      commit 83bce9c2 upstream.
      Signed-off-by: default avatarIlia Mirkin <imirkin@alum.mit.edu>
      Fixes: 590801c1 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup")
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a737abe4
    • Kirill A. Shutemov's avatar
      thp: fix MADV_DONTNEED vs clear soft dirty race · ef4c9628
      Kirill A. Shutemov authored
      commit 5b7abeae upstream.
      
      Yet another instance of the same race.
      
      Fix is identical to change_huge_pmd().
      
      See "thp: fix MADV_DONTNEED vs.  numa balancing race" for more details.
      
      Link: http://lkml.kernel.org/r/20170302151034.27829-5-kirill.shutemov@linux.intel.comSigned-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef4c9628
    • Tejun Heo's avatar
      cgroup, kthread: close race window where new kthreads can be migrated to non-root cgroups · 3144d81a
      Tejun Heo authored
      commit 77f88796 upstream.
      
      Creation of a kthread goes through a couple interlocked stages between
      the kthread itself and its creator.  Once the new kthread starts
      running, it initializes itself and wakes up the creator.  The creator
      then can further configure the kthread and then let it start doing its
      job by waking it up.
      
      In this configuration-by-creator stage, the creator is the only one
      that can wake it up but the kthread is visible to userland.  When
      altering the kthread's attributes from userland is allowed, this is
      fine; however, for cases where CPU affinity is critical,
      kthread_bind() is used to first disable affinity changes from userland
      and then set the affinity.  This also prevents the kthread from being
      migrated into non-root cgroups as that can affect the CPU affinity and
      many other things.
      
      Unfortunately, the cgroup side of protection is racy.  While the
      PF_NO_SETAFFINITY flag prevents further migrations, userland can win
      the race before the creator sets the flag with kthread_bind() and put
      the kthread in a non-root cgroup, which can lead to all sorts of
      problems including incorrect CPU affinity and starvation.
      
      This bug got triggered by userland which periodically tries to migrate
      all processes in the root cpuset cgroup to a non-root one.  Per-cpu
      workqueue workers got caught while being created and ended up with
      incorrected CPU affinity breaking concurrency management and sometimes
      stalling workqueue execution.
      
      This patch adds task->no_cgroup_migration which disallows the task to
      be migrated by userland.  kthreadd starts with the flag set making
      every child kthread start in the root cgroup with migration
      disallowed.  The flag is cleared after the kthread finishes
      initialization by which time PF_NO_SETAFFINITY is set if the kthread
      should stay in the root cgroup.
      
      It'd be better to wait for the initialization instead of failing but I
      couldn't think of a way of implementing that without adding either a
      new PF flag, or sleeping and retrying from waiting side.  Even if
      userland depends on changing cgroup membership of a kthread, it either
      has to be synchronized with kthread_create() or periodically repeat,
      so it's unlikely that this would break anything.
      
      v2: Switch to a simpler implementation using a new task_struct bit
          field suggested by Oleg.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Reported-and-debugged-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3144d81a
  2. 18 Apr, 2017 4 commits