commit ec2a7555f46858fc960300e61b97e2b2406116f6 Author: Greg Kroah-Hartman Date: Wed Jun 1 12:17:36 2016 -0700 Linux 4.5.6 commit 3e9227d949d3988fe24620b592d911ed888c882c Author: Arnd Bergmann Date: Tue May 10 23:30:01 2016 +0200 kbuild: move -Wunused-const-variable to W=1 warning level commit c9c6837d39311b0cc14cdbe7c18e815ab44aefb1 upstream. gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=] arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=] drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=] drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=] drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=] This is similar to the existing -Wunused-but-set-variable warning that was added in an earlier release and that we disable by default now and only enable when W=1 is set, so it makes sense to do the same here. Once we have eliminated the majority of the warnings for both, we can put them back into the default list. We probably want this in backport kernels as well, to allow building them with gcc-6 without introducing extra warnings. Signed-off-by: Arnd Bergmann Acked-by: Olof Johansson Acked-by: Lee Jones Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman commit a128141350f9c4108e5a27021729e589e5239daf Author: Johannes Thumshirn Date: Tue Apr 5 11:50:45 2016 +0200 Revert "scsi: fix soft lockup in scsi_remove_target() on module removal" commit 305c2e71b3d733ec065cb716c76af7d554bd5571 upstream. Now that we've done a more comprehensive fix with the intermediate target state we can remove the previous hack introduced with commit 90a88d6ef88e ("scsi: fix soft lockup in scsi_remove_target() on module removal"). Signed-off-by: Johannes Thumshirn Reviewed-by: Ewan D. Milne Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1b8acb9b02d8e3423ebb6af619508b7ee9c23900 Author: Johannes Thumshirn Date: Tue Apr 5 11:50:44 2016 +0200 scsi: Add intermediate STARGET_REMOVE state to scsi_target_state commit f05795d3d771f30a7bdc3a138bf714b06d42aa95 upstream. Add intermediate STARGET_REMOVE state to scsi_target_state to avoid running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE state is only valid in the path from scsi_remove_target() to scsi_target_destroy() indicating this target is going to be removed. This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI] scsi_remove_target: fix softlockup regression on hot remove") and 40998193560d ("scsi: restart list search after unlock in scsi_remove_target") in a more comprehensive way. [mkp: Included James' fix for scsi_target_destroy()] Signed-off-by: Johannes Thumshirn Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38 Reported-by: Sergey Senozhatsky Tested-by: Sergey Senozhatsky Reviewed-by: Ewan D. Milne Reviewed-by: Hannes Reinecke Reviewed-by: James Bottomley Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 43eabfc371d71905166af5d06b5c8d5b09e69d72 Author: Mikulas Patocka Date: Tue May 24 22:49:18 2016 +0200 hpfs: implement the show_options method commit 037369b872940cd923835a0a589763180c4a36bc upstream. The HPFS filesystem used generic_show_options to produce string that is displayed in /proc/mounts. However, there is a problem that the options may disappear after remount. If we mount the filesystem with option1 and then remount it with option2, /proc/mounts should show both option1 and option2, however it only shows option2 because the whole option string is replaced with replace_mount_options in hpfs_remount_fs. To fix this bug, implement the hpfs_show_options function that prints options that are currently selected. Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b9b4574c8e747a1c9267755c31f9bf17959762b2 Author: Mikulas Patocka Date: Tue May 24 22:47:00 2016 +0200 hpfs: fix remount failure when there are no options changed commit 44d51706b4685f965cd32acde3fe0fcc1e6198e8 upstream. Commit ce657611baf9 ("hpfs: kstrdup() out of memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: ce657611baf9 ("hpfs: kstrdup() out of memory handling") Signed-off-by: Mikulas Patocka Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a8a54a05a733c2290cc0b6bc9fad36069cf3cd12 Author: Richard Weinberger Date: Tue Apr 26 16:39:48 2016 +0200 UBI: Fix static volume checks when Fastmap is used commit 1900149c835ab5b48bea31a823ea5e5a401fb560 upstream. Ezequiel reported that he's facing UBI going into read-only mode after power cut. It turned out that this behavior happens only when updating a static volume is interrupted and Fastmap is used. A possible trace can look like: ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012 0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841 ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6 ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0 Call Trace: [] dump_stack+0x63/0x82 [] ubi_eba_read_leb+0x486/0x4a0 [ubi] [] ubi_check_volume+0x83/0xf0 [ubi] [] ubi_open_volume+0x177/0x350 [ubi] [] vol_cdev_open+0x58/0xb0 [ubi] [] chrdev_open+0xae/0x1d0 [] do_dentry_open+0x1ff/0x300 [] ? cdev_put+0x30/0x30 [] vfs_open+0x56/0x60 [] path_openat+0x4f4/0x1190 [] do_filp_open+0x91/0x100 [] ? __alloc_fd+0xc7/0x190 [] do_sys_open+0x13f/0x210 [] SyS_open+0x1e/0x20 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 UBI checks static volumes for data consistency and reads the whole volume upon first open. If the volume is found erroneous users of UBI cannot read from it, but another volume update is possible to fix it. The check is performed by running ubi_eba_read_leb() on every allocated LEB of the volume. For static volumes ubi_eba_read_leb() computes the checksum of all data stored in a LEB. To verify the computed checksum it has to read the LEB's volume header which stores the original checksum. If the volume header is not found UBI treats this as fatal internal error and switches to RO mode. If the UBI device was attached via a full scan the assumption is correct, the volume header has to be present as it had to be there while scanning to get known as mapped. If the attach operation happened via Fastmap the assumption is no longer correct. When attaching via Fastmap UBI learns the mapping table from Fastmap's snapshot of the system state and not via a full scan. It can happen that a LEB got unmapped after a Fastmap was written to the flash. Then UBI can learn the LEB still as mapped and accessing it returns only 0xFF bytes. As UBI is not a FTL it is allowed to have mappings to empty PEBs, it assumes that the layer above takes care of LEB accounting and referencing. UBIFS does so using the LEB property tree (LPT). For static volumes UBI blindly assumes that all LEBs are present and therefore special actions have to be taken. The described situation can happen when updating a static volume is interrupted, either by a user or a power cut. The volume update code first unmaps all LEBs of a volume and then writes LEB by LEB. If the sequence of operations is interrupted UBI detects this either by the absence of LEBs, no volume header present at scan time, or corrupted payload, detected via checksum. In the Fastmap case the former method won't trigger as no scan happened and UBI automatically thinks all LEBs are present. Only by reading data from a LEB it detects that the volume header is missing and incorrectly treats this as fatal error. To deal with the situation ubi_eba_read_leb() from now on checks whether we attached via Fastmap and handles the absence of a volume header like a data corruption error. This way interrupted static volume updates will correctly get detected also when Fastmap is used. Reported-by: Ezequiel Garcia Tested-by: Ezequiel Garcia Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit bece76228840b8c815008fe14280b1e1aada1d08 Author: James Hogan Date: Mon Feb 8 18:43:50 2016 +0000 SIGNAL: Move generic copy_siginfo() to signal.h commit ca9eb49aa9562eaadf3cea071ec7018ad6800425 upstream. The generic copy_siginfo() is currently defined in asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which defines the generic struct siginfo. However this makes it awkward for an architecture to use it if it has to define its own struct siginfo (e.g. MIPS and potentially IA64), since it means that asm-generic/siginfo.h can only be included after defining the arch-specific siginfo, which may be problematic if the arch-specific definition needs definitions from uapi/asm-generic/siginfo.h. It is possible to work around this by first including uapi/asm-generic/siginfo.h to get the constants before defining the arch-specific siginfo, and include asm-generic/siginfo.h after. However uapi headers can't be included by other uapi headers, so that first include has to be in an ifdef __kernel__, with the non __kernel__ case including the non-UAPI header instead. Instead of that mess, move the generic copy_siginfo() definition into linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to include asm-generic/siginfo.h and define the arch-specific siginfo, and for the generic copy_siginfo() to see that arch-specific definition. Signed-off-by: James Hogan Cc: Arnd Bergmann Cc: Ralf Baechle Cc: Petr Malat Cc: Tony Luck Cc: Fenghua Yu Cc: Christopher Ferris Cc: linux-arch@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-ia64@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12478/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 11d853be8ade548d68241ca2342addf1514c4b18 Author: Andreas Noever Date: Sun Apr 10 12:48:27 2016 +0200 thunderbolt: Fix double free of drom buffer commit 2ffa9a5d76a75abbc1f95c17959fced666095bdd upstream. If tb_drom_read() fails, sw->drom is freed but not set to NULL. sw->drom is then freed again in the error path of tb_switch_alloc(). The bug can be triggered by unplugging a thunderbolt device shortly after it is detected by the thunderbolt driver. Clear sw->drom if tb_drom_read() fails. [bhelgaas: add Fixes:, stable versions of interest] Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.") Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas CC: Lukas Wunner Signed-off-by: Greg Kroah-Hartman commit f131e8e07c4ff651a4a2508b9f2cc3a52708b9ab Author: Bart Van Assche Date: Tue Apr 12 14:39:18 2016 -0700 IB/srp: Fix a debug kernel crash commit 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream. Avoid that the following BUG() is triggered against a debug kernel: kernel BUG at include/linux/scatterlist.h:92! RIP: 0010:[] [] srp_map_idb+0x199/0x1a0 [ib_srp] Call Trace: [] srp_map_data+0x84a/0x890 [ib_srp] [] srp_queuecommand+0x1e4/0x610 [ib_srp] [] scsi_dispatch_cmd+0x9e/0x180 [] scsi_request_fn+0x477/0x610 [] __blk_run_queue+0x2e/0x40 [] blk_delay_work+0x20/0x30 [] process_one_work+0x197/0x480 [] worker_thread+0x49/0x490 [] kthread+0xea/0x100 [] ret_from_fork+0x22/0x40 Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API") Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Christoph Hellwig Reviewed-by: Max Gurtovoy Reviewed-by: Sagi Grimberg Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 61178531d925bf8570ec410e9a7325e916bb44e8 Author: Hui Wang Date: Wed May 25 12:12:32 2016 +0800 ALSA: hda - Fix headset mic detection problem for one Dell machine commit 86c72d1ce91d804e4fa8d90b316a89597dd220f1 upstream. Add the pin configuration value of this machine into the pin_quirk table to make DELL1_MIC_NO_PRESENCE apply to this machine. Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6d9457b2cd6582572b1bbbcaa0ff30183fce8508 Author: Kailang Yang Date: Tue May 24 16:46:07 2016 +0800 ALSA: hda/realtek - Add support for ALC295/ALC3254 commit 7d727869c7b86da0874436ac5675dcdadaf3a0a1 upstream. Add support for ALC295/ALC3254. They are simply compatible with ALC225 chip. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5caee70f29c812da8e0da39980f79e1cb171e82d Author: Kai-Heng Feng Date: Fri May 20 15:47:23 2016 +0800 ALSA: hda - Fix headphone noise on Dell XPS 13 9360 commit 423cd785619ac6778252fbdb916505aa1c153959 upstream. The headphone has noise when playing sound or switching microphone sources. It uses the same codec on XPS 13 9350, but with different subsystem ID. Applying the fixup can solve the issue. Also, changing the model name to better differentiate models. v2: Reorder by device ID. Signed-off-by: Kai-Heng Feng Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 960dfcb4684b93337d5c57429c049f672bd1704a Author: Kailang Yang Date: Wed May 4 15:50:18 2016 +0800 ALSA: hda/realtek - New codecs support for ALC234/ALC274/ALC294 commit dcd4f0db6141d6bf2cb897309d5d6f53d1b1696f upstream. Support new codecs for ALC234/ALC274/ALC294. This three codecs was the same IC. But bonding is not the same. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a2cdcb8296b549b250396d5056ddc28672b3db6f Author: Andreas Werner Date: Tue May 3 12:42:00 2016 +0200 mcb: Fixed bar number assignment for the gdd commit f75564d343010b025301d9548f2304f48eb25f01 upstream. The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by: Andreas Werner Fixes: '3764e82e5' drivers: Introduce MEN Chameleon Bus Signed-off-by: Johannes Thumshirn Signed-off-by: Greg Kroah-Hartman commit e0a343f02800b9a7b6990a8891483f8a16b7dbef Author: Lucas Stach Date: Tue May 3 19:15:58 2016 +0200 watchdog: sp5100_tco: properly check for new register layouts commit 46856fabe40cc80f92134683cdec7dc0fc8f4000 upstream. Commits 190aa4304de6 (Add AMD Mullins platform support) and cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the driver on a lot more devices, but the following commit missed a single location in the code when checking if the SB800 register offsets should be used. This leads to the wrong register being written which in turn causes ACPI to go haywire. Fix this by introducing a helper function to check for the new register layout and use this consistently. https://bugzilla.kernel.org/show_bug.cgi?id=114201 https://bugzilla.redhat.com/show_bug.cgi?id=1329910 Fixes: bdecfcdb5461 (sp5100_tco: fix the device check for SB800 and later chipsets) Signed-off-by: Lucas Stach Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 93900a7af2cd2288b5f0d209d467350beede9cf6 Author: Martin Sperl Date: Mon Feb 29 11:39:18 2016 +0000 clk: bcm2835: add locking to pll*_on/off methods commit ec36a5c6682fdd5328abf15c3c67281bed0241d7 upstream. Add missing locking to: * bcm2835_pll_divider_on * bcm2835_pll_divider_off to protect the read modify write cycle for the register access protecting both cm_reg and a2w_reg registers. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Martin Sperl Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman commit acc55cf5339a99389669139f83463ada2b1a6559 Author: Peter Zijlstra Date: Fri May 20 18:04:36 2016 +0200 locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait() commit 54cf809b9512be95f53ed4a5e3b631d1ac42f0fa upstream. Similar to commits: 51d7d5205d33 ("powerpc: Add smp_mb() to arch_spin_is_locked()") d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers") qspinlock suffers from the fact that the _Q_LOCKED_VAL store is unordered inside the ACQUIRE of the lock. And while this is not a problem for the regular mutual exclusive critical section usage of spinlocks, it breaks creative locking like: spin_lock(A) spin_lock(B) spin_unlock_wait(B) if (!spin_is_locked(A)) do_something() do_something() In that both CPUs can end up running do_something at the same time, because our _Q_LOCKED_VAL store can drop past the spin_unlock_wait() spin_is_locked() loads (even on x86!!). To avoid making the normal case slower, add smp_mb()s to the less used spin_unlock_wait() / spin_is_locked() side of things to avoid this problem. Reported-and-tested-by: Davidlohr Bueso Reported-by: Giovanni Gherdovich Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5637fc0d84fc4dd499b4f59ea2390175ca154906 Author: Chanwoo Choi Date: Thu Apr 21 18:58:31 2016 +0900 serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios() commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream. This patch fixes the broken serial log when changing the clock source of uart device. Before disabling the original clock source, this patch enables the new clock source to protect the clock off state for a split second. Signed-off-by: Chanwoo Choi Reviewed-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Krzysztof Kozlowski commit 33414f17f85d037ec4b1033391aa6b48dfcaa560 Author: Andy Shevchenko Date: Mon Apr 4 17:35:10 2016 +0300 serial: 8250_mid: recognize interrupt source in handler commit c42850f1ae7e70056f852e67bb9dddf927853b47 upstream. There is a special register that shows interrupt status by source. In particular case the source can be a combination of DMA Tx, DMA Rx, and UART. Read the register and call the handlers only for sources that request an interrupt. Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 7c8fcc9083c0e917e968072a0ed041f8fe1b4c70 Author: Andy Shevchenko Date: Mon Apr 4 17:35:09 2016 +0300 serial: 8250_mid: use proper bar for DNV platform commit 107e15fc1f8d6ef69eac5f175971252f76e82f0d upstream. Unlike Intel Medfield and Tangier platforms DNV uses PCI BAR0 for IO compatible resources and BAR1 for MMIO. We need latter in a way to support DMA. Introduce an additional field in the internal structure and pass PCI BAR based on device ID. Reported-by: "Lai, Poey Seng" Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Reviewed-by: Heikki Krogerus Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit b12e9085e3f51258481604c4c12af523dd1e5247 Author: David Müller Date: Wed Apr 27 11:58:32 2016 +0200 serial: 8250_pci: fix divide error bug if baud rate is 0 commit 6f210c18c1c0f016772c8cd51ae12a02bfb9e7ef upstream. Since commit 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Signed-off-by: David Müller Fixes: 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula") Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit af522524ca402d042e23bb88e919c40f0345dd91 Author: Brian Bloniarz Date: Sun Mar 6 13:16:30 2016 -0800 Fix OpenSSH pty regression on close commit 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa upstream. OpenSSH expects the (non-blocking) read() of pty master to return EAGAIN only if it has received all of the slave-side output after it has received SIGCHLD. This used to work on pre-3.12 kernels. This fix effectively forces non-blocking read() and poll() to block for parallel i/o to complete for all ttys. It also unwinds these changes: 1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12 tty: Fix pty master read() after slave closes 2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73 pty, n_tty: Simplify input processing on final close 3) 1a48632ffed61352a7810ce089dc5a8bcd505a60 pty: Fix input race when closing Inspired by analysis and patch from Marc Aurele La France Reported-by: Volth Reported-by: Marc Aurele La France BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52 BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492 Signed-off-by: Brian Bloniarz Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 48ce2de680d524fa5487cdc1f4683c278c6bd170 Author: Alexandre Belloni Date: Tue Apr 12 14:51:40 2016 +0200 tty/serial: atmel: fix hardware handshake selection commit 5be605ac9af979265d7b64c160ad9928088a78be upstream. Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") actually allowed to enable hardware handshaking. Before, the CRTSCTS flags was silently ignored. As the DMA controller can't drive RTS (as explain in the commit message). Ensure that hardware flow control stays disabled when DMA is used and FIFOs are not available. Signed-off-by: Alexandre Belloni Acked-by: Nicolas Ferre Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by: Greg Kroah-Hartman commit c7308a84fe663ad4de28c42fe2bcd273746fbb4b Author: Jiri Slaby Date: Tue Mar 22 18:09:51 2016 +0100 TTY: n_gsm, fix false positive WARN_ON commit d175feca89a1c162f60f4e3560ca7bc9437c65eb upstream. Dmitry reported, that the current cleanup code in n_gsm can trigger a warning: WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0() ... Call Trace: ... [] warn_slowpath_null+0x29/0x30 kernel/panic.c:490 [] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048 [] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386 [] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447 [] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883 ... But this is a legal path when open fails to find a space in the gsm_mux array and tries to clean up. So make it a standard test instead of a warning. Reported-by: "Dmitry Vyukov" Cc: Alan Cox Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()") Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit c0a561b4eaa9a24f5ffcef658b82defe8f84f068 Author: Jiri Slaby Date: Tue May 3 17:05:54 2016 +0200 tty: vt, return error when con_startup fails commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 upstream. When csw->con_startup() fails in do_register_con_driver, we return no error (i.e. 0). This was changed back in 2006 by commit 3e795de763. Before that we used to return -ENODEV. So fix the return value to be -ENODEV in that case again. Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT console") Signed-off-by: Jiri Slaby Reported-by: "Dan Carpenter" Signed-off-by: Greg Kroah-Hartman commit f21a3ff053d11bd9442b6ae7f51503bc5b373feb Author: Stefano Stabellini Date: Wed Apr 20 14:15:01 2016 +0100 xen/x86: actually allocate legacy interrupts on PV guests commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 upstream. b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number of legacy interrupts when actually nr_legacy_irqs() returns 0 after probe_8259A(). Use NR_IRQS_LEGACY instead. Signed-off-by: Stefano Stabellini Signed-off-by: Greg Kroah-Hartman commit caa2ca520f0d0cb963f5d0a18cbcd7cdfd1f1b0d Author: Paolo Bonzini Date: Mon Mar 21 12:33:00 2016 +0100 KVM: x86: mask CPUID(0xD,0x1).EAX against host value commit 316314cae15fb0e3869b76b468f59a0c83ac3d4e upstream. This ensures that the guest doesn't see XSAVE extensions (e.g. xgetbv1 or xsavec) that the host lacks. Cc: stable@vger.kernel.org Reviewed-by: Radim Krčmář [4.5 does have CPUID_D_1_EAX, but earlier kernels don't, so use the numeric value. This is consistent with other occurrences of cpuid_mask in arch/x86/kvm/cpuid.c - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f9c9ade6b859d50a4b186ac45793fa0d0e7698e9 Author: James Hogan Date: Fri Apr 22 10:38:46 2016 +0100 MIPS: KVM: Fix timer IRQ race when writing CP0_Compare commit b45bacd2d048f405c7760e5cc9b60dd67708734f upstream. Writing CP0_Compare clears the timer interrupt pending bit (CP0_Cause.TI), but this wasn't being done atomically. If a timer interrupt raced with the write of the guest CP0_Compare, the timer interrupt could end up being pending even though the new CP0_Compare is nowhere near CP0_Count. We were already updating the hrtimer expiry with kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and kvm_mips_resume_hrtimer(). Close the race window by expanding out kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting CP0_Compare between the freeze and resume. Since the pending timer interrupt should not be cleared when CP0_Compare is written via the KVM user API, an ack argument is added to distinguish the source of the write. Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit d2760fa98aac28d840d5041085a2ba39472d5a1f Author: James Hogan Date: Fri Apr 22 10:38:45 2016 +0100 MIPS: KVM: Fix timer IRQ race when freezing timer commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 upstream. There's a particularly narrow and subtle race condition when the software emulated guest timer is frozen which can allow a guest timer interrupt to be missed. This happens due to the hrtimer expiry being inexact, so very occasionally the freeze time will be after the moment when the emulated CP0_Count transitions to the same value as CP0_Compare (so an IRQ should be generated), but before the moment when the hrtimer is due to expire (so no IRQ is generated). The IRQ won't be generated when the timer is resumed either, since the resume CP0_Count will already match CP0_Compare. With VZ guests in particular this is far more likely to happen, since the soft timer may be frozen frequently in order to restore the timer state to the hardware guest timer. This happens after 5-10 hours of guest soak testing, resulting in an overflow in guest kernel timekeeping calculations, hanging the guest. A more focussed test case to intentionally hit the race (with the help of a new hypcall to cause the timer state to migrated between hardware & software) hits the condition fairly reliably within around 30 seconds. Instead of relying purely on the inexact hrtimer expiry to determine whether an IRQ should be generated, read the guest CP0_Compare and directly check whether the freeze time is before or after it. Only if CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to determine whether the last IRQ has already been generated (which will have pushed back the expiry by one timer period). Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit dc7ecfc8bc1e86990f83e5ee3a7fb5471f5dea7a Author: Bruce Rogers Date: Thu Apr 28 14:49:21 2016 -0600 KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset commit f24632475d4ffed5626abbfab7ef30a128dd1474 upstream. Commit d28bc9dd25ce reversed the order of two lines which initialize cr0, allowing the current (old) cr0 value to mess up vcpu initialization. This was observed in the checks for cr0 X86_CR0_WP bit in the context of kvm_mmu_reset_context(). Besides, setting vcpu->arch.cr0 after vmx_set_cr0() is completely redundant. Change the order back to ensure proper vcpu initialization. The combination of booting with ovmf firmware when guest vcpus > 1 and kvm's ept=N option being set results in a VM-entry failure. This patch fixes that. Fixes: d28bc9dd25ce ("KVM: x86: INIT and reset sequences are different") Signed-off-by: Bruce Rogers Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit 2aecd84724e43ea2f962ba54e10b9f304c258d16 Author: Andy Honig Date: Tue May 17 17:41:47 2016 +0200 KVM: MTRR: remove MSR 0x2f8 commit 9842df62004f366b9fed2423e24df10542ee0dc5 upstream. MSR 0x2f8 accessed the 124th Variable Range MTRR ever since MTRR support was introduced by 9ba075a664df ("KVM: MTRR support"). 0x2f8 became harmful when 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs") shrinked the array of VR MTRRs from 256 to 8, which made access to index 124 out of bounds. The surrounding code only WARNs in this situation, thus the guest gained a limited read/write access to struct kvm_arch_vcpu. 0x2f8 is not a valid VR MTRR MSR, because KVM has/advertises only 16 VR MTRR MSRs, 0x200-0x20f. Every VR MTRR is set up using two MSRs, 0x2f8 was treated as a PHYSBASE and 0x2f9 would be its PHYSMASK, but 0x2f9 was not implemented in KVM, therefore 0x2f8 could never do anything useful and getting rid of it is safe. This fixes CVE-2016-3713. Fixes: 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs") Reported-by: David Matlack Signed-off-by: Andy Honig Signed-off-by: Radim Krčmář Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 90566b26b924c0679401ca23dbd0a1785156c488 Author: H Hartley Sweeten Date: Fri Apr 8 10:14:58 2016 -0700 staging: comedi: das1800: fix possible NULL dereference commit d375278d666760e195693b57415ba0a125cadd55 upstream. DMA is optional with this driver. If it was not enabled the devpriv->dma pointer will be NULL. Fix the possible NULL pointer dereference when trying to disable the DMA channels in das1800_ai_cancel() and tidy up the comments to fix the checkpatch.pl issues: WARNING: line over 80 characters It's probably harmless in das1800_ai_setup_dma() because the 'desc' pointer will not be used if DMA is disabled but fix it there also. Fixes: 99dfc3357e98 ("staging: comedi: das1800: remove depends on ISA_DMA_API limitation") Signed-off-by: H Hartley Sweeten Reviewed-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 0b5eec3abd40b3df725dc03a5e2aad77a1f71091 Author: Yoshihiro Shimoda Date: Mon Apr 18 16:53:38 2016 +0900 usb: gadget: udc: core: Fix argument of dev_err() in usb_gadget_map_request() commit 5096c4d3bfa75bdd23c78f799aabd08598afb48f upstream. The argument of dev_err() in usb_gadget_map_request() should be dev instead of &gadget->dev. Fixes: 7ace8fc ("usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Greg Kroah-Hartman commit eebaba39da46bc901d837aa0765509873dd9fbbe Author: Alan Stern Date: Fri Apr 29 15:25:17 2016 -0400 USB: leave LPM alone if possible when binding/unbinding interface drivers commit 6fb650d43da3e7054984dc548eaa88765a94d49f upstream. When a USB driver is bound to an interface (either through probing or by claiming it) or is unbound from an interface, the USB core always disables Link Power Management during the transition and then re-enables it afterward. The reason is because the driver might want to prevent hub-initiated link power transitions, in which case the HCD would have to recalculate the various LPM parameters. This recalculation takes place when LPM is re-enabled and the new parameters are sent to the device and its parent hub. However, if the driver does not want to prevent hub-initiated link power transitions then none of this work is necessary. The parameters don't need to be recalculated, and LPM doesn't need to be disabled and re-enabled. It turns out that disabling and enabling LPM can be time-consuming, enough so that it interferes with user programs that want to claim and release interfaces rapidly via usbfs. Since the usbfs kernel driver doesn't set the disable_hub_initiated_lpm flag, we can speed things up and get the user programs to work by leaving LPM alone whenever the flag isn't set. And while we're improving the way disable_hub_initiated_lpm gets used, let's also fix its kerneldoc. Signed-off-by: Alan Stern Tested-by: Matthew Giassa CC: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 4ca637d3b896506fd67faacbfc6ce77019122255 Author: Mathias Nyman Date: Mon May 2 11:39:03 2016 +0300 usb: misc: usbtest: fix pattern tests for scatterlists. commit cdc77c82a8286b1181b81b6e5ef60c8e83ded7bc upstream. The current implemenentation restart the sent pattern for each entry in the sg list. The receiving end expects a continuous pattern, and test will fail unless scatterilst entries happen to be aligned with the pattern Fix this by calculating the pattern byte based on total sent size instead of just the current sg entry. Signed-off-by: Mathias Nyman Fixes: 8b5249019352 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing") Acked-by: Felipe Balbi Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit c734ed035cc8122ca7cb25b785851c96dea01162 Author: Michal Nazarewicz Date: Fri Apr 8 10:24:11 2016 +0200 usb: f_mass_storage: test whether thread is running before starting another commit f78bbcae86e676fad9e6c6bb6cd9d9868ba23696 upstream. When binding the function to usb_configuration, check whether the thread is running before starting another one. Without that, when function instance is added to multiple configurations, fsg_bing starts multiple threads with all but the latest one being forgotten by the driver. This leads to obvious thread leaks, possible lockups when trying to halt the machine and possible more issues. This fixes issues with legacy/multi¹ gadget as well as configfs gadgets when mass_storage function is added to multiple configurations. This change also simplifies API since the legacy gadgets no longer need to worry about starting the thread by themselves (which was where bug in legacy/multi was in the first place). N.B., this patch doesn’t address adding single mass_storage function instance to a single configuration twice. Thankfully, there’s no legitimate reason for such setup plus, if I’m not mistaken, configfs gadget doesn’t even allow it to be expressed. ¹ I have no example failure though. Conclusion that legacy/multi has a bug is based purely on me reading the code. Acked-by: Alan Stern Signed-off-by: Michal Nazarewicz Tested-by: Ivaylo Dimitrov Cc: Alan Stern Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit baee2dc1110a985c93f65edb9c6fe4080da45e7d Author: Lars-Peter Clausen Date: Wed Mar 30 13:49:14 2016 +0200 usb: gadget: f_fs: Fix EFAULT generation for async read operations commit 332a5b446b7916d272c2a659a3b20909ce34d2c1 upstream. In the current implementation functionfs generates a EFAULT for async read operations if the read buffer size is larger than the URB data size. Since a application does not necessarily know how much data the host side is going to send it typically supplies a buffer larger than the actual data, which will then result in a EFAULT error. This behaviour was introduced while refactoring the code to use iov_iter interface in commit c993c39b8639 ("gadget/function/f_fs.c: use put iov_iter into io_data"). The original code took the minimum over the URB size and the user buffer size and then attempted to copy that many bytes using copy_to_user(). If copy_to_user() could not copy all data a EFAULT error was generated. Restore the original behaviour by only generating a EFAULT error when the number of bytes copied is not the size of the URB and the target buffer has not been fully filled. Commit 342f39a6c8d3 ("usb: gadget: f_fs: fix check in read operation") already fixed the same problem for the synchronous read path. Fixes: c993c39b8639 ("gadget/function/f_fs.c: use put iov_iter into io_data") Acked-by: Michal Nazarewicz Signed-off-by: Lars-Peter Clausen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 02d6edb426aa15c0625a8aff5b868a367d641d76 Author: Lei Liu Date: Wed May 4 16:34:22 2016 +0800 USB: serial: option: add even more ZTE device ids commit 74d2a91aec97ab832790c9398d320413ad185321 upstream. Add even more ZTE device ids. Signed-off-by: lei liu [johan: rebase and replace commit message ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8680d2133e3436ed238a299b589690ce36b768af Author: lei liu Date: Tue May 3 14:44:19 2016 -0700 USB: serial: option: add more ZTE device ids commit f0d09463c59c2d764a6c6d492cbe6d2c77f27153 upstream. More ZTE device ids. Signed-off-by: lei liu [properly sort them - gregkh] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3a3013e43ed8819ecbe91544f275d549343af9a2 Author: Schemmel Hans-Christoph Date: Fri Apr 29 08:51:06 2016 +0000 USB: serial: option: add support for Cinterion PH8 and AHxx commit 444f94e9e625f6ec6bbe2cb232a6451c637f35a3 upstream. Added support for Gemalto's Cinterion PH8 and AHxx products with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface. In addition some minor renaming and formatting. Signed-off-by: Hans-Christoph Schemmel [johan: sort current entries and trim trailing whitespace ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c6bfe09e470a888e8db69abd4a6f38f0646cda23 Author: Johan Hovold Date: Sun May 8 20:07:57 2016 +0200 USB: serial: io_edgeport: fix memory leaks in probe error path commit c8d62957d450cc1a22ce3242908709fe367ddc8e upstream. URBs and buffers allocated in attach for Epic devices would never be deallocated in case of a later probe error (e.g. failure to allocate minor numbers) as disconnect is then never called. Fix by moving deallocation to release and making sure that the URBs are first unlinked. Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect, release") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 3a6b77bb95bd97ab5bb324961330cebc0992fd12 Author: Johan Hovold Date: Sun May 8 20:07:56 2016 +0200 USB: serial: io_edgeport: fix memory leaks in attach error path commit c5c0c55598cefc826d6cfb0a417eeaee3631715c upstream. Private data, URBs and buffers allocated for Epic devices during attach were never released on errors (e.g. missing endpoints). Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 6f4a028447d96953012a34a6118dbc957a71d0b4 Author: Johan Hovold Date: Sun May 8 20:08:02 2016 +0200 USB: serial: quatech2: fix use-after-free in probe error path commit 028c49f5e02a257c94129cd815f7c8485f51d4ef upstream. The interface read URB is submitted in attach, but was only unlinked by the driver at disconnect. In case of a late probe error (e.g. due to failed minor allocation), disconnect is never called and we would end up with active URBs for an unbound interface. This in turn could lead to deallocated memory being dereferenced in the completion callback. Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c1c806a8e7ad2e04030e3e388509b5d78137270d Author: Johan Hovold Date: Sun May 8 20:07:58 2016 +0200 USB: serial: keyspan: fix use-after-free in probe error path commit 35be1a71d70775e7bd7e45fa6d2897342ff4c9d2 upstream. The interface instat and indat URBs were submitted in attach, but never unlinked in release before deallocating the corresponding transfer buffers. In the case of a late probe error (e.g. due to failed minor allocation), disconnect would not have been called before release, causing the buffers to be freed while the URBs are still in use. We'd also end up with active URBs for an unbound interface. Fixes: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect, release") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 30323c980ccbe9e4624662ac3380a40c59088072 Author: Johan Hovold Date: Sun May 8 20:08:01 2016 +0200 USB: serial: mxuport: fix use-after-free in probe error path commit 9e45284984096314994777f27e1446dfbfd2f0d7 upstream. The interface read and event URBs are submitted in attach, but were never explicitly unlinked by the driver. Instead the URBs would have been killed by usb-serial core on disconnect. In case of a late probe error (e.g. due to failed minor allocation), disconnect is never called and we could end up with active URBs for an unbound interface. This in turn could lead to deallocated memory being dereferenced in the completion callbacks. Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX driver") Signed-off-by: Johan Hovold Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 8b7c5de8b628d7c371be9a7cabc43c9b3f2d1661 Author: Alexander Usyskin Date: Tue May 3 18:54:21 2016 -0400 mei: bus: call mei_cl_read_start under device lock commit bc46b45a421a64a0895dd41a34d3d2086e1ac7f6 upstream. Ensure that mei_cl_read_start is called under the device lock also in the bus layer. The function updates global ctrl_wr_list which should be locked. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 0823125460517e607a9607572c20a871a3516998 Author: Alexander Usyskin Date: Sun Apr 17 12:16:04 2016 -0400 mei: amthif: discard not read messages commit 9d04ee11db7bf0d848266cbfd7db336097a0e239 upstream. When a message is received and amthif client is not in reading state the message is ignored and left dangling in the queue. This may happen after one of the amthif host connections is closed w/o completing the reading. Another client will pick up a wrong message on next read attempt which will lead to link reset. To prevent this the driver has to properly discard the message when amthif client is not in reading state. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 8b67d24bdbfd70885f28fa1f799540da46a11d2a Author: Alexander Usyskin Date: Sun Apr 17 12:16:03 2016 -0400 mei: fix NULL dereferencing during FW initiated disconnection commit 6a8d648c8d1824117a9e9edb948ed1611fb013c0 upstream. In the case when disconnection is initiated from the FW the driver is flushing items from the write control list while iterating over it: mei_irq_write_handler() list_for_each_entry_safe(ctrl_wr_list) <-- outer loop mei_cl_irq_disconnect_rsp() mei_cl_set_disconnected() mei_io_list_flush(ctrl_wr_list) <-- destorying list We move the list flushing to the completion routine. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 42c021d1bfe919e6b2fe36a0de74b539dae6c4fc Author: Takashi Iwai Date: Thu Apr 14 17:32:19 2016 +0200 Bluetooth: vhci: Fix race at creating hci device commit c7c999cb18da88a881e10e07f0724ad0bfaff770 upstream. hci_vhci driver creates a hci device object dynamically upon each HCI_VENDOR_PKT write. Although it checks the already created object and returns an error, it's still racy and may build multiple hci_dev objects concurrently when parallel writes are performed, as the device tracks only a single hci_dev object. This patch introduces a mutex to protect against the concurrent device creations. Signed-off-by: Takashi Iwai Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit d071b444851fa2bd2e2fa7f16eb54876b1d36397 Author: Jiri Slaby Date: Sat Mar 19 11:49:43 2016 +0100 Bluetooth: vhci: purge unhandled skbs commit 13407376b255325fa817798800117a839f3aa055 upstream. The write handler allocates skbs and queues them into data->readq. Read side should read them, if there is any. If there is none, skbs should be dropped by hdev->flush. But this happens only if the device is HCI_UP, i.e. hdev->power_on work was triggered already. When it was not, skbs stay allocated in the queue when /dev/vhci is closed. So purge the queue in ->release. Program to reproduce: #include #include #include #include #include #include #include int main() { char buf[] = { 0xff, 0 }; struct iovec iov = { .iov_base = buf, .iov_len = sizeof(buf), }; int fd; while (1) { fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(50); if (writev(fd, &iov, 1) < 0) err(1, "writev"); usleep(50); close(fd); } return 0; } Result: kmemleak: 4609 new suspected memory leaks unreferenced object 0xffff88059f4d5440 (size 232): comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s) hex dump (first 32 bytes): 20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff .#..... .#..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: ... [] __alloc_skb+0x0/0x5a0 [] vhci_create_device+0x5c/0x580 [hci_vhci] [] vhci_write+0x306/0x4c8 [hci_vhci] Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit e2b5fee43d27733bc417dae40e107efab22c8ba0 Author: Jiri Slaby Date: Sat Mar 19 11:05:18 2016 +0100 Bluetooth: vhci: fix open_timeout vs. hdev race commit 373a32c848ae3a1c03618517cce85f9211a6facf upstream. Both vhci_get_user and vhci_release race with open_timeout work. They both contain cancel_delayed_work_sync, but do not test whether the work actually created hdev or not. Since the work can be in progress and _sync will wait for finishing it, we can have data->hdev allocated when cancel_delayed_work_sync returns. But the call sites do 'if (data->hdev)' *before* cancel_delayed_work_sync. As a result: * vhci_get_user allocates a second hdev and puts it into data->hdev. The former is leaked. * vhci_release does not release data->hdev properly as it thinks there is none. Fix both cases by moving the actual test *after* the call to cancel_delayed_work_sync. This can be hit by this program: #include #include #include #include #include #include #include #include int main(int argc, char **argv) { int fd; srand(time(NULL)); while (1) { const int delta = (rand() % 200 - 100) * 100; fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(1000000 + delta); close(fd); } return 0; } And the result is: BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228 Read of size 8 by task kworker/u13:1/32068 ============================================================================= BUG kmalloc-192 (Tainted: G E ): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040 ... kmem_cache_alloc_trace+0x150/0x190 vhci_open+0x50/0x330 [hci_vhci] misc_open+0x35b/0x4e0 chrdev_open+0x23b/0x510 ... INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040 ... __slab_free+0x204/0x310 vhci_release+0xa4/0xd0 [hci_vhci] ... INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080 INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600 Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00 ...k............ Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff ...k.......k.... Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff .F.k.....F.k.... Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 ................ Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff @..k....@..k.... Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de P.n............. Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00 .........b...... Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff ........8..k.... Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00 .. ............. Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff ...........=.... Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . .............. Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb ........ Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00 ........ CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G B E 4.4.6-0-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014 Workqueue: hci0 hci_cmd_work [bluetooth] 00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180 ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320 ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80 Call Trace: ... [] ? skb_queue_tail+0x13e/0x150 [] ? vhci_send_frame+0xac/0x100 [hci_vhci] [] ? hci_send_frame+0x188/0x320 [bluetooth] [] ? hci_cmd_work+0x115/0x310 [bluetooth] [] ? process_one_work+0x815/0x1340 [] ? worker_thread+0xe5/0x11f0 [] ? process_one_work+0x1340/0x1340 [] ? kthread+0x1c8/0x230 ... Memory state around the buggy address: ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby Signed-off-by: Marcel Holtmann Cc: Dmitry Vyukov Signed-off-by: Greg Kroah-Hartman commit 4f0699a50407a96a31f67050dda11debb52650ee Author: Adrian Hunter Date: Fri May 20 10:33:47 2016 +0300 mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers commit 822969369482166050c5b2f7013501505e025c39 upstream. The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 67bfab0a4c0ea829d51d7cb20db7da7be04caa42 Author: Matt Gumbel Date: Fri May 20 10:33:46 2016 +0300 mmc: longer timeout for long read time quirk commit 32ecd320db39bcb007679ed42f283740641b81ea upstream. 008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by: Matt Gumbel Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit fe76487efabef700daff6b0f92776354f09c1c4c Author: Gabriele Mazzotta Date: Tue May 24 22:53:08 2016 +0200 dell-rbtn: Ignore ACPI notifications if device is suspended commit ff8651237f39cea60dc89b2d9f25d9ede3fc82c0 upstream. Some BIOSes unconditionally send an ACPI notification to RBTN when the system is resuming from suspend. This makes dell-rbtn send an input event to userspace as if a function key was pressed. Prevent this by ignoring all the notifications received while the device is suspended. Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031 Signed-off-by: Gabriele Mazzotta Tested-by: Alex Hung Reviewed-by: Pali Rohár Signed-off-by: Darren Hart Signed-off-by: Greg Kroah-Hartman commit 3d5a41e4b3aa0f91c4f216c1bdec5c7a35455397 Author: Lv Zheng Date: Tue May 3 16:48:20 2016 +0800 ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 upstream. The order of the _OSI related functionalities is as follows: acpi_blacklisted() acpi_dmi_osi_linux() acpi_osi_setup() acpi_osi_setup() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< parse_args() __setup("acpi_osi=") acpi_osi_setup_linux() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< acpi_early_init() acpi_initialize_subsystem() acpi_ut_initialize_interfaces() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ acpi_bus_init() acpi_os_initialize1() acpi_install_interface_handler(acpi_osi_handler) acpi_osi_setup_late() acpi_update_interfaces() for "!" >>>>>>>>>>>>>>>>>>>>>>>> acpi_osi_handler() Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command line setting can override the DMI detection. That's why acpi_blacklisted() is put before __setup("acpi_osi="). Then we can notice the following wrong invocation order. There are acpi_update_interfaces() (marked by <<<<) calls invoked before acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible to use acpi_osi=!* correctly from OSI DMI table or from the command line. The use of acpi_osi=!* is meant to disable both ACPICA (acpi_gbl_supported_interfaces) and Linux specific strings (osi_setup_entries) while the ACPICA part should have stopped working because of the order issue. This patch fixes this issue by moving acpi_update_interfaces() to where it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux specific strings are still handled in the original place in order to make the following command line working: acpi_osi=!* acpi_osi="Module Device". Note that since acpi_osi=!* is meant to further disable linux specific string comparing to the acpi_osi=!, there is no such use case in our bug fixing work and hence there is no one using acpi_osi=!* either from the command line or from the DMI quirks, this issue is just a theoretical issue. Fixes: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings) Tested-by: Lukas Wunner Tested-by: Chen Yu Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 96b9a9728452e7c551951903b40f1ba5b128445c Author: Adrian Hunter Date: Fri May 20 10:33:48 2016 +0300 mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers commit 265984b36ce82fec67957d452dd2b22e010611e4 upstream. The CMD19/CMD14 bus width test has been found to be unreliable in some cases. It is not essential, so simply remove it. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 36bb9f187f9c24294ff13e7e25fdb24ae82cfbd8 Author: Adrian Hunter Date: Thu May 19 15:25:42 2016 +0200 mmc: sdhci-acpi: Ensure connected devices are powered when probing commit e5bbf30733f930a1d17b4ccf19eac88e30a39cc7 upstream. Some devices connected to the SDHCI controller may have separate enabling lines that are controlled through GPIO. These devices need to be powered on and enabled before probing. This is to ensure all devices connected can be seen by the controller. Note, for "stable" this patch depends on the following change: commit 78a898d0e395 ("ACPI / PM: Export acpi_device_fix_up_power()") Signed-off-by: Adrian Hunter Reported-and-tested-by: Laszlo Fiat Signed-off-by: Ulf Hansson Reported-by: Laszlo Fiat Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571 Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit 10289eff6a3ee8b880b9b3e658b059e0bb0228a0 Author: Ulf Hansson Date: Thu May 19 15:25:41 2016 +0200 ACPI / PM: Export acpi_device_fix_up_power() commit 78a898d0e39513469858de990de83210fee28ee9 upstream. Drivers that needs acpi_device_fix_up_power(), allow them to be built as modules by exporting this function. Tested-by: Laszlo Fiat Signed-off-by: Ulf Hansson Acked-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 88295eda162d8ff85c52e06d75875c67dd94f530 Author: Adrian Hunter Date: Thu May 5 08:12:28 2016 +0300 mmc: mmc: Fix partition switch timeout for some eMMCs commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 upstream. Some eMMCs set the partition switch timeout too low. Now typically eMMCs are considered a critical component (e.g. because they store the root file system) and consequently are expected to be reliable. Thus we can neglect the use case where eMMCs can't switch reliably and we might want a lower timeout to facilitate speedy recovery. Although we could employ a quirk for the cards that are affected (if we could identify them all), as described above, there is little benefit to having a low timeout, so instead simply set a minimum timeout. The minimum is set to 300ms somewhat arbitrarily - the examples that have been seen had a timeout of 10ms but were sometimes taking 60-70ms. Signed-off-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4995078daa0dcc64242969d2aa727d445bb3e0b4 Author: Oliver Hartkopp Date: Mon Mar 21 20:18:21 2016 +0100 can: fix handling of unmodifiable configuration options commit bb208f144cf3f59d8f89a09a80efd04389718907 upstream. As described in 'can: m_can: tag current CAN FD controllers as non-ISO' (6cfda7fbebe) it is possible to define fixed configuration options by setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'. This leads to the incovenience that the fixed configuration bits can not be passed by netlink even when they have the correct values (e.g. non-ISO, FD). This patch fixes that issue and not only allows fixed set bit values to be set again but now requires(!) to provide these fixed values at configuration time. A valid CAN FD configuration consists of a nominal/arbitration bittiming, a data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now enforced by a new can_validate() function. This fix additionally removed the inconsistency that was prohibiting the support of 'CANFD-only' controller drivers, like the RCar CAN FD. For this reason a new helper can_set_static_ctrlmode() has been introduced to provide a proper interface to handle static enabled CAN controller options. Reported-by: Ramesh Shanmugasundaram Signed-off-by: Oliver Hartkopp Reviewed-by: Ramesh Shanmugasundaram Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 085e706eba3fe0c92b89c55f38b9cb9318d48225 Author: Christophe Ricard Date: Sat Apr 30 09:12:34 2016 +0200 nfc: st21nfca: Fix static checker warning commit b58afe6d6d3a53af165d5946f12c4b08c95acd58 upstream. Fix static checker warning: drivers/nfc/st21nfca/i2c.c:530 st21nfca_hci_i2c_acpi_request_resources() error: 'gpiod_ena' dereferencing possible ERR_PTR() Fix so that if no enable gpio can be retrieved an -ENODEV is returned. Reported-by: Dan Carpenter Fixes: dfa8070d7f64 ("nfc: st21nfca: Add support for acpi probing for i2c device.") Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit f0bbf31d63b86845500f8e2a6fcbe6e35f630636 Author: Marc Zyngier Date: Fri May 6 19:41:56 2016 +0100 irqchip/gic-v3: Configure all interrupts as non-secure Group-1 commit 7c9b973061b03af62734f613f6abec46c0dd4a88 upstream. The GICv3 driver wrongly assumes that it runs on the non-secure side of a secure-enabled system, while it could be on a system with a single security state, or a GICv3 with GICD_CTLR.DS set. Either way, it is important to configure this properly, or interrupts will simply not be delivered on this HW. Reported-by: Peter Maydell Tested-by: Peter Maydell Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 066b085d819dd8a1decba6119a7a068e9e5add86 Author: Will Deacon Date: Tue Apr 26 12:00:00 2016 +0100 irqchip/gic: Ensure ordering between read of INTACK and shared data commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 upstream. When an IPI is generated by a CPU, the pattern looks roughly like: smp_wmb(); On the receiving CPU we rely on the fact that, once we've taken the interrupt, then the freshly written shared data must be visible to us. Put another way, the CPU isn't going to speculate taking an interrupt. Unfortunately, this assumption turns out to be broken. Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy to read some shared_data. Before CPUx has done anything, a random peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised. CPUy then takes the IRQ and starts executing the entry code, heading towards gic_handle_irq. Furthermore, let's assume that a bunch of the previous interrupts handled by CPUy were SGIs, so the branch predictor kicks in and speculates that irqnr will be <16 and we're likely to head into handle_IPI. The prefetcher then grabs a speculative copy of shared_data which contains a stale value. Meanwhile, CPUx gets round to updating shared_data and asking the GIC to send an SGI to CPUy. Internally, the GIC decides that the SGI is more important than the peripheral interrupt (which hasn't yet been ACKed) but doesn't need to do anything to CPUy, because the IRQ line is already raised. CPUy then reads the ACK register on the GIC, sees the SGI value which confirms the branch prediction and we end up with a stale shared_data value. This patch fixes the problem by adding an smp_rmb() to the IPI entry code in gic_handle_irq. As it turns out, the combination of a control dependency and an ISB instruction from the EOI in the GICv3 driver is enough to provide the ordering we need, so we add a comment there justifying the absence of an explicit smp_rmb(). Signed-off-by: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit cb302f2a7d549b4d34432434622a7549a77a30cc Author: Manfred Schlaegl Date: Fri May 27 16:36:36 2016 -0700 Input: pwm-beeper - fix - scheduling while atomic commit f49cf3b8b4c841457244c461c66186a719e13bcc upstream. Pwm config may sleep so defer it using a worker. On a Freescale i.MX53 based board we ran into "BUG: scheduling while atomic" because input_inject_event locks interrupts, but imx_pwm_config_v2 sleeps. Tested on Freescale i.MX53 SoC with 4.6.0. Signed-off-by: Manfred Schlaegl Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 0f25db7acd51c5889de7bf0f09d1884461214179 Author: Roger Quadros Date: Mon May 9 11:28:37 2016 +0300 mfd: omap-usb-tll: Fix scheduling while atomic BUG commit b49b927f16acee626c56a1af4ab4cb062f75b5df upstream. We shouldn't be calling clk_prepare_enable()/clk_prepare_disable() in an atomic context. Fixes the following issue: [ 5.830970] ehci-omap: OMAP-EHCI Host Controller driver [ 5.830974] driver_register 'ehci-omap' [ 5.895849] driver_register 'wl1271_sdio' [ 5.896870] BUG: scheduling while atomic: udevd/994/0x00000002 [ 5.896876] 4 locks held by udevd/994: [ 5.896904] #0: (&dev->mutex){......}, at: [] __driver_attach+0x60/0xac [ 5.896923] #1: (&dev->mutex){......}, at: [] __driver_attach+0x70/0xac [ 5.896946] #2: (tll_lock){+.+...}, at: [] omap_tll_enable+0x2c/0xd0 [ 5.896966] #3: (prepare_lock){+.+...}, at: [] clk_prepare_lock+0x48/0xe0 [ 5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine [ 5.897048] Preemption disabled at:[< (null)>] (null) [ 5.897051] [ 5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233 [ 5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.897076] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 5.897087] [] (show_stack) from [] (dump_stack+0x88/0xc0) [ 5.897099] [] (dump_stack) from [] (__schedule_bug+0xac/0xd0) [ 5.897111] [] (__schedule_bug) from [] (__schedule+0x88/0x7e4) [ 5.897120] [] (__schedule) from [] (schedule+0x9c/0xc0) [ 5.897129] [] (schedule) from [] (schedule_preempt_disabled+0x14/0x20) [ 5.897140] [] (schedule_preempt_disabled) from [] (mutex_lock_nested+0x258/0x43c) [ 5.897150] [] (mutex_lock_nested) from [] (clk_prepare_lock+0x48/0xe0) [ 5.897160] [] (clk_prepare_lock) from [] (clk_prepare+0x10/0x28) [ 5.897169] [] (clk_prepare) from [] (omap_tll_enable+0x64/0xd0) [ 5.897180] [] (omap_tll_enable) from [] (usbhs_runtime_resume+0x18/0x17c) [ 5.897192] [] (usbhs_runtime_resume) from [] (pm_generic_runtime_resume+0x2c/0x40) [ 5.897202] [] (pm_generic_runtime_resume) from [] (__rpm_callback+0x38/0x68) [ 5.897210] [] (__rpm_callback) from [] (rpm_callback+0x70/0x88) [ 5.897218] [] (rpm_callback) from [] (rpm_resume+0x4ec/0x7ec) [ 5.897227] [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) [ 5.897236] [] (__pm_runtime_resume) from [] (driver_probe_device+0x30/0x70) [ 5.897246] [] (driver_probe_device) from [] (__driver_attach+0x88/0xac) [ 5.897256] [] (__driver_attach) from [] (bus_for_each_dev+0x50/0x84) [ 5.897267] [] (bus_for_each_dev) from [] (bus_add_driver+0xcc/0x1e4) [ 5.897276] [] (bus_add_driver) from [] (driver_register+0xac/0xf4) [ 5.897286] [] (driver_register) from [] (do_one_initcall+0x100/0x1b8) [ 5.897296] [] (do_one_initcall) from [] (do_init_module+0x58/0x1c0) [ 5.897304] [] (do_init_module) from [] (SyS_finit_module+0x88/0x90) [ 5.897313] [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x1c) [ 5.912697] ------------[ cut here ]------------ [ 5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58 [ 5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count()) Reported-by: H. Nikolaus Schaller Tested-by: H. Nikolaus Schaller Signed-off-by: Roger Quadros Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 2f53603676943ea29e70e850e17b7c4ca97d0e90 Author: Vik Heyndrickx Date: Thu Apr 28 20:46:28 2016 +0200 sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems commit 20878232c52329f92423d27a60e48b6a6389e0dd upstream. Systems show a minimal load average of 0.00, 0.01, 0.05 even when they have no load at all. Uptime and /proc/loadavg on all systems with kernels released during the last five years up until kernel version 4.6-rc5, show a 5- and 15-minute minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on idle systems, but the way the kernel calculates this value prevents it from getting lower than the mentioned values. Likewise but not as obviously noticeable, a fully loaded system with no processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95 (multiplied by number of cores). Once the (old) load becomes 93 or higher, it mathematically can never get lower than 93, even when the active (load) remains 0 forever. This results in the strange 0.00, 0.01, 0.05 uptime values on idle systems. Note: 93/2048 = 0.0454..., which rounds up to 0.05. It is not correct to add a 0.5 rounding (=1024/2048) here, since the result from this function is fed back into the next iteration again, so the result of that +0.5 rounding value then gets multiplied by (2048-2037), and then rounded again, so there is a virtual "ghost" load created, next to the old and active load terms. By changing the way the internally kept value is rounded, that internal value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon increasing load, the internally kept load value is rounded up, when the load is decreasing, the load value is rounded down. The modified code was tested on nohz=off and nohz kernels. It was tested on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was tested on single, dual, and octal cores system. It was tested on virtual hosts and bare hardware. No unwanted effects have been observed, and the problems that the patch intended to fix were indeed gone. Tested-by: Damien Wyart Signed-off-by: Vik Heyndrickx Signed-off-by: Peter Zijlstra (Intel) Cc: Doug Smythies Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes") Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.net Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 48bcb9abe77d8666257b16ef0949e1bb3103aad7 Author: Andy Gross Date: Tue May 3 15:24:11 2016 -0500 clk: qcom: msm8916: Fix crypto clock flags commit 2a0974aa1a0b40a92387ea03dbfeacfbc9ba182c upstream. This patch adds the CLK_SET_RATE_PARENT flag for the crypto core and ahb blocks. Without this flag, clk_set_rate can fail for certain frequency requests. Signed-off-by: Andy Gross Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 2f7bf345e38fd35c16da1bd1bad3843141a52949 Author: Corentin LABBE Date: Wed Mar 23 16:11:24 2016 +0100 crypto: sun4i-ss - Replace spinlock_bh by spin_lock_irq{save|restore} commit bdb6cf9f6fe6d9af905ea34b7c4bb78ea601329e upstream. The current sun4i-ss driver could generate data corruption when ciphering/deciphering. It occurs randomly on end of handled data. No root cause have been found and the only way to remove it is to replace all spin_lock_bh by their irq counterparts. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by: LABBE Corentin Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c3f955ab855526778802608dd55d9ce5a93d4e31 Author: Horia Geant? Date: Thu Apr 21 19:24:55 2016 +0300 crypto: talitos - fix ahash algorithms registration commit 3639ca840df953f9af6f15fc8a6bf77f19075ab1 upstream. Provide hardware state import/export functionality, as mandated by commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") Reported-by: Jonas Eymann Signed-off-by: Horia Geant? Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c51a35922749249cd06fa113b919a6ae4f317666 Author: Catalin Vasile Date: Fri May 6 16:18:53 2016 +0300 crypto: caam - fix caam_jr_alloc() ret code commit e930c765ca5c6b039cd22ebfb4504ea7b5dab43d upstream. caam_jr_alloc() used to return NULL if a JR device could not be allocated for a session. In turn, every user of this function used IS_ERR() function to verify if anything went wrong, which does NOT look for NULL values. This made the kernel crash if the sanity check failed, because the driver continued to think it had allocated a valid JR dev instance to the session and at some point it tries to do a caam_jr_free() on a NULL JR dev pointer. This patch is a fix for this issue. Signed-off-by: Catalin Vasile Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 40677f4ae0cb6ebaa1e2f631ee277e0be3379c31 Author: Steven Rostedt (Red Hat) Date: Fri May 13 09:34:12 2016 -0400 ring-buffer: Prevent overflow of size in ring_buffer_resize() commit 59643d1535eb220668692a5359de22545af579f6 upstream. If the size passed to ring_buffer_resize() is greater than MAX_LONG - BUF_PAGE_SIZE then the DIV_ROUND_UP() will return zero. Here's the details: # echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb tracing_entries_write() processes this and converts kb to bytes. 18014398509481980 << 10 = 18446744073709547520 and this is passed to ring_buffer_resize() as unsigned long size. size = DIV_ROUND_UP(size, BUF_PAGE_SIZE); Where DIV_ROUND_UP(a, b) is (a + b - 1)/b BUF_PAGE_SIZE is 4080 and here 18446744073709547520 + 4080 - 1 = 18446744073709551599 where 18446744073709551599 is still smaller than 2^64 2^64 - 18446744073709551599 = 17 But now 18446744073709551599 / 4080 = 4521260802379792 and size = size * 4080 = 18446744073709551360 This is checked to make sure its still greater than 2 * 4080, which it is. Then we convert to the number of buffer pages needed. nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE) but this time size is 18446744073709551360 and 2^64 - (18446744073709551360 + 4080 - 1) = -3823 Thus it overflows and the resulting number is less than 4080, which makes 3823 / 4080 = 0 an nr_pages is set to this. As we already checked against the minimum that nr_pages may be, this causes the logic to fail as well, and we crash the kernel. There's no reason to have the two DIV_ROUND_UP() (that's just result of historical code changes), clean up the code and fix this bug. Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 3386ffedba20156e5218d74a788ef9732ffa998d Author: Steven Rostedt (Red Hat) Date: Thu May 12 11:01:24 2016 -0400 ring-buffer: Use long for nr_pages to avoid overflow failures commit 9b94a8fba501f38368aef6ac1b30e7335252a220 upstream. The size variable to change the ring buffer in ftrace is a long. The nr_pages used to update the ring buffer based on the size is int. On 64 bit machines this can cause an overflow problem. For example, the following will cause the ring buffer to crash: # cd /sys/kernel/debug/tracing # echo 10 > buffer_size_kb # echo 8556384240 > buffer_size_kb Then you get the warning of: WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 rb_update_pages+0x22f/0x260 Which is: RB_WARN_ON(cpu_buffer, nr_removed); Note each ring buffer page holds 4080 bytes. This is because: 1) 10 causes the ring buffer to have 3 pages. (10kb requires 3 * 4080 pages to hold) 2) (2^31 / 2^10 + 1) * 4080 = 8556384240 The value written into buffer_size_kb is shifted by 10 and then passed to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760 3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE which is 4080. 8761737461760 / 4080 = 2147484672 4) nr_pages is subtracted from the current nr_pages (3) and we get: 2147484669. This value is saved in a signed integer nr_pages_to_update 5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int turns into the value of -2147482627 6) As the value is a negative number, in update_pages_handler() it is negated and passed to rb_remove_pages() and 2147482627 pages will be removed, which is much larger than 3 and it causes the warning because not all the pages asked to be removed were removed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001 Fixes: 7a8e76a3829f1 ("tracing: unified trace buffer") Reported-by: Hao Qin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f49e6af09aa878ef09c364b67c47fb417bea81e6 Author: John Stultz Date: Mon May 16 20:36:15 2016 -0700 asix: Fix offset calculation in asix_rx_fixup() causing slow transmissions commit cd9e2e5d3ff148be9ea210f622ce3e8e8292fcd6 upstream. In testing with HiKey, we found that since commit 3f30b158eba5 ("asix: On RX avoid creating bad Ethernet frames"), we're seeing lots of noise during network transfers: [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988 [ 239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x54ebb5ec, offset 4 [ 239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xcdffe7a2, offset 4 [ 239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988 [ 239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x1d36f59d, offset 4 [ 239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0xaef3c1e9, offset 4 [ 239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header synchronisation was lost, remaining 988 [ 239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x2881912, offset 4 [ 239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length 0x5638f7e2, offset 4 And network throughput ends up being pretty bursty and slow with a overall throughput of at best ~30kB/s (where as previously we got 1.1MB/s with the slower USB1.1 "full speed" host). We found the issue also was reproducible on a x86_64 system, using a "high-speed" USB2.0 port but the throughput did not measurably drop (possibly due to the scp transfer being cpu bound on my slow test hardware). After lots of debugging, I found the check added in the problematic commit seems to be calculating the offset incorrectly. In the normal case, in the main loop of the function, we do: (where offset is zero, or set to "offset += (copy_length + 1) & 0xfffe" in the previous loop) rx->header = get_unaligned_le32(skb->data + offset); offset += sizeof(u32); But the problematic patch calculates: offset = ((rx->remaining + 1) & 0xfffe) + sizeof(u32); rx->header = get_unaligned_le32(skb->data + offset); Adding some debug logic to check those offset calculation used to find rx->header, the one in problematic code is always too large by sizeof(u32). Thus, this patch removes the incorrect " + sizeof(u32)" addition in the problematic calculation, and resolves the issue. Cc: Dean Jenkins Cc: "David B. Robins" Cc: Mark Craske Cc: Emil Goode Cc: "David S. Miller" Cc: YongQin Liu Cc: Guodong Xu Cc: Ivan Vecera Cc: linux-usb@vger.kernel.org Cc: netdev@vger.kernel.org Reported-by: Yongqin Liu Signed-off-by: John Stultz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7c15728e5686b37fdf500bb93d388286bdfa92b9 Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication for the NTLM(v2) authentication commit 1a967d6c9b39c226be1b45f13acd4d8a5ab3dc44 upstream. Only server which map unknown users to guest will allow access using a non-null NTLMv2_Response. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e05a20e4efd4f5318d8bd53f48d856ddd2026bc3 Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication for the NTLM(v1) authentication commit 777f69b8d26bf35ade4a76b08f203c11e048365d upstream. Only server which map unknown users to guest will allow access using a non-null NTChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6b11a5c8def79b684c278c4472a4fbf974389ecb Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication for the LANMAN authentication commit fa8f3a354bb775ec586e4475bcb07f7dece97e0c upstream. Only server which map unknown users to guest will allow access using a non-null LMChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7e82a4bf3146ab16f1ed41ca7e2121897e293e00 Author: Stefan Metzmacher Date: Tue May 3 10:52:30 2016 +0200 fs/cifs: correctly to anonymous authentication via NTLMSSP commit cfda35d98298131bf38fbad3ce4cd5ecb3cf18db upstream. See [MS-NLMP] 3.2.5.1.2 Server Receives an AUTHENTICATE_MESSAGE from the Client: ... Set NullSession to FALSE If (AUTHENTICATE_MESSAGE.UserNameLen == 0 AND AUTHENTICATE_MESSAGE.NtChallengeResponse.Length == 0 AND (AUTHENTICATE_MESSAGE.LmChallengeResponse == Z(1) OR AUTHENTICATE_MESSAGE.LmChallengeResponse.Length == 0)) -- Special case: client requested anonymous authentication Set NullSession to TRUE ... Only server which map unknown users to guest will allow access using a non-null NTChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913 Signed-off-by: Stefan Metzmacher Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 402570569e3664e9f580ca2ae06edd763a674985 Author: Steve French Date: Thu May 12 21:20:36 2016 -0500 remove directory incorrectly tries to set delete on close on non-empty directories commit 897fba1172d637d344f009d700f7eb8a1fa262f1 upstream. Wrong return code was being returned on SMB3 rmdir of non-empty directory. For SMB3 (unlike for cifs), we attempt to delete a directory by set of delete on close flag on the open. Windows clients set this flag via a set info (SET_FILE_DISPOSITION to set this flag) which properly checks if the directory is empty. With this patch on smb3 mounts we correctly return "DIRECTORY NOT EMPTY" on attempts to remove a non-empty directory. Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman commit 80491592ca86f8f3f7bf81b5e554996c8c945219 Author: Matt Evans Date: Mon May 16 13:54:56 2016 +0100 kvm: arm64: Fix EC field in inject_abt64 commit e4fe9e7dc3828bf6a5714eb3c55aef6260d823a2 upstream. The EC field of the constructed ESR is conditionally modified by ORing in ESR_ELx_EC_DABT_LOW for a data abort. However, ESR_ELx_EC_SHIFT is missing from this condition. Signed-off-by: Matt Evans Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 45550cd5046db1fd021632524eceae0b483e4f0f Author: Marc Zyngier Date: Thu Apr 28 16:16:31 2016 +0100 arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f upstream. The ARM architecture mandates that when changing a page table entry from a valid entry to another valid entry, an invalid entry is first written, TLB invalidated, and only then the new entry being written. The current code doesn't respect this, directly writing the new entry and only then invalidating TLBs. Let's fix it up. Reported-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit be4945ad82f0257d327c47a75ba2d0c6250b5a1c Author: Julien Grall Date: Tue May 10 15:40:31 2016 +0100 arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str commit f228b494e56d949be8d8ea09d4f973d1979201bf upstream. The loop that browses the array compat_hwcap_str will stop when a NULL is encountered, however NULL is missing at the end of array. This will lead to overrun until a NULL is found somewhere in the following memory. In reality, this works out because the compat_hwcap2_str array tends to follow immediately in memory, and that *is* terminated correctly. Furthermore, the unsigned int compat_elf_hwcap is checked before printing each capability, so we end up doing the right thing because the size of the two arrays is less than 32. Still, this is an obvious mistake and should be fixed. Note for backporting: commit 12d11817eaafa414 ("arm64: Move /proc/cpuinfo handling code") moved this code in v4.4. Prior to that commit, the same change should be made in arch/arm64/kernel/setup.c. Fixes: 44b82b7700d0 "arm64: Fix up /proc/cpuinfo" Signed-off-by: Julien Grall Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 110339a2fabdbb568968827c7ba83280029ba539 Author: Catalin Marinas Date: Thu May 5 10:44:00 2016 +0100 arm64: Implement pmdp_set_access_flags() for hardware AF/DBM commit 282aa7051b0169991b34716f0f22d9c2f59c46c4 upstream. The update to the accessed or dirty states for block mappings must be done atomically on hardware with support for automatic AF/DBM. The ptep_set_access_flags() function has been fixed as part of commit 66dbd6e61a52 ("arm64: Implement ptep_set_access_flags() for hardware AF/DBM"). This patch brings pmdp_set_access_flags() in line with the pte counterpart. Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 05e0cd4b5f1490b048ccda254a2ff234d2a50e8f Author: Catalin Marinas Date: Wed Apr 13 16:01:22 2016 +0100 arm64: Implement ptep_set_access_flags() for hardware AF/DBM commit 66dbd6e61a526ae7d11a208238ae2c17e5cacb6b upstream. When hardware updates of the access and dirty states are enabled, the default ptep_set_access_flags() implementation based on calling set_pte_at() directly is potentially racy. This triggers the "racy dirty state clearing" warning in set_pte_at() because an existing writable PTE is overridden with a clean entry. There are two main scenarios for this situation: 1. The CPU getting an access fault does not support hardware updates of the access/dirty flags. However, a different agent in the system (e.g. SMMU) can do this, therefore overriding a writable entry with a clean one could potentially lose the automatically updated dirty status 2. A more complex situation is possible when all CPUs support hardware AF/DBM: a) Initial state: shareable + writable vma and pte_none(pte) b) Read fault taken by two threads of the same process on different CPUs c) CPU0 takes the mmap_sem and proceeds to handling the fault. It eventually reaches do_set_pte() which sets a writable + clean pte. CPU0 releases the mmap_sem d) CPU1 acquires the mmap_sem and proceeds to handle_pte_fault(). The pte entry it reads is present, writable and clean and it continues to pte_mkyoung() e) CPU1 calls ptep_set_access_flags() If between (d) and (e) the hardware (another CPU) updates the dirty state (clears PTE_RDONLY), CPU1 will override the PTR_RDONLY bit marking the entry clean again. This patch implements an arm64-specific ptep_set_access_flags() function to perform an atomic update of the PTE flags. Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") Signed-off-by: Catalin Marinas Reported-by: Ming Lei Tested-by: Julien Grall Cc: Will Deacon [will: reworded comment] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 97fc1b996f9ad1a77bc6bb2127f5002c66e66c5f Author: Catalin Marinas Date: Thu May 5 10:44:02 2016 +0100 arm64: Ensure pmd_present() returns false after pmd_mknotpresent() commit 5bb1cc0ff9a6b68871970737e6c4c16919928d8b upstream. Currently, pmd_present() only checks for a non-zero value, returning true even after pmd_mknotpresent() (which only clears the type bits). This patch converts pmd_present() to using pte_present(), similar to the other pmd_*() checks. As a side effect, it will return true for PROT_NONE mappings, though they are not yet used by the kernel with transparent huge pages. For consistency, also change pmd_mknotpresent() to only clear the PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block mappings (no functional change). The unused PMD_SECT_PROT_NONE definition is removed as transparent huge pages use the pte page prot values. Fixes: 9c7e535fcc17 ("arm64: mm: Route pmd thp functions through pte equivalents") Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 930f1194d44f585fb0aa1f6f41faae3fb0a1f82f Author: Catalin Marinas Date: Thu May 5 10:43:59 2016 +0100 arm64: Fix typo in the pmdp_huge_get_and_clear() definition commit 911f56eeb87ee378f5e215469268a7a2f68a5a8a upstream. With hardware AF/DBM support, pmd modifications (transparent huge pages) should be performed atomically using load/store exclusive. The initial patches defined the get-and-clear function and __HAVE_ARCH_* macro without the "huge" word, leaving the pmdp_huge_get_and_clear() to the default, non-atomic implementation. Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") Reviewed-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d276f428ef5549f414583963ba1f014e7746009e Author: Peter Zijlstra Date: Tue Apr 26 11:36:53 2016 +0200 perf/core: Fix perf_event_open() vs. execve() race commit 79c9ce57eb2d5f1497546a3946b4ae21b6fdc438 upstream. Jann reported that the ptrace_may_access() check in find_lively_task_by_vpid() is racy against exec(). Specifically: perf_event_open() execve() ptrace_may_access() commit_creds() ... if (get_dumpable() != SUID_DUMP_USER) perf_event_exit_task(); perf_install_in_context() would result in installing a counter across the creds boundary. Fix this by wrapping lots of perf_event_open() in cred_guard_mutex. This should be fine as perf_event_exit_task() is already called with cred_guard_mutex held, so all perf locks already nest inside it. Reported-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Signed-off-by: Ingo Molnar Signed-off-by: He Kuang Signed-off-by: Greg Kroah-Hartman commit 8f845bfbc77b938217b7e5bb30de70d7f36c5629 Author: Alexander Shishkin Date: Tue May 10 16:18:32 2016 +0300 perf/x86/intel/pt: Generate PMI in the STOP region as well commit ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c upstream. Currently, the PT driver always sets the PMI bit one region (page) before the STOP region so that we can wake up the consumer before we run out of room in the buffer and have to disable the event. However, we also need an interrupt in the last output region, so that we actually get to disable the event (if no more room from new data is available at that point), otherwise hardware just quietly refuses to start, but the event is scheduled in and we end up losing trace data till the event gets removed. For a cpu-wide event it is even worse since there may not be any re-scheduling at all and no chance for the ring buffer code to notice that its buffer is filled up and the event needs to be disabled (so that the consumer can re-enable it when it finishes reading the data out). In other words, all the trace data will be lost after the buffer gets filled up. This patch makes PT also generate a PMI when the last output region is full. Reported-by: Markus Metzger Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Cc: vince@deater.net Link: http://lkml.kernel.org/r/1462886313-13660-2-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman