commit 3b60b86aec06fbae1142ccc4e55b39b529ae2a25 Author: Sasha Levin Date: Fri Sep 2 22:46:14 2016 -0400 Linux 4.1.32 Signed-off-by: Sasha Levin commit dfd742cecf233b6b4a1d903a9c64f1b4bf04f1da Author: Simon Horman Date: Fri Dec 11 11:30:12 2015 +0900 PCI: Limit config space size for Netronome NFP4000 [ Upstream commit c2e771b02792d222cbcd9617fe71482a64f52647 ] Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP4000's PF's config space size to 0x600 bytes as is already done for the NFP6000. The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 8d3cd03ce36cf9673ce0625d648184b2fab25853 Author: Simon Horman Date: Fri Dec 11 11:30:11 2015 +0900 PCI: Add Netronome NFP4000 PF device ID [ Upstream commit 69874ec233871a62e1bc8c89e643993af93a8630 ] Add the device ID for the PF of the NFP4000. The device ID for the VF, 0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF. Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 2ca638dd9ba7a92a75196831e48cd22536e54787 Author: Jason S. McMullan Date: Wed Sep 30 15:35:07 2015 +0900 PCI: Limit config space size for Netronome NFP6000 family [ Upstream commit 9f33a2ae59f24452c1076749deb615bccd435ca9 ] The NFP6000 has an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP6000's config space size to 0x600 bytes. Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit ebcd02166277b5754a731d48a8ee004133abc345 Author: Jason S. McMullan Date: Wed Sep 30 15:35:06 2015 +0900 PCI: Add Netronome vendor and device IDs [ Upstream commit a755e169031dac9ebaed03302c4921687c271d62 ] Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV devices. Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 884740187257c03adae546c2bd9ca2b851785924 Author: Jason S. McMullan Date: Wed Sep 30 15:35:05 2015 +0900 PCI: Support PCIe devices with short cfg_size [ Upstream commit c20aecf6963d1273d8f6d61c042b4845441ca592 ] If a device quirk modifies the pci_dev->cfg_size to be less than PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256), the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE. Allow sysfs access to config space up to cfg_size, even if the device doesn't support the entire 4096-byte PCIe config space. Note that pci_read_config() and pci_write_config() limit access to dev->cfg_size even though pcie_config_attr contains 4096 (the maximum size). Signed-off-by: Jason S. McMullan [simon: edited changelog] Signed-off-by: Simon Horman [bhelgaas: more changelog edits] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit f7bb9ba34f4697790b144368377a268f3f2634e0 Author: Vegard Nossum Date: Thu Aug 25 15:17:11 2016 -0700 fs/seq_file: fix out-of-bounds read [ Upstream commit 088bf2ff5d12e2e32ee52a4024fec26e582f44d3 ] seq_read() is a nasty piece of work, not to mention buggy. It has (I think) an old bug which allows unprivileged userspace to read beyond the end of m->buf. I was getting these: BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr ffff880116889880 Read of size 2713 by task trinity-c2/1329 CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: kasan_object_err+0x1c/0x80 kasan_report_error+0x2cb/0x7e0 kasan_report+0x4e/0x80 check_memory_region+0x13e/0x1a0 kasan_check_read+0x11/0x20 seq_read+0xcd2/0x1480 proc_reg_read+0x10b/0x260 do_loop_readv_writev.part.5+0x140/0x2c0 do_readv_writev+0x589/0x860 vfs_readv+0x7b/0xd0 do_readv+0xd8/0x2c0 SyS_readv+0xb/0x10 do_syscall_64+0x1b3/0x4b0 entry_SYSCALL64_slow_path+0x25/0x25 Object at ffff880116889100, in cache kmalloc-4096 size: 4096 Allocated: PID = 1329 save_stack_trace+0x26/0x80 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x1aa/0x4a0 seq_buf_alloc+0x35/0x40 seq_read+0x7d8/0x1480 proc_reg_read+0x10b/0x260 do_loop_readv_writev.part.5+0x140/0x2c0 do_readv_writev+0x589/0x860 vfs_readv+0x7b/0xd0 do_readv+0xd8/0x2c0 SyS_readv+0xb/0x10 do_syscall_64+0x1b3/0x4b0 return_from_SYSCALL_64+0x0/0x6a Freed: PID = 0 (stack is not available) Memory state around the buggy address: ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint This seems to be the same thing that Dave Jones was seeing here: https://lkml.org/lkml/2016/8/12/334 There are multiple issues here: 1) If we enter the function with a non-empty buffer, there is an attempt to flush it. But it was not clearing m->from after doing so, which means that if we try to do this flush twice in a row without any call to traverse() in between, we are going to be reading from the wrong place -- the splat above, fixed by this patch. 2) If there's a short write to userspace because of page faults, the buffer may already contain multiple lines (i.e. pos has advanced by more than 1), but we don't save the progress that was made so the next call will output what we've already returned previously. Since that is a much less serious issue (and I have a headache after staring at seq_read() for the past 8 hours), I'll leave that for now. Link: http://lkml.kernel.org/r/1471447270-32093-1-git-send-email-vegard.nossum@oracle.com Signed-off-by: Vegard Nossum Reported-by: Dave Jones Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 942d5c08badb801dc6cddea30053840af05a6b43 Author: Chen-Yu Tsai Date: Thu Aug 25 14:26:59 2016 +0800 clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe function [ Upstream commit b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e ] The bootloader (U-boot) sometimes uses this timer for various delays. It uses it as a ongoing counter, and does comparisons on the current counter value. The timer counter is never stopped. In some cases when the user interacts with the bootloader, or lets it idle for some time before loading Linux, the timer may expire, and an interrupt will be pending. This results in an unexpected interrupt when the timer interrupt is enabled by the kernel, at which point the event_handler isn't set yet. This results in a NULL pointer dereference exception, panic, and no way to reboot. Clear any pending interrupts after we stop the timer in the probe function to avoid this. Cc: stable@vger.kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Daniel Lezcano Acked-by: Maxime Ripard Signed-off-by: Sasha Levin commit 917f1531b13efbc52acbc9fc0a65c258f01bfbc4 Author: Mike Snitzer Date: Wed Aug 24 21:12:58 2016 -0400 dm flakey: fix reads to be issued if drop_writes configured [ Upstream commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc ] v4.8-rc3 commit 99f3c90d0d ("dm flakey: error READ bios during the down_interval") overlooked the 'drop_writes' feature, which is meant to allow reads to be issued rather than errored, during the down_interval. Fixes: 99f3c90d0d ("dm flakey: error READ bios during the down_interval") Reported-by: Qu Wenruo Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 1d6a6dc25a83afb263fcc961d3714b6e30ba7fd1 Author: Jan Beulich Date: Mon Aug 15 09:02:38 2016 -0600 xenbus: don't look up transaction IDs for ordinary writes [ Upstream commit 9a035a40f7f3f6708b79224b86c5777a3334f7ea ] This should really only be done for XS_TRANSACTION_END messages, or else at least some of the xenstore-* tools don't work anymore. Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition") Reported-by: Richard Schütz Cc: Signed-off-by: Jan Beulich Tested-by: Richard Schütz Signed-off-by: David Vrabel Signed-off-by: Sasha Levin commit 083e76a59d21becc555ebcfd23a3821044096fa2 Author: Wanpeng Li Date: Tue Aug 23 20:07:19 2016 +0800 x86/apic: Do not init irq remapping if ioapic is disabled [ Upstream commit 2e63ad4bd5dd583871e6602f9d398b9322d358d9 ] native_smp_prepare_cpus -> default_setup_apic_routing -> enable_IR_x2apic -> irq_remapping_prepare -> intel_prepare_irq_remapping -> intel_setup_irq_remapping So IR table is setup even if "noapic" boot parameter is added. As a result we crash later when the interrupt affinity is set due to a half initialized remapping infrastructure. Prevent remap initialization when IOAPIC is disabled. Signed-off-by: Wanpeng Li Cc: Peter Zijlstra Cc: Joerg Roedel Link: http://lkml.kernel.org/r/1471954039-3942-1-git-send-email-wanpeng.li@hotmail.com Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit a3f914be622e423eb9f8d24128d3b965fa3d9b8a Author: John Stultz Date: Tue Aug 23 16:08:22 2016 -0700 timekeeping: Cap array access in timekeeping_debug [ Upstream commit a4f8f6667f099036c88f231dcad4cf233652c824 ] It was reported that hibernation could fail on the 2nd attempt, where the system hangs at hibernate() -> syscore_resume() -> i8237A_resume() -> claim_dma_lock(), because the lock has already been taken. However there is actually no other process would like to grab this lock on that problematic platform. Further investigation showed that the problem is triggered by setting /sys/power/pm_trace to 1 before the 1st hibernation. Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend, and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller than 1970) to the release date of that motherboard during POST stage, thus after resumed, it may seem that the system had a significant long sleep time which is a completely meaningless value. Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the sleep time happened to be set to 1, fls() returns 32 and we add 1 to sleep_time_bin[32], which causes an out of bounds array access and therefor memory being overwritten. As depicted by System.map: 0xffffffff81c9d080 b sleep_time_bin 0xffffffff81c9d100 B dma_spin_lock the dma_spin_lock.val is set to 1, which caused this problem. This patch adds a sanity check in tk_debug_account_sleep_time() to ensure we don't index past the sleep_time_bin array. [jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the issue slightly differently, but borrowed his excelent explanation of the issue here.] Fixes: 5c83545f24ab "power: Add option to log time spent in suspend" Reported-by: Janek Kozicki Reported-by: Chen Yu Signed-off-by: John Stultz Cc: linux-pm@vger.kernel.org Cc: Peter Zijlstra Cc: Xunlei Pang Cc: "Rafael J. Wysocki" Cc: stable Cc: Zhang Rui Link: http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 0c7b2c2aea55b4e940e3de8b41658855aebcbca4 Author: John Stultz Date: Tue Aug 23 16:08:21 2016 -0700 timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING [ Upstream commit 27727df240c7cc84f2ba6047c6f18d5addfd25ef ] When I added some extra sanity checking in timekeeping_get_ns() under CONFIG_DEBUG_TIMEKEEPING, I missed that the NMI safe __ktime_get_fast_ns() method was using timekeeping_get_ns(). Thus the locking added to the debug checks broke the NMI-safety of __ktime_get_fast_ns(). This patch open-codes the timekeeping_get_ns() logic for __ktime_get_fast_ns(), so can avoid any deadlocks in NMI. Fixes: 4ca22c2648f9 "timekeeping: Add warnings when overflows or underflows are observed" Reported-by: Steven Rostedt Reported-by: Peter Zijlstra Signed-off-by: John Stultz Cc: stable Link: http://lkml.kernel.org/r/1471993702-29148-2-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 2d701beb5dd816fa4c1115c88d464a6cc0e7271f Author: Andrey Ryabinin Date: Wed Aug 17 18:10:11 2016 +0300 um: Don't discard .text.exit section [ Upstream commit dad2232844073295c64e9cc2d734a0ade043e0f6 ] Commit e41f501d3912 ("vmlinux.lds: account for destructor sections") added '.text.exit' to EXIT_TEXT which is discarded at link time by default. This breaks compilation of UML: `.text.exit' referenced in section `.fini_array' of /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o): defined in discarded section `.text.exit' of /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libc.a(sdlerror.o) Apparently UML doesn't want to discard exit text, so let's place all EXIT_TEXT sections in .exit.text. Fixes: e41f501d3912 ("vmlinux.lds: account for destructor sections") Reported-by: Stefan Traby Signed-off-by: Andrey Ryabinin Cc: Acked-by: Dmitry Vyukov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit befdc6e859950c790f8b1c255049f036d3c7754a Author: Vincent Stehlé Date: Fri Aug 12 15:26:30 2016 +0200 ubifs: Fix assertion in layout_in_gaps() [ Upstream commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a ] An assertion in layout_in_gaps() verifies that the gap_lebs pointer is below the maximum bound. When computing this maximum bound the idx_lebs count is multiplied by sizeof(int), while C pointers arithmetic does take into account the size of the pointed elements implicitly already. Remove the multiplication to fix the assertion. Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system") Cc: Signed-off-by: Vincent Stehlé Cc: Artem Bityutskiy Signed-off-by: Artem Bityutskiy Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit d9a5bd9d810fdb2e66fa749b76bd1b8efecd290e Author: Benjamin Coddington Date: Mon Jun 6 18:07:59 2016 -0400 vhost/scsi: fix reuse of &vq->iov[out] in response [ Upstream commit a77ec83a57890240c546df00ca5df1cdeedb1cc3 ] The address of the iovec &vq->iov[out] is not guaranteed to contain the scsi command's response iovec throughout the lifetime of the command. Rather, it is more likely to contain an iovec from an immediately following command after looping back around to vhost_get_vq_desc(). Pass along the iovec entirely instead. Fixes: 79c14141a487 ("vhost/scsi: Convert completion path to use copy_to_iter") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Coddington Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit f85090ffc9bf6cb6734f563fb42e878b20314bab Author: Masahiro Yamada Date: Mon Aug 22 13:25:56 2016 -0700 Input: tegra-kbc - fix inverted reset logic [ Upstream commit fae16989be77b09bab86c79233e4b511ea769cea ] Commit fe6b0dfaba68 ("Input: tegra-kbc - use reset framework") accidentally converted _deassert to _assert, so there is no code to wake up this hardware. Fixes: fe6b0dfaba68 ("Input: tegra-kbc - use reset framework") Signed-off-by: Masahiro Yamada Acked-by: Thierry Reding Acked-by: Laxman Dewangan Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit bdd62ec6d873be9e3bcdc34d2deb45a541873650 Author: Andrej Krutak Date: Thu Aug 18 23:52:12 2016 +0200 ALSA: line6: Fix POD sysfs attributes segfault [ Upstream commit b027d11263836a0cd335520175257dcb99b43757 ] The commit 02fc76f6a changed base of the sysfs attributes from device to card. The "show" callbacks dereferenced wrong objects because of this. Fixes: 02fc76f6a7db ('ALSA: line6: Create sysfs via snd_card_add_dev_attr()') Cc: # v4.0+ Reviewed-by: Stefan Hajnoczi Signed-off-by: Andrej Krutak Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 571d36168dc246837e96ce40a7e535f1b70622e6 Author: Andrej Krutak Date: Thu Aug 18 23:52:11 2016 +0200 ALSA: line6: Give up on the lock while URBs are released. [ Upstream commit adc8a43a6d6688272ebffa81789fa857e603dec6 ] Done, because line6_stream_stop() locks and calls line6_unlink_audio_urbs(), which in turn invokes audio_out_callback(), which tries to lock 2nd time. Fixes: ============================================= [ INFO: possible recursive locking detected ] 4.4.15+ #15 Not tainted --------------------------------------------- mplayer/3591 is trying to acquire lock: (&(&line6pcm->out.lock)->rlock){-.-...}, at: [] audio_out_callback+0x70/0x110 [snd_usb_line6] but task is already holding lock: (&(&line6pcm->out.lock)->rlock){-.-...}, at: [] line6_stream_stop+0x24/0x5c [snd_usb_line6] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&line6pcm->out.lock)->rlock); lock(&(&line6pcm->out.lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by mplayer/3591: #0: (snd_pcm_link_rwlock){.-.-..}, at: [] snd_pcm_stream_lock+0x1e/0x40 [snd_pcm] #1: (&(&substream->self_group.lock)->rlock){-.-...}, at: [] snd_pcm_stream_lock+0x26/0x40 [snd_pcm] #2: (&(&line6pcm->out.lock)->rlock){-.-...}, at: [] line6_stream_stop+0x24/0x5c [snd_usb_line6] stack backtrace: CPU: 0 PID: 3591 Comm: mplayer Not tainted 4.4.15+ #15 Hardware name: Generic AM33XX (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x11/0x14) [] (show_stack) from [] (dump_stack+0x8b/0xac) [] (dump_stack) from [] (__lock_acquire+0xc8b/0x1780) [] (__lock_acquire) from [] (lock_acquire+0x99/0x1c0) [] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x3f/0x4c) [] (_raw_spin_lock_irqsave) from [] (audio_out_callback+0x70/0x110 [snd_usb_line6]) [] (audio_out_callback [snd_usb_line6]) from [] (__usb_hcd_giveback_urb+0x53/0xd0) [] (__usb_hcd_giveback_urb) from [] (musb_giveback+0x3d/0x98) [] (musb_giveback) from [] (musb_urb_dequeue+0x6d/0x114) [] (musb_urb_dequeue) from [] (usb_hcd_unlink_urb+0x39/0x98) [] (usb_hcd_unlink_urb) from [] (line6_unlink_audio_urbs+0x6a/0x6c [snd_usb_line6]) [] (line6_unlink_audio_urbs [snd_usb_line6]) from [] (line6_stream_stop+0x42/0x5c [snd_usb_line6]) [] (line6_stream_stop [snd_usb_line6]) from [] (snd_line6_trigger+0xb6/0xf4 [snd_usb_line6]) [] (snd_line6_trigger [snd_usb_line6]) from [] (snd_pcm_do_stop+0x36/0x38 [snd_pcm]) [] (snd_pcm_do_stop [snd_pcm]) from [] (snd_pcm_action_single+0x22/0x40 [snd_pcm]) [] (snd_pcm_action_single [snd_pcm]) from [] (snd_pcm_action+0xac/0xb0 [snd_pcm]) [] (snd_pcm_action [snd_pcm]) from [] (snd_pcm_drop+0x38/0x64 [snd_pcm]) [] (snd_pcm_drop [snd_pcm]) from [] (snd_pcm_common_ioctl1+0x7fe/0xbe8 [snd_pcm]) [] (snd_pcm_common_ioctl1 [snd_pcm]) from [] (snd_pcm_playback_ioctl1+0x15c/0x51c [snd_pcm]) [] (snd_pcm_playback_ioctl1 [snd_pcm]) from [] (snd_pcm_playback_ioctl+0x20/0x28 [snd_pcm]) [] (snd_pcm_playback_ioctl [snd_pcm]) from [] (do_vfs_ioctl+0x3af/0x5c8) Fixes: 63e20df1e5b2 ('ALSA: line6: Reorganize PCM stream handling') Cc: # v4.0+ Reviewed-by: Stefan Hajnoczi Signed-off-by: Andrej Krutak Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c717f88b1a8019a02d769cdefe27a4e38b49c2a3 Author: Andrej Krutak Date: Thu Aug 18 23:52:10 2016 +0200 ALSA: line6: Remove double line6_pcm_release() after failed acquire. [ Upstream commit 7e4379eae0e31994ea645db1d13006ea8e5ce539 ] If there's an error, pcm is released in line6_pcm_acquire already. Fixes: 247d95ee6dd2 ('ALSA: line6: Handle error from line6_pcm_acquire()') Cc: # v4.0+ Reviewed-by: Stefan Hajnoczi Signed-off-by: Andrej Krutak Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6c000a45a7d0e667eef0e3e568c4ff7fdba8faab Author: Daniel Vetter Date: Sat Aug 20 12:22:11 2016 +0200 drm: Reject page_flip for !DRIVER_MODESET [ Upstream commit 6f00975c619064a18c23fd3aced325ae165a73b9 ] Somehow this one slipped through, which means drivers without modeset support can be oopsed (since those also don't call drm_mode_config_init, which means the crtc lookup will chase an uninitalized idr). Reported-by: Alexander Potapenko Cc: Alexander Potapenko Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin commit f4eaf28c0926c1cc03af31f5e0a115abec91a0b3 Author: Helge Deller Date: Sat Aug 20 11:51:38 2016 +0200 parisc: Fix order of EREFUSED define in errno.h [ Upstream commit 3eb53b20d7bd1374598cfb1feaa081fcac0e76cd ] When building gccgo in userspace, errno.h gets parsed and the go include file sysinfo.go is generated. Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED is defined later on in errno.h, this leads to go complaining that EREFUSED isn't defined yet. Fix this trivial problem by moving the define of EREFUSED down after ECONNREFUSED in errno.h (and clean up the indenting while touching this line). Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 66751ff14c7d5429e7f2d014748c8e7549dc2361 Author: Vineet Gupta Date: Fri Aug 19 13:59:02 2016 -0700 ARC: export __udivdi3 for modules [ Upstream commit c57653dc94d0db7bf63067433ceaa97bdcd0a312 ] Some module using div_u64() was failing to link because the libgcc 64-bit divide assist routine was not being exported for modules Reported-by: avinashp@quantenna.com Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 871b20f18e93a25aca3d1980589e5ae5ec1a4b9d Author: Vineet Gupta Date: Wed Aug 10 14:10:57 2016 -0700 ARC: Support syscall ABI v4 [ Upstream commit 840c054fd0efb048df6fceb0c46385ec5b66dfe6 ] The syscall ABI includes the gcc functional calling ABI since a syscall implies userland caller and kernel callee. The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in even-odd register pairs, (potentially punching reg holes when passing such values as args). This was partly driven by the fact that the double-word LDD/STD instructions in ARCv2 expect the register alignment and thus gcc forcing this avoids extra MOV at the cost of a few unused register (which we have plenty anyways). This however was rejected as part of upstreaming gcc port to HS. So the new ABI v4 doesn't enforce the even-odd reg restriction. Do note that for ARCompact ISA builds v3 and v4 are practically the same in terms of gcc code generation. In terms of change management, we infer the new ABI if gcc 6.x onwards is used for building the kernel. This also needs a stable backport to enable older kernels to work with new tools/user-space Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 35de4db88c800c40f46959709674089d9e07743b Author: Liav Rehana Date: Tue Aug 16 10:55:35 2016 +0300 ARC: use correct offset in pt_regs for saving/restoring user mode r25 [ Upstream commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 ] User mode callee regs are explicitly collected before signal delivery or breakpoint trap. r25 is special for kernel as it serves as task pointer, so user mode value is clobbered very early. It is saved in pt_regs where generally only scratch (aka caller saved) regs are saved. The code to access the corresponding pt_regs location had a subtle bug as it was using load/store with scaling of offset, whereas the offset was already byte wise correct. So fix this by replacing LD.AS with a standard LD Cc: Signed-off-by: Liav Rehana Reviewed-by: Alexey Brodkin [vgupta: rewrote title and commit log] Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 0798bebd877549b60e56ab59bef5eac65c1c6ed6 Author: Vineet Gupta Date: Tue Oct 7 14:12:13 2014 +0530 ARCv2: STAR 9000808988: signals involving Delay Slot [ Upstream commit 0d7b8855a05c099a5c65a8d49a1e604198021f56 ] Reported by Anton as LTP:munmap01 failing with Illegal Instruction Exception. --------------------->8-------------------------------------- mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x200d2000 munmap(0x200d2000, 24576) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x200d2000} --- potentially unexpected fatal signal 4. Path: /munmap01 CPU: 0 PID: 61 Comm: munmap01 Not tainted 3.13.0-g5d5c46d9a556 #8 task: 9f1a8000 ti: 9f154000 task.ti: 9f154000 [ECR ]: 0x00020100 => Illegal Insn [EFA ]: 0x0001354c [BLINK ]: 0x200515d4 [ERET ]: 0x1354c @off 0x1354c in [/munmap01] VMA: 0x00010000 to 0x00018000 [STAT32]: 0x800802c0 ... --------------------->8-------------------------------------- The issue was 1. munmap01 accessed unmapped memory (on purpose) with signal handler installed for SIGSEGV 2. The faulting instruction happened to be in Delay Slot 00011864
: 11908: bl.d 13284 1190c: stb r16,[r2] 3. kernel sets up the reg file for signal handler and correctly clears the DE bit in pt_regs->status32 placeholder 4. However RESTORE_CALLEE_SAVED_USER macro is not adjusted for ARCv2, and it over-writes the above with orig/stale value of status32 5. After RTIE, userspace signal handler executes a non branch instruction with DE bit set, triggering Illegal Instruction Exception. Reported-by: Anton Kolesov Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit bc78e69d6f6d44b4ce34371c12e2af78f63935e1 Author: Dmitry Torokhov Date: Tue Aug 16 17:38:54 2016 -0700 Input: i8042 - set up shared ps2_cmd_mutex for AUX ports [ Upstream commit 47af45d684b5f3ae000ad448db02ce4f13f73273 ] The commit 4097461897df ("Input: i8042 - break load dependency ...") correctly set up ps2_cmd_mutex pointer for the KBD port but forgot to do the same for AUX port(s), which results in communication on KBD and AUX ports to clash with each other. Fixes: 4097461897df ("Input: i8042 - break load dependency ...") Reported-by: Bruno Wolff III Tested-by: Bruno Wolff III Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 146ed73fcafa760048514d4ddf791cfa943c9371 Author: Christian König Date: Wed Aug 17 09:46:42 2016 +0200 drm/radeon: fix radeon_move_blit on 32bit systems [ Upstream commit 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 ] This bug seems to be present for a very long time. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit bb6cf2c298a52ceb881d748188cefb07c08e7839 Author: Linus Walleij Date: Tue Aug 16 09:58:25 2016 +0200 gpio: Fix OF build problem on UM [ Upstream commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 ] The UserMode (UM) Linux build was failing in gpiolib-of as it requires ioremap()/iounmap() to exist, which is absent from UM. The non-existence of IO memory is negatively defined as CONFIG_NO_IOMEM which means we need to depend on HAS_IOMEM. Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven Reported-by: kbuild test robot Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cb515bdff8293136e97dd5370d0a094d3074ab21 Author: Kent Overstreet Date: Wed Aug 17 18:21:24 2016 -0700 bcache: RESERVE_PRIO is too small by one when prio_buckets() is a power of two. [ Upstream commit acc9cf8c66c66b2cbbdb4a375537edee72be64df ] This patch fixes a cachedev registration-time allocation deadlock. This can deadlock on boot if your initrd auto-registeres bcache devices: Allocator thread: [ 720.727614] INFO: task bcache_allocato:3833 blocked for more than 120 seconds. [ 720.732361] [] schedule+0x37/0x90 [ 720.732963] [] bch_bucket_alloc+0x188/0x360 [bcache] [ 720.733538] [] ? prepare_to_wait_event+0xf0/0xf0 [ 720.734137] [] bch_prio_write+0x19d/0x340 [bcache] [ 720.734715] [] bch_allocator_thread+0x3ff/0x470 [bcache] [ 720.735311] [] ? __schedule+0x2dc/0x950 [ 720.735884] [] ? invalidate_buckets+0x980/0x980 [bcache] Registration thread: [ 720.710403] INFO: task bash:3531 blocked for more than 120 seconds. [ 720.715226] [] schedule+0x37/0x90 [ 720.715805] [] __bch_btree_map_nodes+0x12d/0x150 [bcache] [ 720.716409] [] ? bch_btree_insert_check_key+0x1c0/0x1c0 [bcache] [ 720.717008] [] bch_btree_insert+0xf4/0x170 [bcache] [ 720.717586] [] ? prepare_to_wait_event+0xf0/0xf0 [ 720.718191] [] bch_journal_replay+0x14a/0x290 [bcache] [ 720.718766] [] ? ttwu_do_activate.constprop.94+0x5d/0x70 [ 720.719369] [] ? try_to_wake_up+0x1d4/0x350 [ 720.719968] [] run_cache_set+0x580/0x8e0 [bcache] [ 720.720553] [] register_bcache+0xe2e/0x13b0 [bcache] [ 720.721153] [] kobj_attr_store+0xf/0x20 [ 720.721730] [] sysfs_kf_write+0x3d/0x50 [ 720.722327] [] kernfs_fop_write+0x12a/0x180 [ 720.722904] [] __vfs_write+0x37/0x110 [ 720.723503] [] ? __sb_start_write+0x58/0x110 [ 720.724100] [] ? security_file_permission+0x23/0xa0 [ 720.724675] [] vfs_write+0xa9/0x1b0 [ 720.725275] [] ? do_audit_syscall_entry+0x6c/0x70 [ 720.725849] [] SyS_write+0x55/0xd0 [ 720.726451] [] ? do_page_fault+0x30/0x80 [ 720.727045] [] system_call_fastpath+0x12/0x71 The fifo code in upstream bcache can't use the last element in the buffer, which was the cause of the bug: if you asked for a power of two size, it'd give you a fifo that could hold one less than what you asked for rather than allocating a buffer twice as big. Signed-off-by: Kent Overstreet Tested-by: Eric Wheeler Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 220360d6ac0e1ef0cf364028c26f44ac99c306c4 Author: Eric Wheeler Date: Fri Jun 17 15:01:54 2016 -0700 bcache: register_bcache(): call blkdev_put() when cache_alloc() fails [ Upstream commit d9dc1702b297ec4a6bb9c0326a70641b322ba886 ] register_cache() is supposed to return an error string on error so that register_bcache() will will blkdev_put and cleanup other user counters, but it does not set 'char *err' when cache_alloc() fails (eg, due to memory pressure) and thus register_bcache() performs no cleanup. register_bcache() <----------\ <- no jump to err_close, no blkdev_put() | | +->register_cache() | <- fails to set char *err | | +->cache_alloc() ---/ <- returns error This patch sets `char *err` for this failure case so that register_cache() will cause register_bcache() to correctly jump to err_close and do cleanup. This was tested under OOM conditions that triggered the bug. Signed-off-by: Eric Wheeler Cc: Kent Overstreet Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 35b8f91bf61afc5764e739e718651afba580f9e8 Author: Christian König Date: Thu Aug 18 11:51:14 2016 +0200 drm/radeon: only apply the SS fractional workaround to RS[78]80 [ Upstream commit ae5b80d2b68eac945b124227dea34462118a6f01 ] Looks like some RV6xx have problems with that. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97099 Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 388bf264aef5c67b89edf78d51cb3b6637aab00f Author: Christian König Date: Mon Jun 13 16:09:53 2016 +0200 drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled [ Upstream commit 9ef8537e68941d858924a3eacee5a1945767cbab ] Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven for working a lot with the PLLs and figuring this out. Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 31df33850d7a16bf7c67220d912638a066a701bf Author: Oleg Nesterov Date: Wed Aug 17 17:36:29 2016 +0200 uprobes: Fix the memcg accounting [ Upstream commit 6c4687cc17a788a6dd8de3e27dbeabb7cbd3e066 ] __replace_page() wronlgy calls mem_cgroup_cancel_charge() in "success" path, it should only do this if page_check_address() fails. This means that every enable/disable leads to unbalanced mem_cgroup_uncharge() from put_page(old_page), it is trivial to underflow the page_counter->count and trigger OOM. Reported-and-tested-by: Brenden Blanco Signed-off-by: Oleg Nesterov Reviewed-by: Johannes Weiner Acked-by: Michal Hocko Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Arnaldo Carvalho de Melo Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Vladimir Davydov Cc: stable@vger.kernel.org # 3.17+ Fixes: 00501b531c47 ("mm: memcontrol: rewrite charge API") Link: http://lkml.kernel.org/r/20160817153629.GB29724@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 26390c7073a70d57c5c0de7c44f909fc91f3c66b Author: Bart Van Assche Date: Tue Aug 16 16:48:36 2016 -0700 block: Fix race triggered by blk_set_queue_dying() [ Upstream commit 1b856086813be9371929b6cc62045f9fd470f5a0 ] blk_set_queue_dying() can be called while another thread is submitting I/O or changing queue flags, e.g. through dm_stop_queue(). Hence protect the QUEUE_FLAG_DYING flag change with locking. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Mike Snitzer Cc: stable Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0df5268514aafd144b5b0402d03a21951961fa9f Author: Christoph Huber Date: Mon Aug 15 18:59:25 2016 +0200 ASoC: atmel_ssc_dai: Don't unconditionally reset SSC on stream startup [ Upstream commit 3e103a65514c2947e53f3171b21255fbde8b60c6 ] commit cbaadf0f90d6 ("ASoC: atmel_ssc_dai: refactor the startup and shutdown") refactored code such that the SSC is reset on every startup; this breaks duplex audio (e.g. first start audio playback, then start record, causing the playback to stop/hang) Fixes: cbaadf0f90d6 (ASoC: atmel_ssc_dai: refactor the startup and shutdown) Signed-off-by: Christoph Huber Signed-off-by: Peter Meerwald-Stadler Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 7ae87eebbcf7bb96467ea4f3c6563e32e1f600bc Author: Sasha Levin Date: Tue Aug 30 22:04:29 2016 -0400 ARC: Elide redundant setup of DMA callbacks [ Upstream commit 45c3b08a117e2232fc8d7b9e849ead36386f4f96 ] For resources shared by all cores such as SLC and IOC, only the master core needs to do any setups / enabling / disabling etc. Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 0e16c544ede2bc7954de7583cb2ff1594fb5db97 Author: Sasha Levin Date: Tue Aug 30 21:59:56 2016 -0400 ARC: Call trace_hardirqs_on() before enabling irqs [ Upstream commit 18b43e89d295cc65151c505c643c98fb2c320e59 ] trace_hardirqs_on_caller() in lockdep.c expects to be called before, not after interrupts are actually enabled. The following comment in kernel/locking/lockdep.c substantiates this claim: " /* * We're enabling irqs and according to our state above irqs weren't * already enabled, yet we find the hardware thinks they are in fact * enabled.. someone messed up their IRQ state tracing. */ " An example can be found in include/linux/irqflags.h: do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0) Without this change, we hit the following DEBUG_LOCKS_WARN_ON. [ 7.760000] ------------[ cut here ]------------ [ 7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0 [ 7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [ 7.780000] Modules linked in: [ 7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366 [ 7.790000] [ 7.790000] Stack Trace: [ 7.790000] arc_unwind_core.constprop.1+0xa4/0x118 [ 7.800000] warn_slowpath_fmt+0x72/0x158 [ 7.800000] resume_user_mode_begin+0x48/0xf0 [ 7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]--- Signed-off-by: Daniel Mentz Cc: Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit e1052fbcb3d341d8088b8ffec73f3e5dbb37fe6d Author: Jim Lin Date: Tue Aug 16 10:18:05 2016 +0300 usb: xhci: Fix panic if disconnect [ Upstream commit 88716a93766b8f095cdef37a8e8f2c93aa233b21 ] After a device is disconnected, xhci_stop_device() will be invoked in xhci_bus_suspend(). Also the "disconnect" IRQ will have ISR to invoke xhci_free_virt_device() in this sequence. xhci_irq -> xhci_handle_event -> handle_cmd_completion -> xhci_handle_cmd_disable_slot -> xhci_free_virt_device If xhci->devs[slot_id] has been assigned to NULL in xhci_free_virt_device(), then virt_dev->eps[i].ring in xhci_stop_device() may point to an invlid address to cause kernel panic. virt_dev = xhci->devs[slot_id]; : if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) [] Unable to handle kernel paging request at virtual address 00001a68 [] pgd=ffffffc001430000 [] [00001a68] *pgd=000000013c807003, *pud=000000013c807003, *pmd=000000013c808003, *pte=0000000000000000 [] Internal error: Oops: 96000006 [#1] PREEMPT SMP [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U [] Workqueue: pm pm_runtime_work [] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti: ffffffc0bc0ec000 [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4 This issue is found when running with realtek ethernet device (0bda:8153). Signed-off-by: Jim Lin Cc: Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 23c50b25b252a8273baddf958f3468ec39b55e0f Author: Mathias Nyman Date: Tue Aug 16 10:18:03 2016 +0300 xhci: always handle "Command Ring Stopped" events [ Upstream commit 33be126510974e2eb9679f1ca9bca4f67ee4c4c7 ] Fix "Command completion event does not match command" errors by always handling the command ring stopped events. The command ring stopped event is generated as a result of aborting or stopping the command ring with a register write. It is not caused by a command in the command queue, and thus won't have a matching command in the comman list. Solve it by handling the command ring stopped event before checking for a matching command. In most command time out cases we abort the command ring, and get a command ring stopped event. The events command pointer will point at the current command ring dequeue, which in most cases matches the timed out command in the command list, and no error messages are seen. If we instead get a command aborted event before the command ring stopped event, the abort event will increse the command ring dequeue pointer, and the following command ring stopped events command pointer will point at the next, not yet queued command. This case triggered the error message Signed-off-by: Mathias Nyman CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9fd7c335115eb2a18b684bdc5c68627be60d4fdf Author: Gavin Li Date: Fri Aug 12 00:52:56 2016 -0700 cdc-acm: fix wrong pipe type on rx interrupt xfers [ Upstream commit add125054b8727103631dce116361668436ef6a7 ] This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb(). Signed-off-by: Gavin Li Acked-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1a8eadfa9c79c3d1b780e8081cc1e5e242f1632d Author: Lu Baolu Date: Thu Aug 11 10:31:14 2016 +0800 usb: misc: usbtest: add fix for driver hang [ Upstream commit 539587511835ea12d8daa444cbed766cf2bc3612 ] In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling into usb_sg_cancel(). usb_sg_cancel() will do nothing and return directly if req->status has been set to a non-zero value. This will cause driver hang whenever transfer time out is triggered. This patch fixes this issue. It could be backported to stable kernel with version later than v3.15. Cc: stable@vger.kernel.org # 3.15+ Cc: Alan Stern Signed-off-by: Lu Baolu Suggested-by: Alan Stern Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79e3a23fe5a319e5799f12585f6a74d1214c66c7 Author: Yoshihiro Shimoda Date: Mon Aug 8 21:50:53 2016 +0900 usb: renesas_usbhs: Use dmac only if the pipe type is bulk [ Upstream commit 700aa7ff8d2c2b9cc669c99375e2ccd06d3cd38d ] This patch fixes an issue that isochronous transfer's data is possible to be lost as a workaround. Since this driver uses a workqueue to start the dmac, the transfer is possible to be delayed when system load is high. Fixes: 6e4b74e4690d ("usb: renesas: fix scheduling in atomic context bug") Cc: # v3.4+ Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 80a979e8212300af4464fa0872a025ac303a50d5 Author: Yoshihiro Shimoda Date: Mon Aug 8 21:50:52 2016 +0900 usb: renesas_usbhs: clear the BRDYSTS in usbhsg_ep_enable() [ Upstream commit 9ab967e6db7412b675ecbff80d5371d53c82cb2e ] This patch fixes an issue that unexpected BRDY interruption happens when the usb_ep_{enable,disable}() are called with different direction. In this case, the driver will cause the following message: renesas_usbhs e6590000.usb: irq_ready run_error 1 : -16 This issue causes the followings: 1) A pipe is enabled as transmission 2) The pipe sent a data 3) The pipe is disabled and re-enabled as reception. 4) The pipe got a queue Since the driver doesn't clear the BRDYSTS flags after 2) above, the issue happens. If we add such clearing the flags into the driver, the code will become complicate. So, this patch clears the BRDYSTS flag of reception in usbhsg_ep_enable() to avoid complicate. Cc: # v4.1+ (usbhs_xxxsts_clear() is needed) Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 03b78ea5910da53e589db6b0f58e711b92dd0d90 Author: Matthew Auld Date: Fri Aug 5 19:04:40 2016 +0100 drm/i915: fix aliasing_ppgtt leak [ Upstream commit 3871f42a57efcdc6a9da751a8cb6fa196c212289 ] In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This fixes the following kmemleak message: unreferenced object 0xffff880213cca000 (size 8192): comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] kmem_cache_alloc_trace+0x142/0x1d0 [] i915_gem_init_ggtt+0x10f/0x210 [i915] [] i915_gem_init+0x5b/0xd0 [i915] [] i915_driver_load+0x97a/0x1460 [i915] [] i915_pci_probe+0x4f/0x70 [i915] [] local_pci_probe+0x45/0xa0 [] pci_device_probe+0x103/0x150 [] driver_probe_device+0x22c/0x440 [] __driver_attach+0xd1/0xf0 [] bus_for_each_dev+0x6c/0xc0 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1c3/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x4c/0x50 [] 0xffffffffa013605b Signed-off-by: Matthew Auld Reviewed-by: Chris Wilson Fixes: b18b6bde300e ("drm/i915/bdw: Free PPGTT struct") Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470420280-21417-1-git-send-email-matthew.auld@intel.com (cherry picked from commit cb7f27601c81a1e0454e9461e96f65b31fafbea0) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 46c9df4a3d9534fd230b7b85b3b0042080283ff7 Author: Agrawal, Nitesh-kumar Date: Tue Jul 26 08:28:19 2016 +0000 pinctrl/amd: Remove the default de-bounce time [ Upstream commit 8cf4345575a416e6856a6856ac6eaa31ad883126 ] In the function amd_gpio_irq_enable() and amd_gpio_direction_input(), remove the code which is setting the default de-bounce time to 2.75ms. The driver code shall use the same settings as specified in BIOS. Any default assignment impacts TouchPad behaviour when the LevelTrig is set to EDGE FALLING. Cc: stable@vger.kernel.org Reviewed-by:  Ken Xue Signed-off-by: Nitesh Kumar Agrawal Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit f079b0e5a9bba59b1befd390b81a1819dd41e19d Author: Heikki Krogerus Date: Fri Apr 1 17:13:11 2016 +0300 usb: dwc3: pci: add Intel Kabylake PCI ID [ Upstream commit 4491ed5042f0419b22a4b08331adb54af31e2caa ] Intel Kabylake PCH has the same DWC3 than Intel Sunrisepoint. Add the new ID to the supported devices. Cc: Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f034f1c6e8075ca3e294babd578ada5daef9d4c1 Author: Heikki Krogerus Date: Wed Oct 21 14:37:04 2015 +0300 usb: dwc3: pci: add support for Intel Broxton SOC [ Upstream commit b4c580a43d520b7812c0fd064fbab929ce2f1da0 ] PCI IDs for Broxton based platforms. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 888ea95a19eb3abde8373f68cd6fd8e65785570c Author: John Youn Date: Fri Sep 25 23:47:53 2015 -0700 usb: dwc3: pci: trivial: Formatting [ Upstream commit 9a5a0783e4910d9e2063e87184fbd9cac7161a16 ] Fix the alignment of the PCI device definitions. Also change the hex digit capitalization of one constant to make it consistent with the rest of the file and driver. Signed-off-by: John Youn Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit b42468438321297c27cca67a20d09b22d0bc486f Author: Felipe Balbi Date: Wed Aug 10 12:35:30 2016 +0300 usb: dwc3: gadget: always cleanup all TRBs [ Upstream commit 7c705dfe2ebe731c8fd068623b6b4df2d3512c08 ] If we stop earlier due to short packet, we will not be able to giveback all TRBs. Cc: Cc: Brian E Rogers Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit a694f3fa30adc8be36d7e2f8e4911a3fe705adf2 Author: Felipe Balbi Date: Wed Aug 10 11:13:26 2016 +0300 usb: dwc3: gadget: fix for short pkts during chained xfers [ Upstream commit e5b36ae2f851024d43c76e51f395d32ce8d769ce ] DWC3 has one interesting peculiarity with chained transfers. If we setup N chained transfers and we get a short packet before processing all N TRBs, DWC3 will (conditionally) issue a XferComplete or XferInProgress event and retire all TRBs from the one which got a short packet to the last without clearing their HWO bits. This means SW must clear HWO bit manually, which this patch is doing. Cc: Cc: Brian E Rogers Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 60b8bcfd6a911071c8eb7de6bb9c1afc964385f1 Author: Felipe Balbi Date: Fri Jul 29 03:17:58 2016 +0300 usb: dwc3: gadget: increment request->actual once [ Upstream commit c7de573471832dff7d31f0c13b0f143d6f017799 ] When using SG lists, we would end up setting request->actual to: num_mapped_sgs * (request->length - count) Let's fix that up by incrementing request->actual only once. Cc: Reported-by: Brian E Rogers Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit d3c1edbd4f11a838785af3c48a1885f6b94935ad Author: Stefan Haberland Date: Mon Aug 8 14:08:17 2016 +0200 s390/dasd: fix hanging device after clear subchannel [ Upstream commit 9ba333dc55cbb9523553df973adb3024d223e905 ] When a device is in a status where CIO has killed all I/O by itself the interrupt for a clear request may not contain an irb to determine the clear function. Instead it contains an error pointer -EIO. This was ignored by the DASD int_handler leading to a hanging device waiting for a clear interrupt. Handle -EIO error pointer correctly for requests that are clear pending and treat the clear as successful. Signed-off-by: Stefan Haberland Reviewed-by: Sebastian Ott Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 5bd6b61399ab2a4c024389fd64c02b099c8fff95 Author: Marc Ohlf Date: Wed Aug 3 11:51:54 2016 +0200 usb: ehci: change order of register cleanup during shutdown [ Upstream commit bc337b51508beb2d039aff5074a76cfe1c212030 ] In ehci_turn_off_all_ports() all EHCI port registers are cleared to zero. On some hardware, this can lead to an system hang, when ehci_port_power() accesses the already cleared registers. This patch changes the order of cleanup. First call ehci_port_power() which respects the current bits in port status registers and afterwards cleanup the hard way by setting everything to zero. Signed-off-by: Marc Ohlf Acked-by: Alan Stern CC: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fdcdf5bac083b93871d4762feeae99caf85bf325 Author: Viresh Kumar Date: Thu Aug 4 13:32:22 2016 -0700 usb: hub: Fix unbalanced reference count/memory leak/deadlocks [ Upstream commit 6bb47e8ab98accb1319bd43c64966340ba3bba9a ] Memory leak and unbalanced reference count: If the hub gets disconnected while the core is still activating it, this can result in leaking memory of few USB structures. This will happen if we have done a kref_get() from hub_activate() and scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect() gets called before the delayed work expires, then we will cancel the work from hub_quiesce(), but wouldn't do a kref_put(). And so the unbalance. kmemleak reports this as (with the commit e50293ef9775 backported to 3.10 kernel with other changes, though the same is true for mainline as well): unreferenced object 0xffffffc08af5b800 (size 1024): comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s) hex dump (first 32 bytes): 30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff 0h.............. 01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff ..........}@.... backtrace: [] create_object+0x148/0x2a0 [] kmemleak_alloc+0x80/0xbc [] kmem_cache_alloc_trace+0x120/0x1ac [] hub_probe+0x120/0xb84 [] usb_probe_interface+0x1ec/0x298 [] driver_probe_device+0x160/0x374 [] __device_attach+0x28/0x4c [] bus_for_each_drv+0x78/0xac [] device_attach+0x6c/0x9c [] bus_probe_device+0x28/0xa0 [] device_add+0x324/0x604 [] usb_set_configuration+0x660/0x6cc [] generic_probe+0x44/0x84 [] usb_probe_device+0x54/0x74 [] driver_probe_device+0x160/0x374 [] __device_attach+0x28/0x4c Deadlocks: If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are finished and the init_work is still queued), the core may call hub_quiesce() after acquiring interface device locks and it will wait for the work to be cancelled synchronously. But if the work handler is already running in parallel, it may try to acquire the same interface device lock and this may result in deadlock. Fix both the issues by removing the call to cancel_delayed_work_sync(). CC: #4.4+ Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()") Reported-by: Manu Gautam Signed-off-by: Viresh Kumar Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aca78034833166c848505b391b258ecbb96c895b Author: Russell King Date: Tue Aug 9 08:27:17 2016 +0100 crypto: caam - fix non-hmac hashes [ Upstream commit a0118c8b2be9297aed8e915c60b4013326b256d4 ] Since 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)"), the AF_ALG interface requires userspace to provide a key to any algorithm that has a setkey method. However, the non-HMAC algorithms are not keyed, so setting a key is unnecessary. Fix this by removing the setkey method from the non-keyed hash algorithms. Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)") Cc: Signed-off-by: Russell King Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e989e0c9bba5c1f8987629e2880a512d7b15e852 Author: Dave Carroll Date: Fri Aug 5 13:44:10 2016 -0600 aacraid: Check size values after double-fetch from user [ Upstream commit fa00c437eef8dc2e7b25f8cd868cfa405fcc2bb3 ] In aacraid's ioctl_send_fib() we do two fetches from userspace, one the get the fib header's size and one for the fib itself. Later we use the size field from the second fetch to further process the fib. If for some reason the size from the second fetch is different than from the first fix, we may encounter an out-of- bounds access in aac_fib_send(). We also check the sender size to insure it is not out of bounds. This was reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was assigned CVE-2016-6480. Reported-by: Pengfei Wang Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)' Cc: stable@vger.kernel.org Signed-off-by: Dave Carroll Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6a19c730de76c8b870a72035416a45ea47cb8e75 Author: Alexey Klimov Date: Mon Aug 8 02:34:46 2016 +0100 USB: serial: fix memleak in driver-registration error path [ Upstream commit 647024a7df36014bbc4479d92d88e6b77c0afcf6 ] udriver struct allocated by kzalloc() will not be freed if usb_register() and next calls fail. This patch fixes this by adding one more step with kfree(udriver) in error path. Signed-off-by: Alexey Klimov Acked-by: Alan Stern Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 61882ca3c2050d4821738454cb4966dcf8097fc5 Author: Daniele Palmas Date: Tue Aug 2 11:29:25 2016 +0200 USB: serial: option: add support for Telit LE920A4 [ Upstream commit 01d7956b58e644ea0d2e8d9340c5727a8fc39d70 ] This patch adds a set of compositions for Telit LE920A4. Compositions in short are: 0x1207: tty + tty 0x1208: tty + adb + tty + tty 0x1211: tty + adb + ecm 0x1212: tty + adb 0x1213: ecm + tty 0x1214: tty + adb + ecm + tty telit_le922_blacklist_usbcfg3 is reused for compositions 0x1211 and 0x1214 due to the same interfaces positions. Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 2980f143e9f9caaf53808f2106fbafc6151646ec Author: Sheng-Hui J. Chu Date: Thu Jul 28 17:01:45 2016 -0400 USB: serial: ftdi_sio: add device ID for WICED USB UART dev board [ Upstream commit ae34d12cc1e212ffcd92e069030e54dae69c832f ] BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO IC. To support BCM920706V2_EVAL dev board for WICED development on Linux. Add the VID(0a5c) and PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board. Signed-off-by: Sheng-Hui J. Chu Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 65b2f0af0dfc3be7ac1f1302db7bf64184b3a821 Author: Robert Deliën Date: Thu Jul 28 18:52:55 2016 +0000 USB: serial: ftdi_sio: add PIDs for Ivium Technologies devices [ Upstream commit 6977495c06f7f47636a076ee5a0ca571279d9697 ] Ivium Technologies uses the FTDI VID with custom PIDs for their line of electrochemical interfaces and the PalmSens they developed for PalmSens BV. Signed-off-by: Robert Delien Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit cbae57635b20802b211e281a7dc7fcf56316e36e Author: Lubomir Rintel Date: Sun Jul 24 13:53:30 2016 +0200 USB: serial: option: add D-Link DWM-156/A3 [ Upstream commit cf1b18030de29e4e5b0a57695ae5db4a89da0ff7 ] The device has four interfaces; the three serial ports ought to be handled by this driver: 00 Diagnostic interface serial port 01 NMEA device serial port 02 Mass storage (sd card) 03 Modem serial port The other product ids listed in the Windows driver are present already. Signed-off-by: Lubomir Rintel Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit 4bb0ddaf9330fd4c1359cd98cb9aa2f3131d769c Author: Felix Fietkau Date: Tue Aug 2 11:13:41 2016 +0200 mac80211: fix purging multicast PS buffer queue [ Upstream commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 ] The code currently assumes that buffered multicast PS frames don't have a pending ACK frame for tx status reporting. However, hostapd sends a broadcast deauth frame on teardown for which tx status is requested. This can lead to the "Have pending ack frames" warning on module reload. Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2dd916fce77144aaa8fb554a2b41be73635ee650 Author: Jason Baron Date: Thu Jul 14 11:38:40 2016 -0400 tcp: enable per-socket rate limiting of all 'challenge acks' [ Upstream commit 083ae308280d13d187512b9babe3454342a7987e ] The per-socket rate limit for 'challenge acks' was introduced in the context of limiting ack loops: commit f2b2c582e824 ("tcp: mitigate ACK loops for connections as tcp_sock") And I think it can be extended to rate limit all 'challenge acks' on a per-socket basis. Since we have the global tcp_challenge_ack_limit, this patch allows for tcp_challenge_ack_limit to be set to a large value and effectively rely on the per-socket limit, or set tcp_challenge_ack_limit to a lower value and still prevents a single connections from consuming the entire challenge ack quota. It further moves in the direction of eliminating the global limit at some point, as Eric Dumazet has suggested. This a follow-up to: Subject: tcp: make challenge acks less predictable Cc: Eric Dumazet Cc: David S. Miller Cc: Neal Cardwell Cc: Yuchung Cheng Cc: Yue Cao Signed-off-by: Jason Baron Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2b211174edd454376ab9bc85f7bae8e01016d87c Author: Eric Dumazet Date: Sun Jul 10 10:04:02 2016 +0200 tcp: make challenge acks less predictable [ Upstream commit 75ff39ccc1bd5d3c455b6822ab09e533c551f758 ] Yue Cao claims that current host rate limiting of challenge ACKS (RFC 5961) could leak enough information to allow a patient attacker to hijack TCP sessions. He will soon provide details in an academic paper. This patch increases the default limit from 100 to 1000, and adds some randomization so that the attacker can no longer hijack sessions without spending a considerable amount of probes. Based on initial analysis and patch from Linus. Note that we also have per socket rate limiting, so it is tempting to remove the host limit in the future. v2: randomize the count of challenge acks per second, not the period. Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") Reported-by: Yue Cao Signed-off-by: Eric Dumazet Suggested-by: Linus Torvalds Cc: Yuchung Cheng Cc: Neal Cardwell Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit beebc82b1cf1710ffebebdff4e09b3455085fa94 Author: Andrew Donnellan Date: Fri Oct 23 17:19:46 2015 +1100 powerpc/eeh: eeh_pci_enable(): fix checking of post-request state [ Upstream commit 949e9b827eb4736d96df520c67d07a54c64e99b8 ] In eeh_pci_enable(), after making the request to set the new options, we call eeh_ops->wait_state() to check that the request finished successfully. At the moment, if eeh_ops->wait_state() returns 0, we return 0 without checking that it reflects the expected outcome. This can lead to callers further up the chain incorrectly assuming the slot has been successfully unfrozen and continuing to attempt recovery. On powernv, this will occur if pnv_eeh_get_pe_state() or pnv_eeh_get_phb_state() return 0, which in turn occurs if the relevant OPAL call returns OPAL_EEH_STOPPED_MMIO_DMA_FREEZE or OPAL_EEH_PHB_ERROR respectively. On pseries, this will occur if pseries_eeh_get_state() returns 0, which in turn occurs if RTAS reports that the PE is in the MMIO Stopped and DMA Stopped states. Obviously, none of these cases represent a successful completion of a request to thaw MMIO or DMA. Fix the check so that a wait_state() return value of 0 won't be considered successful for the EEH_OPT_THAW_MMIO or EEH_OPT_THAW_DMA cases. Signed-off-by: Andrew Donnellan Acked-by: Gavin Shan Reviewed-by: Daniel Axtens Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin