commit 2f5e58ec793f56f9ac1c6736b4638a4b81d6f099 Author: Greg Kroah-Hartman Date: Fri Apr 21 09:31:39 2017 +0200 Linux 4.9.24 commit 35b9d61ea910c1ebd4652b32cc7d713f6689b4f4 Author: Marcelo Ricardo Leitner Date: Thu Feb 23 09:31:18 2017 -0300 sctp: deny peeloff operation on asocs with threads sleeping on it commit dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 upstream. commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") attempted to avoid a BUG_ON call when the association being used for a sendmsg() is blocked waiting for more sndbuf and another thread did a peeloff operation on such asoc, moving it to another socket. As Ben Hutchings noticed, then in such case it would return without locking back the socket and would cause two unlocks in a row. Further analysis also revealed that it could allow a double free if the application managed to peeloff the asoc that is created during the sendmsg call, because then sctp_sendmsg() would try to free the asoc that was created only for that call. This patch takes another approach. It will deny the peeloff operation if there is a thread sleeping on the asoc, so this situation doesn't exist anymore. This avoids the issues described above and also honors the syscalls that are already being handled (it can be multiple sendmsg calls). Joint work with Xin Long. Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") Cc: Alexander Popov Cc: Ben Hutchings Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c67c2be735b143422db69ba2012b2c93edb92baa Author: Mantas M Date: Fri Dec 16 10:30:59 2016 +0200 net: ipv6: check route protocol when deleting routes commit c2ed1880fd61a998e3ce40254a99a2ad000f1a7d upstream. The protocol field is checked when deleting IPv4 routes, but ignored for IPv6, which causes problems with routing daemons accidentally deleting externally set routes (observed by multiple bird6 users). This can be verified using `ip -6 route del proto something`. Signed-off-by: Mantas Mikulėnas Signed-off-by: David S. Miller Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 86c6667f6a5f6bdb392d8ffbe58fbcbcf6db2704 Author: Omar Sandoval Date: Wed Feb 1 00:02:27 2017 -0800 virtio-console: avoid DMA from stack commit c4baad50297d84bde1a7ad45e50c73adae4a2192 upstream. put_chars() stuffs the buffer it gets into an sg, but that buffer may be on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it manifested as printks getting turned into NUL bytes). Signed-off-by: Omar Sandoval Signed-off-by: Michael S. Tsirkin Reviewed-by: Amit Shah Cc: Ben Hutchings Cc: Brad Spengler Signed-off-by: Greg Kroah-Hartman commit fb00319317c152bf3528df13a54c28bf8c5daa55 Author: Stefan Brüns Date: Sun Feb 5 12:57:59 2017 -0200 cxusb: Use a dma capable buffer also for reading commit 3f190e3aec212fc8c61e202c51400afa7384d4bc upstream. Commit 17ce039b4e54 ("[media] cxusb: don't do DMA on stack") added a kmalloc'ed bounce buffer for writes, but missed to do the same for reads. As the read only happens after the write is finished, we can reuse the same buffer. As dvb_usb_generic_rw handles a read length of 0 by itself, avoid calling it using the dvb_usb_generic_read wrapper function. Signed-off-by: Stefan Brüns Signed-off-by: Mauro Carvalho Chehab Cc: Ben Hutchings Cc: Brad Spengler Signed-off-by: Greg Kroah-Hartman commit 28d1e8b7ef81d254583f68627095f8a85e39597d Author: Stefan Brüns Date: Sun Feb 12 13:02:13 2017 -0200 dvb-usb-firmware: don't do DMA on stack commit 67b0503db9c29b04eadfeede6bebbfe5ddad94ef upstream. The buffer allocation for the firmware data was changed in commit 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load") but the same applies for the reset value. Fixes: 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load") Signed-off-by: Stefan Brüns Signed-off-by: Mauro Carvalho Chehab Cc: Ben Hutchings Cc: Brad Spengler Signed-off-by: Greg Kroah-Hartman commit 36b62c08e72b9cff822d8d8e007d75302c71d68c Author: Mauro Carvalho Chehab Date: Tue Jan 24 08:13:11 2017 -0200 dvb-usb: don't use stack for firmware load commit 43fab9793c1f44e665b4f98035a14942edf03ddc upstream. As reported by Marc Duponcheel , firmware load on dvb-usb is using the stack, with is not allowed anymore on default Kernel configurations: [ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware [ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw' [ 1025.958855] dvb-usb: could not stop the USB controller CPU. [ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3) [ 1025.958856] dvb-usb: firmware download failed at 8 with -22 [ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u [ 2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw' [ 2.789905] ------------[ cut here ]------------ [ 2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore] [ 2.789912] transfer buffer not dma capable [ 2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod [ 2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1 [ 2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013 [ 2.789938] ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000 [ 2.789939] ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000 [ 2.789941] 0000000000000000 0000000000000000 0000000000000001 ffff880116c08000 [ 2.789942] Call Trace: [ 2.789945] [] dump_stack+0x4d/0x66 [ 2.789947] [] __warn+0xc6/0xe0 [ 2.789948] [] warn_slowpath_fmt+0x4a/0x50 [ 2.789952] [] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore] [ 2.789954] [] ? io_schedule_timeout+0xd8/0x110 [ 2.789956] [] usb_hcd_submit_urb+0x9c/0x980 [usbcore] [ 2.789958] [] ? copy_page_to_iter+0x14f/0x2b0 [ 2.789960] [] ? pagecache_get_page+0x28/0x240 [ 2.789962] [] ? touch_atime+0x20/0xa0 [ 2.789964] [] usb_submit_urb+0x2c4/0x520 [usbcore] [ 2.789967] [] usb_start_wait_urb+0x5a/0xe0 [usbcore] [ 2.789969] [] usb_control_msg+0xbc/0xf0 [usbcore] [ 2.789970] [] usb_cypress_writemem+0x3d/0x40 [dvb_usb] [ 2.789972] [] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb] [ 2.789973] [] ? console_unlock+0x2fe/0x5d0 [ 2.789974] [] ? vprintk_emit+0x27c/0x410 [ 2.789975] [] ? vprintk_default+0x1a/0x20 [ 2.789976] [] ? printk+0x43/0x4b [ 2.789977] [] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb] [ 2.789979] [] dvb_usb_device_init+0x3d8/0x610 [dvb_usb] [ 2.789981] [] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u] [ 2.789984] [] usb_probe_interface+0xfc/0x270 [usbcore] [ 2.789985] [] driver_probe_device+0x215/0x2d0 [ 2.789986] [] __driver_attach+0x96/0xa0 [ 2.789987] [] ? driver_probe_device+0x2d0/0x2d0 [ 2.789988] [] bus_for_each_dev+0x5b/0x90 [ 2.789989] [] driver_attach+0x19/0x20 [ 2.789990] [] bus_add_driver+0x11c/0x220 [ 2.789991] [] driver_register+0x5b/0xd0 [ 2.789994] [] usb_register_driver+0x7c/0x130 [usbcore] [ 2.789994] [] ? 0xffffffffa06a5000 [ 2.789996] [] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u] [ 2.789997] [] do_one_initcall+0x38/0x140 [ 2.789998] [] ? __vunmap+0x7c/0xc0 [ 2.789999] [] ? do_init_module+0x22/0x1d2 [ 2.790000] [] do_init_module+0x5a/0x1d2 [ 2.790002] [] load_module+0x1e11/0x2580 [ 2.790003] [] ? show_taint+0x30/0x30 [ 2.790004] [] ? kernel_read_file+0x100/0x190 [ 2.790005] [] SyS_finit_module+0xba/0xc0 [ 2.790007] [] entry_SYSCALL_64_fastpath+0x13/0x94 [ 2.790008] ---[ end trace c78a74e78baec6fc ]--- So, allocate the structure dynamically. Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 2c0ad235ac77f2fc2eee593bf06822cad772e0e2 Author: Kees Cook Date: Wed Apr 5 09:39:08 2017 -0700 mm: Tighten x86 /dev/mem with zeroing reads commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream. Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is disallowed. However, on x86, the first 1MB was always allowed for BIOS and similar things, regardless of it actually being System RAM. It was possible for heap to end up getting allocated in low 1MB RAM, and then read by things like x86info or dd, which would trip hardened usercopy: usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes) This changes the x86 exception for the low 1MB by reading back zeros for System RAM areas instead of blindly allowing them. More work is needed to extend this to mmap, but currently mmap doesn't go through usercopy, so hardened usercopy won't Oops the kernel. Reported-by: Tommi Rantala Tested-by: Tommi Rantala Signed-off-by: Kees Cook Cc: Brad Spengler Signed-off-by: Greg Kroah-Hartman commit ef793e6e113473f7cb08edf1ca4a8737c57ce51c Author: Thierry Reding Date: Thu Jan 12 17:07:43 2017 +0100 rtc: tegra: Implement clock handling commit 5fa4086987506b2ab8c92f8f99f2295db9918856 upstream. Accessing the registers of the RTC block on Tegra requires the module clock to be enabled. This only works because the RTC module clock will be enabled by default during early boot. However, because the clock is unused, the CCF will disable it at late_init time. This causes the RTC to become unusable afterwards. This can easily be reproduced by trying to use the RTC: $ hwclock --rtc /dev/rtc1 This will hang the system. I ran into this by following up on a report by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It turns out that the rtc-tegra driver's ->shutdown() implementation will hang the CPU, because of the disabled clock, before the system can be rebooted. What confused me for a while is that the same driver is used on prior Tegra generations where the hang can not be observed. However, as Peter De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC clock is enabled by the tegra20_timer.c clocksource driver, which uses the RTC to provide a persistent clock. This code is never enabled on 64-bit Tegra because the persistent clock infrastructure does not exist on 64-bit ARM. The proper fix for this is to add proper clock handling to the RTC driver in order to ensure that the clock is enabled when the driver requires it. All device trees contain the clock already, therefore no additional changes are required. Reported-by: Martin Michlmayr Acked-By Peter De Schrijver Signed-off-by: Thierry Reding Signed-off-by: Alexandre Belloni [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 0dd962118a201a19d8c5c01e4909bfc07c288d6c Author: Lv Zheng Date: Fri Jan 20 16:42:48 2017 +0800 ACPI / EC: Use busy polling mode when GPE is not enabled commit c3a696b6e8f8f75f9f75e556a9f9f6472eae2655 upstream. When GPE is not enabled, it is not efficient to use the wait polling mode as it introduces an unexpected scheduler delay. So before the GPE handler is installed, this patch uses busy polling mode for all EC(s) and the logic can be applied to non boot EC(s) during the suspend/resume process. Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561 Tested-by: Jakobus Schurz Tested-by: Chen Yu Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit c07479f4b10ac3faa5168881e7751681d59de7e7 Author: Mohit Gambhir Date: Thu Jan 26 13:12:27 2017 -0500 x86/xen: Fix APIC id mismatch warning on Intel commit cc272163ea554a97dac180fa8dd6cd54c2810bd1 upstream. This patch fixes the following warning message seen when booting the kernel as Dom0 with Xen on Intel machines. [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1] The code generating the warning in validate_apic_and_package_id() matches cpu_data(cpu).apicid (initialized in init_intel()-> detect_extended_topology() using cpuid) against the apicid returned from xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid for the boot cpu but returns 0 otherwise. Hence the warning gets thrown for all but the boot cpu. The idea behind xen_apic_read() returning 0 for apicid is that the guests (even Dom0) should not need to know what physical processor their vcpus are running on. This is because we currently do not have topology information in Xen and also because xen allows more vcpus than physical processors. However, boot cpu's apicid is required for loading xen-acpi-processor driver on AMD machines. Look at following patch for details: commit 558daa289a40 ("xen/apic: Return the APIC ID (and version) for CPU 0.") So to get rid of the warning, this patch modifies xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of calling xen_apic_read(). The warning is not seen on AMD machines because init_amd() populates cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read() as opposed to using apicid from cpuid as is done on Intel machines. Signed-off-by: Mohit Gambhir Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 03470ba96a96754573db076b2700544843be8aa9 Author: Lee, Chun-Yi Date: Thu Nov 3 08:18:52 2016 +0800 platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event commit 98d610c3739ac354319a6590b915f4624d9151e6 upstream. The accelerometer event relies on the ACERWMID_EVENT_GUID notify. So, this patch changes the codes to setup accelerometer input device when detected ACERWMID_EVENT_GUID. It avoids that the accel input device created on every Acer machines. In addition, patch adds a clearly parsing logic of accelerometer hid to acer_wmi_get_handle_cb callback function. It is positive matching the "SENR" name with "BST0001" device to avoid non-supported hardware. Reported-by: Bjørn Mork Cc: Darren Hart Signed-off-by: Lee, Chun-Yi [andy: slightly massage commit message] Signed-off-by: Andy Shevchenko Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit a6ca4946676b8855ebc81b72a9ced3f64dc5f1d4 Author: Andy Shevchenko Date: Mon Jan 16 15:12:26 2017 +0200 ASoC: Intel: select DW_DMAC_CORE since it's mandatory commit ebf79091bf85d9b2270ab29191de9cd3aaf888c5 upstream. Select DW_DMAC_CORE like the rest of glue drivers do, e.g. drivers/dma/dw/Kconfig. While here group selectors under SND_SOC_INTEL_HASWELL and SND_SOC_INTEL_BAYTRAIL. Make platforms, which are using a common SST firmware driver, to be dependent on DMADEVICES. Signed-off-by: Andy Shevchenko Acked-by: Liam Girdwood Signed-off-by: Mark Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 25640e792f1a938f4cda99b86c43998cb70c2d27 Author: Jens Axboe Date: Sat Dec 3 12:08:03 2016 -0700 nbd: fix 64-bit division commit e88f72cb9f54f6d244e55f629fe5e2f34ca6f9ed upstream. We have this: ERROR: "__aeabi_ldivmod" [drivers/block/nbd.ko] undefined! ERROR: "__divdi3" [drivers/block/nbd.ko] undefined! nbd.c:(.text+0x247c72): undefined reference to `__divdi3' due to a recent commit, that did 64-bit division. Use the proper divider function so that 32-bit compiles don't break. Fixes: ef77b515243b ("nbd: use loff_t for blocksize and nbd_set_size args") Signed-off-by: Jens Axboe Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 7599166d785552bd8b4abff6eb222fa9efc616fa Author: Josef Bacik Date: Fri Dec 2 16:19:12 2016 -0500 nbd: use loff_t for blocksize and nbd_set_size args commit ef77b515243b3499d62cf446eda6ca7e0a0b079c upstream. If we have large devices (say like the 40t drive I was trying to test with) we will end up overflowing the int arguments to nbd_set_size and not get the right size for our device. Fix this by using loff_t everywhere so I don't have to think about this again. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe [bwh: Backported to 4.9: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 9c0c4352726368fca2760b9b9a7d808ce86871c7 Author: Ben Skeggs Date: Mon Jan 9 10:22:15 2017 +1000 drm/nouveau/disp/mcp7x: disable dptmds workaround commit 7dfee6827780d4228148263545af936d0cae8930 upstream. The workaround appears to cause regressions on these boards, and from inspection of RM traces, NVIDIA don't appear to do it on them either. Signed-off-by: Ben Skeggs Tested-by: Roy Spliet Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 754ae7efb383690785265c8e9b032fda63be00ce Author: Vladimir Davydov Date: Mon Dec 12 16:41:29 2016 -0800 mm: memcontrol: use special workqueue for creating per-memcg caches commit 13583c3d3224508582ec03d881d0b68dd3ee8e10 upstream. Creating a lot of cgroups at the same time might stall all worker threads with kmem cache creation works, because kmem cache creation is done with the slab_mutex held. The problem was amplified by commits 801faf0db894 ("mm/slab: lockless decision to grow cache") in case of SLAB and 81ae6d03952c ("mm/slub.c: replace kick_all_cpus_sync() with synchronize_sched() in kmem_cache_shrink()") in case of SLUB, which increased the maximal time the slab_mutex can be held. To prevent that from happening, let's use a special ordered single threaded workqueue for kmem cache creation. This shouldn't introduce any functional changes regarding how kmem caches are created, as the work function holds the global slab_mutex during its whole runtime anyway, making it impossible to run more than one work at a time. By using a single threaded workqueue, we just avoid creating a thread per each work. Ordering is required to avoid a situation when a cgroup's work is put off indefinitely because there are other cgroups to serve, in other words to guarantee fairness. Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981 Link: http://lkml.kernel.org/r/20161004131417.GC1862@esperanza Signed-off-by: Vladimir Davydov Reported-by: Doug Smythies Acked-by: Michal Hocko Cc: Christoph Lameter Cc: David Rientjes Cc: Johannes Weiner Cc: Joonsoo Kim Cc: Pekka Enberg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit b1574caf96642113d1507ec637cc986acc4b61af Author: Daeho Jeong Date: Thu Dec 1 11:49:12 2016 -0500 ext4: fix inode checksum calculation problem if i_extra_size is small commit 05ac5aa18abd7db341e54df4ae2b4c98ea0e43b7 upstream. We've fixed the race condition problem in calculating ext4 checksum value in commit b47820edd163 ("ext4: avoid modifying checksum fields directly during checksum veficationon"). However, by this change, when calculating the checksum value of inode whose i_extra_size is less than 4, we couldn't calculate the checksum value in a proper way. This problem was found and reported by Nix, Thank you. Reported-by: Nix Signed-off-by: Daeho Jeong Signed-off-by: Youngjin Gil Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1992564156b5dc4ac73418e5b95e1a43f12f3cb1 Author: Arnd Bergmann Date: Thu Feb 2 12:36:01 2017 -0200 dvb-usb-v2: avoid use-after-free commit 005145378c9ad7575a01b6ce1ba118fb427f583a upstream. I ran into a stack frame size warning because of the on-stack copy of the USB device structure: drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usbv2_disconnect': drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1029:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Copying a device structure like this is wrong for a number of other reasons too aside from the possible stack overflow. One of them is that the dev_info() call will print the name of the device later, but AFAICT we have only copied a pointer to the name earlier and the actual name has been freed by the time it gets printed. This removes the on-stack copy of the device and instead copies the device name using kstrdup(). I'm ignoring the possible failure here as both printk() and kfree() are able to deal with NULL pointers. Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit de75264ee112b8c7353fc7ba13096690a6d3bcbe Author: Miaoqing Pan Date: Wed Nov 16 17:23:08 2016 +0800 ath9k: fix NULL pointer dereference commit 40bea976c72b9ee60f8d097852deb53ccbeaffbe upstream. relay_open() may return NULL, check the return value to avoid the crash. BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 IP: [] ath_cmn_process_fft+0xd5/0x700 [ath9k_common] PGD 41cf28067 PUD 41be92067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35 Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15 07/04/2011 task: ffffffff81e0c4c0 task.stack: ffffffff81e00000 RIP: 0010:[] [] ath_cmn_process_fft+0xd5/0x700 [ath9k_common] RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98 RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0 Stack: 0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9 000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0 0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60 Call Trace: [] ath9k_tasklet+0x1b1/0x220 [ath9k] [] tasklet_action+0x4d/0xf0 [] __do_softirq+0x92/0x2a0 Reported-by: Devin Tuchsen Tested-by: Devin Tuchsen Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit a28acecbaf25b0ab71d62b6b64b6bd75f9892bb1 Author: Helge Deller Date: Sun Apr 16 10:00:14 2017 +0200 parisc: Fix get_user() for 64-bit value on 32-bit kernel commit 3f795cef0ecdf9bc980dd058d49bdab4b19af1d3 upstream. This fixes a bug in which the upper 32-bits of a 64-bit value which is read by get_user() was lost on a 32-bit kernel. While touching this code, split out pre-loading of %sr2 space register and clean up code indent. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit c10479591869177ae7ac0570b54ace6fbdeb57c2 Author: Herbert Xu Date: Mon Apr 10 17:27:57 2017 +0800 crypto: ahash - Fix EINPROGRESS notification callback commit ef0579b64e93188710d48667cb5e014926af9f1b upstream. The ahash API modifies the request's callback function in order to clean up after itself in some corner cases (unaligned final and missing finup). When the request is complete ahash will restore the original callback and everything is fine. However, when the request gets an EBUSY on a full queue, an EINPROGRESS callback is made while the request is still ongoing. In this case the ahash API will incorrectly call its own callback. This patch fixes the problem by creating a temporary request object on the stack which is used to relay EINPROGRESS back to the original completion function. This patch also adds code to preserve the original flags value. Fixes: ab6bf4e5e5e4 ("crypto: hash - Fix the pointer voodoo in...") Reported-by: Sabrina Dubroca Tested-by: Sabrina Dubroca Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 64ba06dc8a1d5c8e70b7b79a709bd1c90ec23afc Author: Herbert Xu Date: Mon Apr 10 17:59:07 2017 +0800 crypto: algif_aead - Fix bogus request dereference in completion function commit e6534aebb26e32fbab14df9c713c65e8507d17e4 upstream. The algif_aead completion function tries to deduce the aead_request from the crypto_async_request argument. This is broken because the API does not guarantee that the same request will be pased to the completion function. Only the value of req->data can be used in the completion function. This patch fixes it by storing a pointer to sk in areq and using that instead of passing in sk through req->data. Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to...") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7da0f8e547c2d3cac939da24458a88cce550af11 Author: Namhyung Kim Date: Mon Apr 17 11:44:27 2017 +0900 ftrace: Fix function pid filter on instances commit d879d0b8c183aabeb9a65eba91f3f9e3c7e7b905 upstream. When function tracer has a pid filter, it adds a probe to sched_switch to track if current task can be ignored. The probe checks the ftrace_ignore_pid from current tr to filter tasks. But it misses to delete the probe when removing an instance so that it can cause a crash due to the invalid tr pointer (use-after-free). This is easily reproducible with the following: # cd /sys/kernel/debug/tracing # mkdir instances/buggy # echo $$ > instances/buggy/set_ftrace_pid # rmdir instances/buggy ============================================================================ BUG: KASAN: use-after-free in ftrace_filter_pid_sched_switch_probe+0x3d/0x90 Read of size 8 by task kworker/0:1/17 CPU: 0 PID: 17 Comm: kworker/0:1 Tainted: G B 4.11.0-rc3 #198 Call Trace: dump_stack+0x68/0x9f kasan_object_err+0x21/0x70 kasan_report.part.1+0x22b/0x500 ? ftrace_filter_pid_sched_switch_probe+0x3d/0x90 kasan_report+0x25/0x30 __asan_load8+0x5e/0x70 ftrace_filter_pid_sched_switch_probe+0x3d/0x90 ? fpid_start+0x130/0x130 __schedule+0x571/0xce0 ... To fix it, use ftrace_clear_pids() to unregister the probe. As instance_rmdir() already updated ftrace codes, it can just free the filter safely. Link: http://lkml.kernel.org/r/20170417024430.21194-2-namhyung@kernel.org Fixes: 0c8916c34203 ("tracing: Add rmdir to remove multibuffer instances") Cc: Ingo Molnar Reviewed-by: Masami Hiramatsu Signed-off-by: Namhyung Kim Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit e3c7258bb4fe5b509621ce643f096502dceec8a4 Author: Minchan Kim Date: Thu Apr 13 14:56:37 2017 -0700 zram: do not use copy_page with non-page aligned address commit d72e9a7a93e4f8e9e52491921d99e0c8aa89eb4e upstream. The copy_page is optimized memcpy for page-alinged address. If it is used with non-page aligned address, it can corrupt memory which means system corruption. With zram, it can happen with 1. 64K architecture 2. partial IO 3. slub debug Partial IO need to allocate a page and zram allocates it via kmalloc. With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned address. And finally, copy_page(mem, cmem) corrupts memory. So, this patch changes it to memcpy. Actuaully, we don't need to change zram_bvec_write part because zsmalloc returns page-aligned address in case of PAGE_SIZE class but it's not good to rely on the internal of zsmalloc. Note: When this patch is merged to stable, clear_page should be fixed, too. Unfortunately, recent zram removes it by "same page merge" feature so it's hard to backport this patch to -stable tree. I will handle it when I receive the mail from stable tree maintainer to merge this patch to backport. Fixes: 42e99bd ("zram: optimize memory operations with clear_page()/copy_page()") Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.org Signed-off-by: Minchan Kim Cc: Sergey Senozhatsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 75465e71ec3139b958d06d48dfc85720aed69b6a Author: Paolo Bonzini Date: Tue Jan 24 11:56:21 2017 +0100 kvm: fix page struct leak in handle_vmon commit 06ce521af9558814b8606c0476c54497cf83a653 upstream. handle_vmon gets a reference on VMXON region page, but does not release it. Release the reference. Found by syzkaller; based on a patch by Dmitry. Reported-by: Dmitry Vyukov Signed-off-by: Paolo Bonzini [bwh: Backported to 3.16: use skip_emulated_instruction()] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 5a4c0738998a037f4d29dc3f25215f4e2cc98919 Author: Greg Kroah-Hartman Date: Tue Apr 18 16:16:57 2017 +0200 Revert "MIPS: Lantiq: Fix cascaded IRQ setup" This reverts commit 362721c4957dcda7b1fbd45380e7a6617a1d077c which is commit 6c356eda225e3ee134ed4176b9ae3a76f793f4dd upstream. It shouldn't have been included in a stable release. Reported-by: Amit Pundir Cc: Felix Fietkau Cc: John Crispin Cc: James Hogan Signed-off-by: Greg Kroah-Hartman commit a9da1ac37ccfc29e8b29855604477a09c9b7b114 Author: Max Bires Date: Tue Jan 3 08:18:07 2017 -0800 char: lack of bool string made CONFIG_DEVPORT always on commit f2cfa58b136e4b06a9b9db7af5ef62fbb5992f62 upstream. Without a bool string present, using "# CONFIG_DEVPORT is not set" in defconfig files would not actually unset devport. This esnured that /dev/port was always on, but there are reasons a user may wish to disable it (smaller kernel, attack surface reduction) if it's not being used. Adding a message here in order to make this user visible. Signed-off-by: Max Bires Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 666452ffdbf700d8ca15d0b75070f3487ccae4fc Author: Steven Rostedt (VMware) Date: Fri Apr 14 17:45:45 2017 -0400 ftrace: Fix removing of second function probe commit 82cc4fc2e70ec5baeff8f776f2773abc8b2cc0ae upstream. When two function probes are added to set_ftrace_filter, and then one of them is removed, the update to the function locations is not performed, and the record keeping of the function states are corrupted, and causes an ftrace_bug() to occur. This is easily reproducable by adding two probes, removing one, and then adding it back again. # cd /sys/kernel/debug/tracing # echo schedule:traceoff > set_ftrace_filter # echo do_IRQ:traceoff > set_ftrace_filter # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter # echo do_IRQ:traceoff > set_ftrace_filter Causes: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 ftrace_get_addr_curr+0x143/0x220 Modules linked in: [...] CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 Call Trace: dump_stack+0x68/0x9f __warn+0x111/0x130 ? trace_irq_work_interrupt+0xa0/0xa0 warn_slowpath_null+0x1d/0x20 ftrace_get_addr_curr+0x143/0x220 ? __fentry__+0x10/0x10 ftrace_replace_code+0xe3/0x4f0 ? ftrace_int3_handler+0x90/0x90 ? printk+0x99/0xb5 ? 0xffffffff81000000 ftrace_modify_all_code+0x97/0x110 arch_ftrace_update_code+0x10/0x20 ftrace_run_update_code+0x1c/0x60 ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0 register_ftrace_function_probe+0x4b6/0x590 ? ftrace_startup+0x310/0x310 ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30 ? update_stack_state+0x88/0x110 ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320 ? preempt_count_sub+0x18/0xd0 ? mutex_lock_nested+0x104/0x800 ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320 ? __unwind_start+0x1c0/0x1c0 ? _mutex_lock_nest_lock+0x800/0x800 ftrace_trace_probe_callback.isra.3+0xc0/0x130 ? func_set_flag+0xe0/0xe0 ? __lock_acquire+0x642/0x1790 ? __might_fault+0x1e/0x20 ? trace_get_user+0x398/0x470 ? strcmp+0x35/0x60 ftrace_trace_onoff_callback+0x48/0x70 ftrace_regex_write.isra.43.part.44+0x251/0x320 ? match_records+0x420/0x420 ftrace_filter_write+0x2b/0x30 __vfs_write+0xd7/0x330 ? do_loop_readv_writev+0x120/0x120 ? locks_remove_posix+0x90/0x2f0 ? do_lock_file_wait+0x160/0x160 ? __lock_is_held+0x93/0x100 ? rcu_read_lock_sched_held+0x5c/0xb0 ? preempt_count_sub+0x18/0xd0 ? __sb_start_write+0x10a/0x230 ? vfs_write+0x222/0x240 vfs_write+0xef/0x240 SyS_write+0xab/0x130 ? SyS_read+0x130/0x130 ? trace_hardirqs_on_caller+0x182/0x280 ? trace_hardirqs_on_thunk+0x1a/0x1c entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x7fe61c157c30 RSP: 002b:00007ffe87890258 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: ffffffff8114a410 RCX: 00007fe61c157c30 RDX: 0000000000000010 RSI: 000055814798f5e0 RDI: 0000000000000001 RBP: ffff8800c9027f98 R08: 00007fe61c422740 R09: 00007fe61ca53700 R10: 0000000000000073 R11: 0000000000000246 R12: 0000558147a36400 R13: 00007ffe8788f160 R14: 0000000000000024 R15: 00007ffe8788f15c ? trace_hardirqs_off_caller+0xc0/0x110 ---[ end trace 99fa09b3d9869c2c ]--- Bad trampoline accounting at: ffffffff81cc3b00 (do_IRQ+0x0/0x150) Fixes: 59df055f1991 ("ftrace: trace different functions with a different tracer") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit fdaa36c75c5a1bf7cdd2f463f8d320c98c6f0761 Author: Tyler Baker Date: Thu Apr 13 15:27:31 2017 -0700 irqchip/irq-imx-gpcv2: Fix spinlock initialization commit 75eb5e1e7b4edbc8e8f930de59004d21cb46961f upstream. The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before usage. That results in a lockdep splat: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Add the missing raw_spin_lock_init() to the setup code. Fixes: e324c4dc4a59 ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources") Signed-off-by: Tyler Baker Reviewed-by: Fabio Estevam Cc: jason@lakedaemon.net Cc: marc.zyngier@arm.com Cc: shawnguo@kernel.org Cc: andrew.smirnov@gmail.com Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 5dda157006bc29986f4f168f485ecbb6f5cf5b3d Author: Chen Yu Date: Sun Apr 9 13:45:16 2017 +0800 cpufreq: Bring CPUs up even if cpufreq_online() failed commit c4a3fa261b16858416f1fd7db03a33d7ef5fc0b3 upstream. There is a report that after commit 27622b061eb4 ("cpufreq: Convert to hotplug state machine"), the normal CPU offline/online cycle fails on some platforms. According to the ftrace result, this problem was triggered on platforms using acpi-cpufreq as the default cpufreq driver, and due to the lack of some ACPI freq method (eg. _PCT), cpufreq_online() failed and returned a negative value, so the CPU hotplug state machine rolled back the CPU online process. Actually, from the user's perspective, the failure of cpufreq_online() should not prevent that CPU from being brought up, although cpufreq might not work on that CPU. BTW, during system startup cpufreq_online() is not invoked via CPU online but by the cpufreq device creation process, so the APs can be brought up even though cpufreq_online() fails in that stage. This patch ignores the return value of cpufreq_online/offline() and lets the cpufreq framework deal with the failure. cpufreq_online() itself will do a proper rollback in that case and if _PCT is missing, the ACPI cpufreq driver will print a warning if the corresponding debug options have been enabled. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194581 Fixes: 27622b061eb4 ("cpufreq: Convert to hotplug state machine") Reported-and-tested-by: Tomasz Maciej Nowak Signed-off-by: Chen Yu Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5f48cacaa72c110b048b73ab928abf70f6ee163e Author: David Wu Date: Wed Mar 1 19:10:55 2017 +0800 pwm: rockchip: State of PWM clock should synchronize with PWM enabled state commit a900152b5c29aea8134cc7a4c5db25552b3cd8f7 upstream. If the PWM was not enabled at U-Boot loader, PWM could not work for clock always disabled at PWM driver. The PWM clock is enabled at beginning of pwm_apply(), but disabled at end of pwm_apply(). If the PWM was enabled at U-Boot loader, PWM clock is always enabled unless closed by ATF. The pwm-backlight might turn off the power at early suspend, should disable PWM clock for saving power consume. It is important to provide opportunity to enable/disable clock at PWM driver, the PWM consumer should ensure correct order to call PWM enable and disable, and PWM driver ensure state of PWM clock synchronized with PWM enabled state. Fixes: 2bf1c98aa5a4 ("pwm: rockchip: Add support for atomic update") Signed-off-by: David Wu Reviewed-by: Boris Brezillon Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 088e5800500e30632b11c4332bcf5923994dc22f Author: Markus Marb Date: Fri Mar 17 23:14:47 2017 +0100 can: ifi: use correct register to read rx status commit 57c1d4c33e8f7ec90976d79127059c1919cc0651 upstream. The incorrect offset was used when trying to read the RXSTCMD register. Signed-off-by: Markus Marb Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5ac50e714f6040904496fae508a2cdb9b6e8a210 Author: Dan Williams Date: Fri Apr 7 09:47:24 2017 -0700 libnvdimm: fix reconfig_mutex, mmap_sem, and jbd2_handle lockdep splat commit 0beb2012a1722633515c8aaa263c73449636c893 upstream. Holding the reconfig_mutex over a potential userspace fault sets up a lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl path. Move the user access outside of the lock. [ INFO: possible circular locking dependency detected ] 4.11.0-rc3+ #13 Tainted: G W O ------------------------------------------------------- fallocate/16656 is trying to acquire lock: (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [] nvdimm_bus_lock+0x21/0x30 [libnvdimm] but task is already holding lock: (jbd2_handle){++++..}, at: [] start_this_handle+0x104/0x460 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (jbd2_handle){++++..}: lock_acquire+0xbd/0x200 start_this_handle+0x16a/0x460 jbd2__journal_start+0xe9/0x2d0 __ext4_journal_start_sb+0x89/0x1c0 ext4_dirty_inode+0x32/0x70 __mark_inode_dirty+0x235/0x670 generic_update_time+0x87/0xd0 touch_atime+0xa9/0xd0 ext4_file_mmap+0x90/0xb0 mmap_region+0x370/0x5b0 do_mmap+0x415/0x4f0 vm_mmap_pgoff+0xd7/0x120 SyS_mmap_pgoff+0x1c5/0x290 SyS_mmap+0x22/0x30 entry_SYSCALL_64_fastpath+0x1f/0xc2 -> #1 (&mm->mmap_sem){++++++}: lock_acquire+0xbd/0x200 __might_fault+0x70/0xa0 __nd_ioctl+0x683/0x720 [libnvdimm] nvdimm_ioctl+0x8b/0xe0 [libnvdimm] do_vfs_ioctl+0xa8/0x740 SyS_ioctl+0x79/0x90 do_syscall_64+0x6c/0x200 return_from_SYSCALL_64+0x0/0x7a -> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}: __lock_acquire+0x16b6/0x1730 lock_acquire+0xbd/0x200 __mutex_lock+0x88/0x9b0 mutex_lock_nested+0x1b/0x20 nvdimm_bus_lock+0x21/0x30 [libnvdimm] nvdimm_forget_poison+0x25/0x50 [libnvdimm] nvdimm_clear_poison+0x106/0x140 [libnvdimm] pmem_do_bvec+0x1c2/0x2b0 [nd_pmem] pmem_make_request+0xf9/0x270 [nd_pmem] generic_make_request+0x118/0x3b0 submit_bio+0x75/0x150 Fixes: 62232e45f4a2 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices") Cc: Dave Jiang Reported-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 5f377c4ad27190523099bfd0ac69197961ed2637 Author: Dan Williams Date: Tue Apr 4 15:08:36 2017 -0700 libnvdimm: fix blk free space accounting commit fe514739d8538783749d3ce72f78e5a999ea5668 upstream. Commit a1f3e4d6a0c3 "libnvdimm, region: update nd_region_available_dpa() for multi-pmem support" reworked blk dpa (DIMM Physical Address) accounting to comprehend multiple pmem namespace allocations aliasing with a given blk-dpa range. The following call trace is a result of failing to account for allocated blk capacity. WARNING: CPU: 1 PID: 2433 at tools/testing/nvdimm/../../../drivers/nvdimm/names 4 size_store+0x6f3/0x930 [libnvdimm] nd_region region5: allocation underrun: 0x0 of 0x1000000 bytes [..] Call Trace: dump_stack+0x86/0xc3 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 size_store+0x6f3/0x930 [libnvdimm] dev_attr_store+0x18/0x30 If a given blk-dpa allocation does not alias with any pmem ranges then the full allocation should be accounted as busy space, not the size of the current pmem contribution to the region. The thinkos that led to this confusion was not realizing that the struct resource management is already guaranteeing no collisions between pmem allocations and blk allocations on the same dimm. Also, we do not try to support blk allocations in aliased pmem holes. This patch also fixes a case where the available blk goes negative. Fixes: a1f3e4d6a0c3 ("libnvdimm, region: update nd_region_available_dpa() for multi-pmem support"). Reported-by: Dariusz Dokupil Reported-by: Dave Jiang Reported-by: Vishal Verma Tested-by: Dave Jiang Tested-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 0c6172ccbb59e7fab17c19dc7c9a753c3429cfd7 Author: Al Viro Date: Fri Feb 17 20:16:34 2017 -0500 make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error commit 3278682123811dd8ef07de5eb701fc4548fcebf2 upstream. Fixes the mess observed in e.g. rsync over a noisy link we'd been seeing since last Summer. What happens is that we copy part of a datagram before noticing a checksum mismatch. Datagram will be resent, all right, but we want the next try go into the same place, not after it... All this family of primitives (copy/checksum and copy a datagram into destination) is "all or nothing" sort of interface - either we get 0 (meaning that copy had been successful) or we get an error (and no way to tell how much had been copied before we ran into whatever error it had been). Make all of them leave iterator unadvanced in case of errors - all callers must be able to cope with that (an error might've been caught before the iterator had been advanced), it costs very little to arrange, it's safer for callers and actually fixes at least one bug in said callers. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit ff76ab9e03a50a4df26329e547e75f865a2bfa9f Author: Al Viro Date: Fri Feb 17 18:42:24 2017 -0500 new privimitive: iov_iter_revert() commit 27c0e3748e41ca79171ffa3e97415a20af6facd0 upstream. opposite to iov_iter_advance(); the caller is responsible for never using it to move back past the initial position. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e485875dff38c79479ba42f80f0230d181a77a56 Author: Juergen Gross Date: Fri Apr 7 17:28:23 2017 +0200 xen, fbfront: fix connecting to backend commit 9121b15b5628b38b4695282dc18c553440e0f79b upstream. Connecting to the backend isn't working reliably in xen-fbfront: in case XenbusStateInitWait of the backend has been missed the backend transition to XenbusStateConnected will trigger the connected state only without doing the actions required when the backend has connected. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman commit 92f8aa7bb825eafc3686cdda6dbbce44d8b35e75 Author: Nicholas Bellinger Date: Mon Mar 27 16:12:43 2017 -0700 target: Avoid mappedlun symlink creation during lun shutdown commit 49cb77e297dc611a1b795cfeb79452b3002bd331 upstream. This patch closes a race between se_lun deletion during configfs unlink in target_fabric_port_unlink() -> core_dev_del_lun() -> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks waiting for percpu_ref RCU grace period to finish, but a new NodeACL mappedlun is added before the RCU grace period has completed. This can happen in target_fabric_mappedlun_link() because it only checks for se_lun->lun_se_dev, which is not cleared until after transport_clear_lun_ref() percpu_ref RCU grace period finishes. This bug originally manifested as NULL pointer dereference OOPsen in target_stat_scsi_att_intr_port_show_attr_dev() on v4.1.y code, because it dereferences lun->lun_se_dev without a explicit NULL pointer check. In post v4.1 code with target-core RCU conversion, the code in target_stat_scsi_att_intr_port_show_attr_dev() no longer uses se_lun->lun_se_dev, but the same race still exists. To address the bug, go ahead and set se_lun>lun_shutdown as early as possible in core_tpg_remove_lun(), and ensure new NodeACL mappedlun creation in target_fabric_mappedlun_link() fails during se_lun shutdown. Reported-by: James Shen Cc: James Shen Tested-by: James Shen Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 08383b004426591502b86bfacdc638d85cedf26c Author: Martin K. Petersen Date: Tue Apr 4 10:42:30 2017 -0400 scsi: sd: Fix capacity calculation with 32-bit sector_t commit 7c856152cb92f8eee2df29ef325a1b1f43161aff upstream. We previously made sure that the reported disk capacity was less than 0xffffffff blocks when the kernel was not compiled with large sector_t support (CONFIG_LBDAF). However, this check assumed that the capacity was reported in units of 512 bytes. Add a sanity check function to ensure that we only enable disks if the entire reported capacity can be expressed in terms of sector_t. Reported-by: Steve Magnani Cc: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 64e746983c4c8c88393866485cbca1782071aeb1 Author: Sawan Chandak Date: Fri Mar 31 14:37:03 2017 -0700 scsi: qla2xxx: Add fix to read correct register value for ISP82xx. commit bf6061b17a8d47ef0d9344d3ef576a4ff0edf793 upstream. Add fix to read correct register value for ISP82xx, during check for register disconnect.ISP82xx has different base register. Fixes: a465537ad1a4 ("qla2xxx: Disable the adapter and skip error recovery in case of register disconnect") Signed-off-by: Sawan Chandak Signed-off-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 82d181d7540fed18ee48487d252dc60920c16d18 Author: Fam Zheng Date: Tue Mar 28 12:41:26 2017 +0800 scsi: sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable commit 6780414519f91c2a84da9baa963a940ac916f803 upstream. If device reports a small max_xfer_blocks and a zero opt_xfer_blocks, we end up using BLK_DEF_MAX_SECTORS, which is wrong and r/w of that size may get error. [mkp: tweaked to avoid setting rw_max twice and added typecast] Fixes: ca369d51b3e ("block/sd: Fix device-imposed transfer length limits") Signed-off-by: Fam Zheng Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c80c158bfe613d346d48803462bf55d8f35d228e Author: Martin K. Petersen Date: Fri Mar 17 08:47:14 2017 -0400 scsi: sr: Sanity check returned mode data commit a00a7862513089f17209b732f230922f1942e0b9 upstream. Kefeng Wang discovered that old versions of the QEMU CD driver would return mangled mode data causing us to walk off the end of the buffer in an attempt to parse it. Sanity check the returned mode sense data. Reported-by: Kefeng Wang Tested-by: Kefeng Wang Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 281e36cbaf4395bf036a8301d20906d0fcbdfc72 Author: Nicholas Bellinger Date: Sun Apr 2 13:36:44 2017 -0700 iscsi-target: Drop work-around for legacy GlobalSAN initiator commit 1c99de981f30b3e7868b8d20ce5479fa1c0fea46 upstream. Once upon a time back in 2009, a work-around was added to support the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login did not propose nor respond to MaxBurstLength, FirstBurstLength, DefaultTime2Wait and DefaultTime2Retain keys. The work-around in iscsi_check_proposer_for_optional_reply() allowed the missing keys to be proposed, but did not require waiting for a response before moving to full feature phase operation. This allowed GlobalSAN v3.3 to work out-of-the box, and for many years we didn't run into login interopt issues with any other initiators.. Until recently, when Martin tried a QLogic 57840S iSCSI Offload HBA on Windows 2016 which completed login, but subsequently failed with: Got unknown iSCSI OpCode: 0x43 The issue was QLogic MSFT side did not propose DefaultTime2Wait + DefaultTime2Retain, so LIO proposes them itself, and immediately transitions to full feature phase because of the GlobalSAN hack. However, the QLogic MSFT side still attempts to respond to DefaultTime2Retain + DefaultTime2Wait, even though LIO has set ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT in last login response. So while the QLogic MSFT side should have been proposing these two keys to start, it was doing the correct thing per RFC-3720 attempting to respond to proposed keys before transitioning to full feature phase. All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541) does correctly propose the four keys during login, making the original work-around moot. So in order to allow QLogic MSFT to run unmodified as-is, go ahead and drop this long standing work-around. Reported-by: Martin Svec Cc: Martin Svec Cc: Himanshu Madhani Cc: Arun Easi Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 0ae3c95e3a31958bfb44bffe0beed12663700ba5 Author: Nicholas Bellinger Date: Thu Mar 23 17:19:24 2017 -0700 iscsi-target: Fix TMR reference leak during session shutdown commit efb2ea770bb3b0f40007530bc8b0c22f36e1c5eb upstream. This patch fixes a iscsi-target specific TMR reference leak during session shutdown, that could occur when a TMR was quiesced before the hand-off back to iscsi-target code via transport_cmd_check_stop_to_fabric(). The reference leak happens because iscsit_free_cmd() was incorrectly skipping the final target_put_sess_cmd() for TMRs when transport_generic_free_cmd() returned zero because the se_cmd->cmd_kref did not reach zero, due to the missing se_cmd assignment in original code. The result was iscsi_cmd and it's associated se_cmd memory would be freed once se_sess->sess_cmd_map where released, but the associated se_tmr_req was leaked and remained part of se_device->dev_tmr_list. This bug would manfiest itself as kernel paging request OOPsen in core_tmr_lun_reset(), when a left-over se_tmr_req attempted to dereference it's se_cmd pointer that had already been released during normal session shutdown. To address this bug, go ahead and treat ISCSI_OP_SCSI_CMD and ISCSI_OP_SCSI_TMFUNC the same when there is an extra se_cmd->cmd_kref to drop in iscsit_free_cmd(), and use op_scsi to signal __iscsit_free_cmd() when the former needs to clear any further iscsi related I/O state. Reported-by: Rob Millner Cc: Rob Millner Reported-by: Chu Yuan Lin Cc: Chu Yuan Lin Tested-by: Chu Yuan Lin Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit eff58f9084a099fd7afe54b0bdcb68d4fbdbdd89 Author: Ard Biesheuvel Date: Tue Apr 4 16:27:44 2017 +0100 efi/fb: Avoid reconfiguration of BAR that covers the framebuffer commit 55d728a40d368ba80443be85c02e641fc9082a3f upstream. On UEFI systems, the PCI subsystem is enumerated by the firmware, and if a graphical framebuffer is exposed via a PCI device, its base address and size are exposed to the OS via the Graphics Output Protocol (GOP). On arm64 PCI systems, the entire PCI hierarchy is reconfigured from scratch at boot. This may result in the GOP framebuffer address to become stale, if the BAR covering the framebuffer is modified. This will cause the framebuffer to become unresponsive, and may in some cases result in unpredictable behavior if the range is reassigned to another device. So add a non-x86 quirk to the EFI fb driver to find the BAR associated with the GOP base address, and claim the BAR resource so that the PCI core will not move it. Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: leif.lindholm@linaro.org Cc: linux-efi@vger.kernel.org Cc: lorenzo.pieralisi@arm.com Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 60174fb3eaa6c84273f282125c4cccdc701549a8 Author: Cohen, Eugene Date: Tue Apr 4 16:27:43 2017 +0100 efi/libstub: Skip GOP with PIXEL_BLT_ONLY format commit 540f4c0e894f7e46a66dfa424b16424cbdc12c38 upstream. The UEFI Specification permits Graphics Output Protocol (GOP) instances without direct framebuffer access. This is indicated in the Mode structure with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the kernel does not know how to drive a Blt() only framebuffer (which is only permitted before ExitBootServices() anyway), we should disregard such framebuffers when looking for a GOP instance that is suitable for use as the boot console. So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance, preventing attempts later in boot to use an invalid screen_info.lfb_base address. Signed-off-by: Eugene Cohen [ Moved the Blt() only check into the loop and clarified that Blt() only GOPs are unusable by the kernel. ] Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: leif.lindholm@linaro.org Cc: linux-efi@vger.kernel.org Cc: lorenzo.pieralisi@arm.com Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Link: http://lkml.kernel.org/r/20170404152744.26687-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1681bab7c450508b26f33368a8d1ec57d3fabfcc Author: Mikulas Patocka Date: Fri Apr 14 14:15:20 2017 -0400 parisc: fix bugs in pa_memcpy commit 409c1b250e30ad0e48b4d15d7319b4e18c046c4f upstream. The patch 554bfeceb8a22d448cd986fc9efce25e833278a1 ("parisc: Fix access fault handling in pa_memcpy()") reimplements the pa_memcpy function. Unfortunatelly, it makes the kernel unbootable. The crash happens in the function ide_complete_cmd where memcpy is called with the same source and destination address. This patch fixes a few bugs in pa_memcpy: * When jumping to .Lcopy_loop_16 for the first time, don't skip the instruction "ldi 31,t0" (this bug made the kernel unbootable) * Use the COND macro when comparing length, so that the comparison is 64-bit (a theoretical issue, in case the length is greater than 0xffffffff) * Don't use the COND macro after the "extru" instruction (the PA-RISC specification says that the upper 32-bits of extru result are undefined, although they are set to zero in practice) * Fix exception addresses in .Lcopy16_fault and .Lcopy8_fault * Rename .Lcopy_loop_4 to .Lcopy_loop_8 (so that it is consistent with .Lcopy8_fault) Fixes: 554bfeceb8a2 ("parisc: Fix access fault handling in pa_memcpy()") Signed-off-by: Mikulas Patocka Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 6ef2f0178649b3d3c502217c22c2dfe365c74091 Author: Rafael J. Wysocki Date: Tue Apr 11 00:23:42 2017 +0200 ACPI / scan: Set the visited flag for all enumerated devices commit f406270bf73d71ea7b35ee3f7a08a44f6594c9b1 upstream. Commit 10c7e20b2ff3 (ACPI / scan: fix enumeration (visited) flags for bus rescans) attempted to fix a problem with ACPI-based enumerateion of I2C/SPI devices, but it forgot to ensure that the visited flag will be set for all of the other enumerated devices, so fix that. Fixes: 10c7e20b2ff3 (ACPI / scan: fix enumeration (visited) flags for bus rescans) Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885 Reported-and-tested-by: Kevin Locke Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 0b914aa8cdc68c4e97ee48e5143cecd514cf1e6d Author: Dan Williams Date: Mon Mar 27 21:53:38 2017 -0700 acpi, nfit, libnvdimm: fix interleave set cookie calculation (64-bit comparison) commit b03b99a329a14b7302f37c3ea6da3848db41c8c5 upstream. While reviewing the -stable patch for commit 86ef58a4e35e "nfit, libnvdimm: fix interleave set cookie calculation" Ben noted: "This is returning an int, thus it's effectively doing a 32-bit comparison and not the 64-bit comparison you say is needed." Update the compare operation to be immune to this integer demotion problem. Cc: Nicholas Moulin Fixes: 86ef58a4e35e ("nfit, libnvdimm: fix interleave set cookie calculation") Reported-by: Ben Hutchings Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 5e29a45f1ef042a87933c0a72eb84fbc490358fa Author: Thomas Gleixner Date: Mon Apr 10 17:14:28 2017 +0200 x86/vdso: Plug race between mapping and ELF header setup commit 6fdc6dd90272ce7e75d744f71535cfbd8d77da81 upstream. The vsyscall32 sysctl can racy against a concurrent fork when it switches from disabled to enabled: arch_setup_additional_pages() if (vdso32_enabled) --> No mapping sysctl.vsysscall32() --> vdso32_enabled = true create_elf_tables() ARCH_DLINFO_IA32 if (vdso32_enabled) { --> Add VDSO entry with NULL pointer Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for the newly forked process or not. Signed-off-by: Thomas Gleixner Acked-by: Andy Lutomirski Cc: Peter Zijlstra Cc: Mathias Krause Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ec980b6f7dcc006f6859c0871c0d7298281f0394 Author: Mathias Krause Date: Mon Apr 10 17:14:27 2017 +0200 x86/vdso: Ensure vdso32_enabled gets set to valid values only commit c06989da39cdb10604d572c8c7ea8c8c97f3c483 upstream. vdso_enabled can be set to arbitrary integer values via the kernel command line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'. load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32 merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which causes a segfault when the application tries to use the VDSO. Restrict the valid arguments on the command line and the sysctl to 0 and 1. Fixes: b0b49f2673f0 ("x86, vdso: Remove compat vdso support") Signed-off-by: Mathias Krause Acked-by: Andy Lutomirski Cc: Peter Zijlstra Cc: Roland McGrath Link: http://lkml.kernel.org/r/1491424561-7187-1-git-send-email-minipli@googlemail.com Link: http://lkml.kernel.org/r/20170410151723.518412863@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit a9826aa4860a9ca1268a9ab5c10fc5e65a72b4ef Author: Dan Williams Date: Thu Apr 6 09:04:31 2017 -0700 x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions commit 11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd upstream. Before we rework the "pmem api" to stop abusing __copy_user_nocache() for memcpy_to_pmem() we need to fix cases where we may strand dirty data in the cpu cache. The problem occurs when copy_from_iter_pmem() is used for arbitrary data transfers from userspace. There is no guarantee that these transfers, performed by dax_iomap_actor(), will have aligned destinations or aligned transfer lengths. Backstop the usage __copy_user_nocache() with explicit cache management in these unaligned cases. Yes, copy_from_iter_pmem() is now too big for an inline, but addressing that is saved for a later patch that moves the entirety of the "pmem api" into the pmem driver directly. Fixes: 5de490daec8b ("pmem: add copy_from_iter_pmem() and clear_pmem()") Cc: Cc: Jan Kara Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: "H. Peter Anvin" Cc: Al Viro Cc: Thomas Gleixner Cc: Matthew Wilcox Reviewed-by: Ross Zwisler Signed-off-by: Toshi Kani Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 59bf2308895337fdf70b3a183e7f3c8723030982 Author: Joerg Roedel Date: Tue Apr 4 18:15:01 2017 +0200 x86/signals: Fix lower/upper bound reporting in compat siginfo commit cfac6dfa42bddfa9711b20d486e521d1a41ab09f upstream. Put the right values from the original siginfo into the userspace compat-siginfo. This fixes the 32-bit MPX "tabletest" testcase on 64-bit kernels. Signed-off-by: Joerg Roedel Acked-by: Dave Hansen Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: a4455082dc6f0 ('x86/signals: Add missing signal_compat code for x86 features') Link: http://lkml.kernel.org/r/1491322501-5054-1-git-send-email-joro@8bytes.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 41d8b02f6448af73203720c5ecf52eab798b1a40 Author: Omar Sandoval Date: Wed Apr 12 16:27:19 2017 +0100 x86/efi: Don't try to reserve runtime regions commit 6f6266a561306e206e0e31a5038f029b6a7b1d89 upstream. Reserving a runtime region results in splitting the EFI memory descriptors for the runtime region. This results in runtime region descriptors with bogus memory mappings, leading to interesting crashes like the following during a kexec: general protection fault: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53 Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016 RIP: 0010:virt_efi_set_variable() ... Call Trace: efi_delete_dummy_variable() efi_enter_virtual_mode() start_kernel() ? set_init_arg() x86_64_start_reservations() x86_64_start_kernel() start_cpu() ... Kernel panic - not syncing: Fatal exception Runtime regions will not be freed and do not need to be reserved, so skip the memmap modification in this case. Signed-off-by: Omar Sandoval Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Dave Young Cc: Linus Torvalds Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()") Link: http://lkml.kernel.org/r/20170412152719.9779-2-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 085656dad4b0aa530ecd8730c00381abbd01e2c6 Author: Peter Zijlstra Date: Tue Apr 11 10:10:28 2017 +0200 perf/x86: Avoid exposing wrong/stale data in intel_pmu_lbr_read_32() commit f2200ac311302fcdca6556fd0c5127eab6c65a3e upstream. When the perf_branch_entry::{in_tx,abort,cycles} fields were added, intel_pmu_lbr_read_32() wasn't updated to initialize them. Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Fixes: 135c5612c460 ("perf/x86/intel: Support Haswell/v4 LBR format") Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 0ea2dcf1f9e691645c22d9103d699e834a7fb8e6 Author: Cameron Gutman Date: Mon Apr 10 20:44:25 2017 -0700 Input: xpad - add support for Razer Wildcat gamepad commit 5376366886251e2f8f248704adb620a4bc4c0937 upstream. Signed-off-by: Cameron Gutman Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 730fecb3401f8a7cc84e8d7b454976efdfdc65c9 Author: Germano Percossi Date: Fri Apr 7 12:29:38 2017 +0100 CIFS: store results of cifs_reopen_file to avoid infinite wait commit 1fa839b4986d648b907d117275869a0e46c324b9 upstream. This fixes Continuous Availability when errors during file reopen are encountered. cifs_user_readv and cifs_user_writev would wait for ever if results of cifs_reopen_file are not stored and for later inspection. In fact, results are checked and, in case of errors, a chain of function calls leading to reads and writes to be scheduled in a separate thread is skipped. These threads will wake up the corresponding waiters once reads and writes are done. However, given the return value is not stored, when rc is checked for errors a previous one (always zero) is inspected instead. This leads to pending reads/writes added to the list, making cifs_user_readv and cifs_user_writev wait for ever. Signed-off-by: Germano Percossi Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3d8d2f2344767cbab597027e2cde21d1a8b32cca Author: Germano Percossi