commit 174651bdf802a2139065e8e31ce950e2f3fc4a94 Author: Greg Kroah-Hartman Date: Sun Dec 1 09:17:47 2019 +0100 Linux 4.19.87 commit 6938a9da7ff8f25fc6a445d4b7510776b00bb386 Author: Ezequiel Garcia Date: Fri Jun 21 18:39:49 2019 -0300 PM / devfreq: Fix kernel oops on governor module load commit 7544fd7f384591038646d3cd9efb311ab4509e24 upstream. A bit unexpectedly (but still documented), request_module may return a positive value, in case of a modprobe error. This is currently causing issues in the devfreq framework. When a request_module exits with a positive value, we currently return that via ERR_PTR. However, because the value is positive, it's not a ERR_VALUE proper, and is therefore treated as a valid struct devfreq_governor pointer, leading to a kernel oops. Fix this by returning -EINVAL if request_module returns a positive value. Fixes: b53b0128052ff ("PM / devfreq: Fix static checker warning in try_then_request_governor") Signed-off-by: Ezequiel Garcia Reviewed-by: Chanwoo Choi Signed-off-by: MyungJoo Ham Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 345712c95eec44bf414782b33e6d5a550fe62b3b Author: Michael Ellerman Date: Wed Nov 13 21:05:44 2019 +1100 KVM: PPC: Book3S HV: Flush link stack on guest exit to host kernel commit af2e8c68b9c5403f77096969c516f742f5bb29e0 upstream. On some systems that are vulnerable to Spectre v2, it is up to software to flush the link stack (return address stack), in order to protect against Spectre-RSB. When exiting from a guest we do some house keeping and then potentially exit to C code which is several stack frames deep in the host kernel. We will then execute a series of returns without preceeding calls, opening up the possiblity that the guest could have poisoned the link stack, and direct speculative execution of the host to a gadget of some sort. To prevent this we add a flush of the link stack on exit from a guest. Signed-off-by: Michael Ellerman [dja: straightforward backport to v4.19] Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit 0a60d4bddc0ba6a7e06d10efa59f7861837860b0 Author: Michael Ellerman Date: Wed Nov 13 21:05:41 2019 +1100 powerpc/book3s64: Fix link stack flush on context switch commit 39e72bf96f5847ba87cc5bd7a3ce0fed813dc9ad upstream. In commit ee13cb249fab ("powerpc/64s: Add support for software count cache flush"), I added support for software to flush the count cache (indirect branch cache) on context switch if firmware told us that was the required mitigation for Spectre v2. As part of that code we also added a software flush of the link stack (return address stack), which protects against Spectre-RSB between user processes. That is all correct for CPUs that activate that mitigation, which is currently Power9 Nimbus DD2.3. What I got wrong is that on older CPUs, where firmware has disabled the count cache, we also need to flush the link stack on context switch. To fix it we create a new feature bit which is not set by firmware, which tells us we need to flush the link stack. We set that when firmware tells us that either of the existing Spectre v2 mitigations are enabled. Then we adjust the patching code so that if we see that feature bit we enable the link stack flush. If we're also told to flush the count cache in software then we fall through and do that also. On the older CPUs we don't need to do do the software count cache flush, firmware has disabled it, so in that case we patch in an early return after the link stack flush. The naming of some of the functions is awkward after this patch, because they're called "count cache" but they also do link stack. But we'll fix that up in a later commit to ease backporting. This is the fix for CVE-2019-18660. Reported-by: Anthony Steinhauser Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 19d98b4d55b044b0d3902d70b3bec0ea9f652cd9 Author: Christopher M. Riedl Date: Thu May 23 21:46:48 2019 -0500 powerpc/64s: support nospectre_v2 cmdline option commit d8f0e0b073e1ec52a05f0c2a56318b47387d2f10 upstream. Add support for disabling the kernel implemented spectre v2 mitigation (count cache flush on context switch) via the nospectre_v2 and mitigations=off cmdline options. Suggested-by: Michael Ellerman Signed-off-by: Christopher M. Riedl Reviewed-by: Andrew Donnellan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190524024647.381-1-cmr@informatik.wtf Signed-off-by: Daniel Axtens Signed-off-by: Greg Kroah-Hartman commit b7e2a040d9fcaddcd665b593f31f0f5df8bbc1f3 Author: Bernd Porr Date: Mon Nov 18 23:07:59 2019 +0000 staging: comedi: usbduxfast: usbduxfast_ai_cmdtest rounding error commit 5618332e5b955b4bff06d0b88146b971c8dd7b32 upstream. The userspace comedilib function 'get_cmd_generic_timed' fills the cmd structure with an informed guess and then calls the function 'usbduxfast_ai_cmdtest' in this driver repeatedly while 'usbduxfast_ai_cmdtest' is modifying the cmd struct until it no longer changes. However, because of rounding errors this never converged because 'steps = (cmd->convert_arg * 30) / 1000' and then back to 'cmd->convert_arg = (steps * 1000) / 30' won't be the same because of rounding errors. 'Steps' should only be converted back to the 'convert_arg' if 'steps' has actually been modified. In addition the case of steps being 0 wasn't checked which is also now done. Signed-off-by: Bernd Porr Cc: # 4.4+ Reviewed-by: Ian Abbott Link: https://lore.kernel.org/r/20191118230759.1727-1-mail@berndporr.me.uk Signed-off-by: Greg Kroah-Hartman commit 4101916e9f08a692000c0052ce2ca86305ff9b55 Author: Aleksander Morgado Date: Wed Nov 13 11:14:05 2019 +0100 USB: serial: option: add support for Foxconn T77W968 LTE modules commit f0797095423e6ea3b4be61134ee353c7f504d440 upstream. These are the Foxconn-branded variants of the Dell DW5821e modules, same USB layout as those. The device exposes AT, NMEA and DIAG ports in both USB configurations. P: Vendor=0489 ProdID=e0b4 Rev=03.18 S: Manufacturer=FII S: Product=T77W968 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option P: Vendor=0489 ProdID=e0b4 Rev=03.18 S: Manufacturer=FII S: Product=T77W968 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Aleksander Morgado [ johan: drop id defines ] Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 62aca6645c084de24c3e594d7ecac0a8cfc08d6e Author: Aleksander Morgado Date: Thu Nov 7 11:55:08 2019 +0100 USB: serial: option: add support for DW5821e with eSIM support commit 957c31ea082e3fe5196f46d5b04018b10de47400 upstream. The device exposes AT, NMEA and DIAG ports in both USB configurations. Exactly same layout as the default DW5821e module, just a different vid/pid. P: Vendor=413c ProdID=81e0 Rev=03.18 S: Manufacturer=Dell Inc. S: Product=DW5821e-eSIM Snapdragon X20 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option P: Vendor=413c ProdID=81e0 Rev=03.18 S: Manufacturer=Dell Inc. S: Product=DW5821e-eSIM Snapdragon X20 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Aleksander Morgado Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3349ed266ae22ea9571343b996ffed7fcf500244 Author: Johan Hovold Date: Thu Nov 7 14:21:19 2019 +0100 USB: serial: mos7840: fix remote wakeup commit 92fe35fb9c70a00d8fbbf5bd6172c921dd9c7815 upstream. The driver was setting the device remote-wakeup feature during probe in violation of the USB specification (which says it should only be set just prior to suspending the device). This could potentially waste power during suspend as well as lead to spurious wakeups. Note that USB core would clear the remote-wakeup feature at first resume. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Cc: stable # 2.6.19 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit abbda35d6a6e9449fcf8c40a8a79cfc208a3a127 Author: Johan Hovold Date: Thu Nov 7 14:21:18 2019 +0100 USB: serial: mos7720: fix remote wakeup commit ea422312a462696093b5db59d294439796cba4ad upstream. The driver was setting the device remote-wakeup feature during probe in violation of the USB specification (which says it should only be set just prior to suspending the device). This could potentially waste power during suspend as well as lead to spurious wakeups. Note that USB core would clear the remote-wakeup feature at first resume. Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver") Cc: stable # 2.6.19 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 84743898d60bd9ac8a3ad0cac53aa01d508175bb Author: Pavel Löbl Date: Fri Nov 1 08:01:50 2019 +0100 USB: serial: mos7840: add USB ID to support Moxa UPort 2210 commit e696d00e65e81d46e911f24b12e441037bf11b38 upstream. Add USB ID for MOXA UPort 2210. This device contains mos7820 but it passes GPIO0 check implemented by driver and it's detected as mos7840. Hence product id check is added to force mos7820 mode. Signed-off-by: Pavel Löbl Cc: stable [ johan: rename id defines and add vendor-id check ] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 356440a79b6b2faf796a65b9915b0882e9f1f73b Author: Oliver Neukum Date: Wed Nov 6 13:49:01 2019 +0100 appledisplay: fix error handling in the scheduled work commit 91feb01596e5efc0cc922cc73f5583114dccf4d2 upstream. The work item can operate on 1. stale memory left over from the last transfer the actual length of the data transfered needs to be checked 2. memory already freed the error handling in appledisplay_probe() needs to cancel the work in that case Reported-and-tested-by: syzbot+495dab1f175edc9c2f13@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191106124902.7765-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 0439d6b901872933da7003413e1bae327c225717 Author: Oliver Neukum Date: Thu Nov 7 15:28:55 2019 +0100 USB: chaoskey: fix error case of a timeout commit 92aa5986f4f7b5a8bf282ca0f50967f4326559f5 upstream. In case of a timeout or if a signal aborts a read communication with the device needs to be ended lest we overwrite an active URB the next time we do IO to the device, as the URB may still be active. Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20191107142856.16774-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit a18675e5d5f7addca7042d77c4763c26c5e8b1e8 Author: Greg Kroah-Hartman Date: Mon Nov 18 10:21:19 2019 +0100 usb-serial: cp201x: support Mark-10 digital force gauge commit 347bc8cb26388791c5881a3775cb14a3f765a674 upstream. Add support for the Mark-10 digital force gauge device to the cp201x driver. Based on a report and a larger patch from Joel Jennings Reported-by: Joel Jennings Cc: stable Acked-by: Johan Hovold Link: https://lore.kernel.org/r/20191118092119.GA153852@kroah.com Signed-off-by: Greg Kroah-Hartman commit 61f6a3fac394fb4f2325196d8fb4cd2b6c8a3ac7 Author: Suwan Kim Date: Mon Nov 11 23:10:35 2019 +0900 usbip: Fix uninitialized symbol 'nents' in stub_recv_cmd_submit() commit 2a9125317b247f2cf35c196f968906dcf062ae2d upstream. Smatch reported that nents is not initialized and used in stub_recv_cmd_submit(). nents is currently initialized by sgl_alloc() and used to allocate multiple URBs when host controller doesn't support scatter-gather DMA. The use of uninitialized nents means that buf_len is zero and use_sg is true. But buffer length should not be zero when an URB uses scatter-gather DMA. To prevent this situation, add the conditional that checks buf_len and use_sg. And move the use of nents right after the sgl_alloc() to avoid the use of uninitialized nents. If the error occurs, it adds SDEV_EVENT_ERROR_MALLOC and stub_priv will be released by stub event handler and connection will be shut down. Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") Reported-by: kbuild test robot Reported-by: Dan Carpenter Signed-off-by: Suwan Kim Acked-by: Shuah Khan Cc: stable Link: https://lore.kernel.org/r/20191111141035.27788-1-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman commit 375b26a8648188957e2f3119c6cf078d3275bd74 Author: Hewenliang Date: Fri Oct 25 00:35:15 2019 -0400 usbip: tools: fix fd leakage in the function of read_attr_usbip_status commit 26a4d4c00f85cb844dd11dd35e848b079c2f5e8f upstream. We should close the fd before the return of read_attr_usbip_status. Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend") Signed-off-by: Hewenliang Cc: stable Link: https://lore.kernel.org/r/20191025043515.20053-1-hewenliang4@huawei.com Signed-off-by: Greg Kroah-Hartman commit e70448b92253c6b20a95b852147a7ff4b97f1c34 Author: Oliver Neukum Date: Tue Nov 12 16:49:39 2019 +0100 USBIP: add config dependency for SGL_ALLOC commit 1ec13abac58b6f24e32f0d3081ef4e7456e62ed8 upstream. USBIP uses lib/scatterlist.h Hence it needs to set CONFIG_SGL_ALLOC Signed-off-by: Oliver Neukum Cc: stable Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20191112154939.21217-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 5d0b56f6725d93e750ec9a5a99222294fc631004 Author: Halil Pasic Date: Thu Nov 14 13:46:46 2019 +0100 virtio_ring: fix return code on DMA mapping fails [ Upstream commit f7728002c1c7bfa787b276a31c3ef458739b8e7c ] Commit 780bc7903a32 ("virtio_ring: Support DMA APIs") makes virtqueue_add() return -EIO when we fail to map our I/O buffers. This is a very realistic scenario for guests with encrypted memory, as swiotlb may run out of space, depending on it's size and the I/O load. The virtio-blk driver interprets -EIO form virtqueue_add() as an IO error, despite the fact that swiotlb full is in absence of bugs a recoverable condition. Let us change the return code to -ENOMEM, and make the block layer recover form these failures when virtio-blk encounters the condition described above. Cc: stable@vger.kernel.org Fixes: 780bc7903a32 ("virtio_ring: Support DMA APIs") Signed-off-by: Halil Pasic Tested-by: Michael Mueller Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 78260a294c04952758f9367f6d92ab129dd8fffb Author: Sean Young Date: Wed Oct 16 14:19:15 2019 -0300 media: imon: invalid dereference in imon_touch_event commit f3f5ba42c58d56d50f539854d8cc188944e96087 upstream. The touch timer is set up in intf1. If the second interface does not exist, the timer and touch input device are not setup and we get the following error, when touch events are reported via intf0. kernel BUG at kernel/time/timer.c:956! invalid opcode: 0000 [#1] SMP KASAN CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc1+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mod_timer kernel/time/timer.c:956 [inline] RIP: 0010:__mod_timer kernel/time/timer.c:949 [inline] RIP: 0010:mod_timer+0x5a2/0xb50 kernel/time/timer.c:1100 Code: 45 10 c7 44 24 14 ff ff ff ff 48 89 44 24 08 48 8d 45 20 48 c7 44 24 18 00 00 00 00 48 89 04 24 e9 5a fc ff ff e8 ae ce 0e 00 <0f> 0b e8 a7 ce 0e 00 4c 89 74 24 20 e9 37 fe ff ff e8 98 ce 0e 00 RSP: 0018:ffff8881db209930 EFLAGS: 00010006 RAX: ffffffff86c2b200 RBX: 00000000ffffa688 RCX: ffffffff83efc583 RDX: 0000000000000100 RSI: ffffffff812f4d82 RDI: ffff8881d2356200 RBP: ffff8881d23561e8 R08: ffffffff86c2b200 R09: ffffed103a46abeb R10: ffffed103a46abea R11: ffff8881d2355f53 R12: dffffc0000000000 R13: 1ffff1103b64132d R14: ffff8881d2355f50 R15: 0000000000000006 FS: 0000000000000000(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f75e2799000 CR3: 00000001d3b07000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: imon_touch_event drivers/media/rc/imon.c:1348 [inline] imon_incoming_packet.isra.0+0x2546/0x2f10 drivers/media/rc/imon.c:1603 usb_rx_callback_intf0+0x151/0x1e0 drivers/media/rc/imon.c:1734 __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1654 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1719 dummy_timer+0x120f/0x2fa2 drivers/usb/gadget/udc/dummy_hcd.c:1965 call_timer_fn+0x179/0x650 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5e3/0x1490 kernel/time/timer.c:1786 __do_softirq+0x221/0x912 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x12f/0x500 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 RIP: 0010:default_idle+0x28/0x2e0 arch/x86/kernel/process.c:581 Code: 90 90 41 56 41 55 65 44 8b 2d 44 3a 8f 7a 41 54 55 53 0f 1f 44 00 00 e8 36 ee d0 fb e9 07 00 00 00 0f 00 2d fa dd 4f 00 fb f4 <65> 44 8b 2d 20 3a 8f 7a 0f 1f 44 00 00 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffffff86c07da8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000007 RBX: ffffffff86c2b200 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffffff86c2ba4c RBP: fffffbfff0d85640 R08: ffffffff86c2b200 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x3b6/0x500 kernel/sched/idle.c:263 cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:355 start_kernel+0x82a/0x864 init/main.c:784 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 Modules linked in: Reported-by: syzbot+f49d12d34f2321cf4df2@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 94a94b605916a3c1f2e54cde475434281d7b7205 Author: Vito Caputo Date: Sun Oct 13 23:08:45 2019 -0300 media: cxusb: detect cxusb_ctrl_msg error in query commit ca8f245f284eeffa56f3b7a5eb6fc503159ee028 upstream. Don't use uninitialized ircode[] in cxusb_rc_query() when cxusb_ctrl_msg() fails to populate its contents. syzbot reported: dvb-usb: bulk message failed: -22 (1/-30591) ===================================================== BUG: KMSAN: uninit-value in ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline] BUG: KMSAN: uninit-value in rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline] BUG: KMSAN: uninit-value in rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816 CPU: 1 PID: 11436 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events dvb_usb_read_remote_control Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 bsearch+0x1dd/0x250 lib/bsearch.c:41 ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline] rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline] rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline] kmsan_internal_chain_origin+0xd2/0x170 mm/kmsan/kmsan.c:314 __msan_chain_origin+0x6b/0xe0 mm/kmsan/kmsan_instr.c:184 rc_g_keycode_from_table drivers/media/rc/rc-main.c:583 [inline] rc_keydown+0x2c4/0x6f0 drivers/media/rc/rc-main.c:816 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Local variable description: ----ircode@cxusb_rc_query Variable was created at: cxusb_rc_query+0x4d/0x360 drivers/media/usb/dvb-usb/cxusb.c:543 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 Signed-off-by: Vito Caputo Reported-by: syzbot Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8b42c263ec1a348bf098e6255407486c1bf17ece Author: Oliver Neukum Date: Tue Jul 30 09:48:27 2019 +0200 media: b2c2-flexcop-usb: add sanity checking commit 1b976fc6d684e3282914cdbe7a8d68fdce19095c upstream. The driver needs an isochronous endpoint to be present. It will oops in its absence. Add checking for it. Reported-by: syzbot+d93dff37e6a89431c158@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 56be9f1b8733395caf570a80aa97d30e1fc61c28 Author: Laurent Pinchart Date: Mon Jul 29 23:14:55 2019 -0300 media: uvcvideo: Fix error path in control parsing failure commit 8c279e9394cade640ed86ec6c6645a0e7df5e0b6 upstream. When parsing the UVC control descriptors fails, the error path tries to cleanup a media device that hasn't been initialised, potentially resulting in a crash. Fix this by initialising the media device before the error handling path can be reached. Fixes: 5a254d751e52 ("[media] uvcvideo: Register a v4l2_device") Reported-by: syzbot+c86454eb3af9e8a4da20@syzkaller.appspotmail.com Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 61e73cf57ed81f63ccce6209f16568578953a3ef Author: Kai Shen Date: Thu Nov 7 05:08:17 2019 +0000 cpufreq: Add NULL checks to show() and store() methods of cpufreq commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream. Add NULL checks to show() and store() in cpufreq.c to avoid attempts to invoke a NULL callback. Though some interfaces of cpufreq are set as read-only, users can still get write permission using chmod which can lead to a kernel crash, as follows: chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq This bug was found in linux 4.19. Signed-off-by: Kai Shen Reported-by: Feilong Lin Reviewed-by: Feilong Lin Acked-by: Viresh Kumar [ rjw: Subject & changelog ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f217cef919dacaab257df22355ae6d275c126f61 Author: Alan Stern Date: Mon Oct 7 12:09:53 2019 -0300 media: usbvision: Fix races among open, close, and disconnect commit 9e08117c9d4efc1e1bc6fce83dab856d9fd284b6 upstream. Visual inspection of the usbvision driver shows that it suffers from three races between its open, close, and disconnect handlers. In particular, the driver is careful to update its usbvision->user and usbvision->remove_pending flags while holding the private mutex, but: usbvision_v4l2_close() and usbvision_radio_close() don't hold the mutex while they check the value of usbvision->remove_pending; usbvision_disconnect() doesn't hold the mutex while checking the value of usbvision->user; and also, usbvision_v4l2_open() and usbvision_radio_open() don't check whether the device has been unplugged before allowing the user to open the device files. Each of these can potentially lead to usbvision_release() being called twice and use-after-free errors. This patch fixes the races by reading the flags while the mutex is still held and checking for pending removes before allowing an open to succeed. Signed-off-by: Alan Stern CC: Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 467052f6ea5a51524992e43f02b543550495c391 Author: Alexander Popov Date: Sun Nov 3 23:17:19 2019 +0100 media: vivid: Fix wrong locking that causes race conditions on streaming stop commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream. There is the same incorrect approach to locking implemented in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and sdr_cap_stop_streaming(). These functions are called during streaming stopping with vivid_dev.mutex locked. And they all do the same mistake while stopping their kthreads, which need to lock this mutex as well. See the example from vivid_stop_generating_vid_cap(): /* shutdown control thread */ vivid_grab_controls(dev, false); mutex_unlock(&dev->mutex); kthread_stop(dev->kthread_vid_cap); dev->kthread_vid_cap = NULL; mutex_lock(&dev->mutex); But when this mutex is unlocked, another vb2_fop_read() can lock it instead of vivid_thread_vid_cap() and manipulate the buffer queue. That causes a use-after-free access later. To fix those issues let's: 1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and sdr_cap_stop_streaming(); 2. use mutex_trylock() with schedule_timeout_uninterruptible() in the loops of the vivid kthread handlers. Signed-off-by: Alexander Popov Acked-by: Linus Torvalds Tested-by: Hans Verkuil Signed-off-by: Hans Verkuil Cc: # for v3.18 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b73b28b1b2cbc345cbe24d98b0997ec599bf4d06 Author: Vandana BN Date: Mon Sep 9 06:43:31 2019 -0300 media: vivid: Set vid_cap_streaming and vid_out_streaming to true commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream. When vbi stream is started, followed by video streaming, the vid_cap_streaming and vid_out_streaming were not being set to true, which would cause the video stream to stop when vbi stream is stopped. This patch allows to set vid_cap_streaming and vid_out_streaming to true. According to Hans Verkuil it appears that these 'if (dev->kthread_vid_cap)' checks are a left-over from the original vivid development and should never have been there. Signed-off-by: Vandana BN Cc: # for v3.18 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit af8071f50f4627fc68ad5f662f200a043dd68472 Author: Oliver Neukum Date: Thu Nov 21 11:37:10 2019 +0100 nfc: port100: handle command failure cleanly commit 5f9f0b11f0816b35867f2cf71e54d95f53f03902 upstream. If starting the transfer of a command suceeds but the transfer for the reply fails, it is not enough to initiate killing the transfer for the command may still be running. You need to wait for the killing to finish before you can reuse URB and buffer. Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3510fb7947d5a7ca662178efe4f8d3712bb85177 Author: Takashi Iwai Date: Fri Nov 22 12:28:40 2019 +0100 ALSA: usb-audio: Fix NULL dereference at parsing BADD commit 9435f2bb66874a0c4dd25e7c978957a7ca2c93b1 upstream. snd_usb_mixer_controls_badd() that parses UAC3 BADD profiles misses a NULL check for the given interfaces. When a malformed USB descriptor is passed, this may lead to an Oops, as spotted by syzkaller. Skip the iteration if the interface doesn't exist for avoiding the crash. Fixes: 17156f23e93c ("ALSA: usb: add UAC3 BADD profiles support") Reported-by: syzbot+a36ab65c6653d7ccdd62@syzkaller.appspotmail.com Suggested-by: Dan Carpenter Cc: Link: https://lore.kernel.org/r/20191122112840.24797-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2819f4030f43057238992a4adcd950d7c95aff65 Author: Yang Tao Date: Wed Nov 6 22:55:35 2019 +0100 futex: Prevent robust futex exit race commit ca16d5bee59807bf04deaab0a8eccecd5061528c upstream. Robust futexes utilize the robust_list mechanism to allow the kernel to release futexes which are held when a task exits. The exit can be voluntary or caused by a signal or fault. This prevents that waiters block forever. The futex operations in user space store a pointer to the futex they are either locking or unlocking in the op_pending member of the per task robust list. After a lock operation has succeeded the futex is queued in the robust list linked list and the op_pending pointer is cleared. After an unlock operation has succeeded the futex is removed from the robust list linked list and the op_pending pointer is cleared. The robust list exit code checks for the pending operation and any futex which is queued in the linked list. It carefully checks whether the futex value is the TID of the exiting task. If so, it sets the OWNER_DIED bit and tries to wake up a potential waiter. This is race free for the lock operation but unlock has two race scenarios where waiters might not be woken up. These issues can be observed with regular robust pthread mutexes. PI aware pthread mutexes are not affected. (1) Unlocking task is killed after unlocking the futex value in user space before being able to wake a waiter. pthread_mutex_unlock() | V atomic_exchange_rel (&mutex->__data.__lock, 0) <------------------------killed lll_futex_wake () | | |(__lock = 0) |(enter kernel) | V do_exit() exit_mm() mm_release() exit_robust_list() handle_futex_death() | |(__lock = 0) |(uval = 0) | V if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr)) return 0; The sanity check which ensures that the user space futex is owned by the exiting task prevents the wakeup of waiters which in consequence block infinitely. (2) Waiting task is killed after a wakeup and before it can acquire the futex in user space. OWNER WAITER futex_wait() pthread_mutex_unlock() | | | |(__lock = 0) | | | V | futex_wake() ------------> wakeup() | |(return to userspace) |(__lock = 0) | V oldval = mutex->__data.__lock <-----------------killed atomic_compare_and_exchange_val_acq (&mutex->__data.__lock, | id | assume_other_futex_waiters, 0) | | | (enter kernel)| | V do_exit() | | V handle_futex_death() | |(__lock = 0) |(uval = 0) | V if ((uval & FUTEX_TID_MASK) != task_pid_vnr(curr)) return 0; The sanity check which ensures that the user space futex is owned by the exiting task prevents the wakeup of waiters, which seems to be correct as the exiting task does not own the futex value, but the consequence is that other waiters wont be woken up and block infinitely. In both scenarios the following conditions are true: - task->robust_list->list_op_pending != NULL - user space futex value == 0 - Regular futex (not PI) If these conditions are met then it is reasonably safe to wake up a potential waiter in order to prevent the above problems. As this might be a false positive it can cause spurious wakeups, but the waiter side has to handle other types of unrelated wakeups, e.g. signals gracefully anyway. So such a spurious wakeup will not affect the correctness of these operations. This workaround must not touch the user space futex value and cannot set the OWNER_DIED bit because the lock value is 0, i.e. uncontended. Setting OWNER_DIED in this case would result in inconsistent state and subsequently in malfunction of the owner died handling in user space. The rest of the user space state is still consistent as no other task can observe the list_op_pending entry in the exiting tasks robust list. The eventually woken up waiter will observe the uncontended lock value and take it over. [ tglx: Massaged changelog and comment. Made the return explicit and not depend on the subsequent check and added constants to hand into handle_futex_death() instead of plain numbers. Fixed a few coding style issues. ] Fixes: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core") Signed-off-by: Yang Tao Signed-off-by: Yi Wang Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1573010582-35297-1-git-send-email-wang.yi59@zte.com.cn Link: https://lkml.kernel.org/r/20191106224555.943191378@linutronix.de Signed-off-by: Greg Kroah-Hartman commit d3f8c58d701caa5fb18fcea8ff93946b747b8d8a Author: Arnd Bergmann Date: Tue Apr 17 16:31:07 2018 +0200 y2038: futex: Move compat implementation into futex.c commit 04e7712f4460585e5eed5b853fd8b82a9943958f upstream. We are going to share the compat_sys_futex() handler between 64-bit architectures and 32-bit architectures that need to deal with both 32-bit and 64-bit time_t, and this is easier if both entry points are in the same file. In fact, most other system call handlers do the same thing these days, so let's follow the trend here and merge all of futex_compat.c into futex.c. In the process, a few minor changes have to be done to make sure everything still makes sense: handle_futex_death() and futex_cmpxchg_enabled() become local symbol, and the compat version of the fetch_robust_entry() function gets renamed to compat_fetch_robust_entry() to avoid a symbol clash. This is intended as a purely cosmetic patch, no behavior should change. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 344966da99c962bea479298e4d3744e0c6a513f1 Author: Navid Emamdoost Date: Mon Sep 23 15:09:58 2019 -0500 nbd: prevent memory leak commit 03bf73c315edca28f47451913177e14cd040a216 upstream. In nbd_add_socket when krealloc succeeds, if nsock's allocation fail the reallocted memory is leak. The correct behaviour should be assigning the reallocted memory to config->socks right after success. Reviewed-by: Josef Bacik Signed-off-by: Navid Emamdoost Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ed7a3dde0aa224051c6455fce3755bf48c062178 Author: Waiman Long Date: Fri Nov 15 11:14:45 2019 -0500 x86/speculation: Fix redundant MDS mitigation message commit cd5a2aa89e847bdda7b62029d94e95488d73f6b2 upstream. Since MDS and TAA mitigations are inter-related for processors that are affected by both vulnerabilities, the followiing confusing messages can be printed in the kernel log: MDS: Vulnerable MDS: Mitigation: Clear CPU buffers To avoid the first incorrect message, defer the printing of MDS mitigation after the TAA mitigation selection has been done. However, that has the side effect of printing TAA mitigation first before MDS mitigation. [ bp: Check box is affected/mitigations are disabled first before printing and massage. ] Suggested-by: Pawan Gupta Signed-off-by: Waiman Long Signed-off-by: Borislav Petkov Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Mark Gross Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: Tony Luck Cc: Tyler Hicks Cc: x86-ml Link: https://lkml.kernel.org/r/20191115161445.30809-3-longman@redhat.com Signed-off-by: Greg Kroah-Hartman commit 0af5ae268e24e265494ea4e91119ddd241744195 Author: Waiman Long Date: Fri Nov 15 11:14:44 2019 -0500 x86/speculation: Fix incorrect MDS/TAA mitigation status commit 64870ed1b12e235cfca3f6c6da75b542c973ff78 upstream. For MDS vulnerable processors with TSX support, enabling either MDS or TAA mitigations will enable the use of VERW to flush internal processor buffers at the right code path. IOW, they are either both mitigated or both not. However, if the command line options are inconsistent, the vulnerabilites sysfs files may not report the mitigation status correctly. For example, with only the "mds=off" option: vulnerabilities/mds:Vulnerable; SMT vulnerable vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable The mds vulnerabilities file has wrong status in this case. Similarly, the taa vulnerability file will be wrong with mds mitigation on, but taa off. Change taa_select_mitigation() to sync up the two mitigation status and have them turned off if both "mds=off" and "tsx_async_abort=off" are present. Update documentation to emphasize the fact that both "mds=off" and "tsx_async_abort=off" have to be specified together for processors that are affected by both TAA and MDS to be effective. [ bp: Massage and add kernel-parameters.txt change too. ] Fixes: 1b42f017415b ("x86/speculation/taa: Add mitigation for TSX Async Abort") Signed-off-by: Waiman Long Signed-off-by: Borislav Petkov Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Kosina Cc: Jonathan Corbet Cc: Josh Poimboeuf Cc: linux-doc@vger.kernel.org Cc: Mark Gross Cc: Cc: Pawan Gupta Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: Tony Luck Cc: Tyler Hicks Cc: x86-ml Link: https://lkml.kernel.org/r/20191115161445.30809-2-longman@redhat.com Signed-off-by: Greg Kroah-Hartman commit ed7312096a1f253dc8cf3cca1c838bbdeefbf067 Author: Alexander Kapshuk Date: Tue Sep 24 07:46:59 2019 +0300 x86/insn: Fix awk regexp warnings commit 700c1018b86d0d4b3f1f2d459708c0cdf42b521d upstream. gawk 5.0.1 generates the following regexp warnings: GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator Ealier versions of gawk are not known to generate these warnings. The gawk manual referenced below does not list characters ':' and '&' as needing escaping, so 'unescape' them. See https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html for more info. Running diff on the output generated by the script before and after applying the patch reported no differences. [ bp: Massage commit message. ] [ Caught the respective tools header discrepancy. ] Reported-by: kbuild test robot Signed-off-by: Alexander Kapshuk Signed-off-by: Borislav Petkov Acked-by: Masami Hiramatsu Cc: "H. Peter Anvin" Cc: "Peter Zijlstra (Intel)" Cc: Arnaldo Carvalho de Melo Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190924044659.3785-1-alexander.kapshuk@gmail.com Signed-off-by: Greg Kroah-Hartman commit 99b933bbc7b05cebf99b032a80efae5ecc41888c Author: Alexey Brodkin Date: Tue Oct 22 17:04:11 2019 +0300 ARC: perf: Accommodate big-endian CPU commit 5effc09c4907901f0e71e68e5f2e14211d9a203f upstream. 8-letter strings representing ARC perf events are stores in two 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc. And the same order of bytes in the word is used regardless CPU endianness. Which means in case of big-endian CPU core we need to swap bytes to get the same order as if it was on little-endian CPU. Otherwise we're seeing the following error message on boot: ------------------------->8---------------------- ARC perf : 8 counters (32 bits), 40 conditions, [overflow IRQ support] sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 sysfs_warn_dup+0x46/0x58 sysfs_add_file_mode_ns+0xb2/0x168 create_files+0x70/0x2a0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0 Failed to register pmu: arc_pct, reason -17 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 __warn+0x9c/0xd4 warn_slowpath_fmt+0x22/0x2c perf_event_sysfs_init+0x70/0xa0 ---[ end trace a75fb9a9837bd1ec ]--- ------------------------->8---------------------- What happens here we're trying to register more than one raw perf event with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters and encoded into two 32-bit words. In this particular case we deal with 2 events: * "IJMP____" which counts all jump & branch instructions * "IJMPC___" which counts only conditional jumps & branches Those strings are split in two 32-bit words this way "IJMP" + "____" & "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core being big-endian then we read "PMJI" + "____" & "PMJI" + "___C". And since we interpret read array of ASCII letters as a null-terminated string on big-endian CPU we end up with 2 events of the same name "PMJI". Signed-off-by: Alexey Brodkin Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman commit e02f1448282b9e83250c25d47fc09e618fdca524 Author: Chester Lin Date: Fri Aug 30 14:30:07 2019 +0100 ARM: 8904/1: skip nomap memblocks while finding the lowmem/highmem boundary commit 1d31999cf04c21709f72ceb17e65b54a401330da upstream. adjust_lowmem_bounds() checks every memblocks in order to find the boundary between lowmem and highmem. However some memblocks could be marked as NOMAP so they are not used by kernel, which should be skipped while calculating the boundary. Signed-off-by: Chester Lin Reviewed-by: Mike Rapoport Signed-off-by: Russell King Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 046f0fcf7397fa0b6c7925d1f4fd3fe69af2278a Author: Gang He Date: Fri Nov 2 15:48:03 2018 -0700 ocfs2: remove ocfs2_is_o2cb_active() commit a634644751c46238df58bbfe992e30c1668388db upstream. Remove ocfs2_is_o2cb_active(). We have similar functions to identify which cluster stack is being used via osb->osb_cluster_stack. Secondly, the current implementation of ocfs2_is_o2cb_active() is not totally safe. Based on the design of stackglue, we need to get ocfs2_stack_lock before using ocfs2_stack related data structures, and that active_stack pointer can be NULL in the case of mount failure. Link: http://lkml.kernel.org/r/1495441079-11708-1-git-send-email-ghe@suse.com Signed-off-by: Gang He Reviewed-by: Joseph Qi Reviewed-by: Eric Ren Acked-by: Changwei Ge Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 36bef080b55f9264d587085d9b00d658d4eafa22 Author: Max Uvarov Date: Tue May 28 13:00:50 2019 +0300 net: phy: dp83867: increase SGMII autoneg timer duration commit 1a97a477e666cbdededab93bd3754e508f0c09d7 upstream. After reset SGMII Autoneg timer is set to 2us (bits 6 and 5 are 01). That is not enough to finalize autonegatiation on some devices. Increase this timer duration to maximum supported 16ms. Signed-off-by: Max Uvarov Cc: Heiner Kallweit Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller [ adapted for kernels without phy_modify_mmd ] Signed-off-by: Adrian Bunk Signed-off-by: Greg Kroah-Hartman commit 87997a7800a1c0d206ff84cbb3b6fd2fc0eb561e Author: Max Uvarov Date: Tue May 28 13:00:49 2019 +0300 net: phy: dp83867: fix speed 10 in sgmii mode commit 333061b924539c0de081339643f45514f5f1c1e6 upstream. For supporting 10Mps speed in SGMII mode DP83867_10M_SGMII_RATE_ADAPT bit of DP83867_10M_SGMII_CFG register has to be cleared by software. That does not affect speeds 100 and 1000 so can be done on init. Signed-off-by: Max Uvarov Cc: Heiner Kallweit Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller [ adapted for kernels without phy_modify_mmd ] Signed-off-by: Adrian Bunk Signed-off-by: Greg Kroah-Hartman commit 5779cbc98369aec83eef8fd2fbe2ff04b27196d1 Author: David Hildenbrand Date: Thu Nov 21 17:53:56 2019 -0800 mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span() commit 7ce700bf11b5e2cb84e4352bbdf2123a7a239c84 upstream. Let's limit shrinking to !ZONE_DEVICE so we can fix the current code. We should never try to touch the memmap of offline sections where we could have uninitialized memmaps and could trigger BUGs when calling page_to_nid() on poisoned pages. There is no reliable way to distinguish an uninitialized memmap from an initialized memmap that belongs to ZONE_DEVICE, as we don't have anything like SECTION_IS_ONLINE we can use similar to pfn_to_online_section() for !ZONE_DEVICE memory. E.g., set_zone_contiguous() similarly relies on pfn_to_online_section() and will therefore never set a ZONE_DEVICE zone consecutive. Stopping to shrink the ZONE_DEVICE therefore results in no observable changes, besides /proc/zoneinfo indicating different boundaries - something we can totally live with. Before commit d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug"), the memmap was initialized with 0 and the node with the right value. So the zone might be wrong but not garbage. After that commit, both the zone and the node will be garbage when touching uninitialized memmaps. Toshiki reported a BUG (race between delayed initialization of ZONE_DEVICE memmaps without holding the memory hotplug lock and concurrent zone shrinking). https://lkml.org/lkml/2019/11/14/1040 "Iteration of create and destroy namespace causes the panic as below: kernel BUG at mm/page_alloc.c:535! CPU: 7 PID: 2766 Comm: ndctl Not tainted 5.4.0-rc4 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:set_pfnblock_flags_mask+0x95/0xf0 Call Trace: memmap_init_zone_device+0x165/0x17c memremap_pages+0x4c1/0x540 devm_memremap_pages+0x1d/0x60 pmem_attach_disk+0x16b/0x600 [nd_pmem] nvdimm_bus_probe+0x69/0x1c0 really_probe+0x1c2/0x3e0 driver_probe_device+0xb4/0x100 device_driver_attach+0x4f/0x60 bind_store+0xc9/0x110 kernfs_fop_write+0x116/0x190 vfs_write+0xa5/0x1a0 ksys_write+0x59/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 While creating a namespace and initializing memmap, if you destroy the namespace and shrink the zone, it will initialize the memmap outside the zone and trigger VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page) in set_pfnblock_flags_mask()." This BUG is also mitigated by this commit, where we for now stop to shrink the ZONE_DEVICE zone until we can do it in a safe and clean way. Link: http://lkml.kernel.org/r/20191006085646.5768-5-david@redhat.com Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319] Signed-off-by: David Hildenbrand Reported-by: Aneesh Kumar K.V Reported-by: Toshiki Fukasawa Cc: Oscar Salvador Cc: David Hildenbrand Cc: Michal Hocko Cc: Pavel Tatashin Cc: Dan Williams Cc: Alexander Duyck Cc: Alexander Potapenko Cc: Andy Lutomirski Cc: Anshuman Khandual Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Damian Tometzki Cc: Dave Hansen Cc: Fenghua Yu Cc: Gerald Schaefer Cc: Greg Kroah-Hartman Cc: Halil Pasic Cc: Heiko Carstens Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jun Yao Cc: Logan Gunthorpe Cc: Mark Rutland Cc: Masahiro Yamada Cc: "Matthew Wilcox (Oracle)" Cc: Mel Gorman Cc: Michael Ellerman Cc: Mike Rapoport Cc: Pankaj Gupta Cc: Paul Mackerras Cc: Pavel Tatashin Cc: Peter Zijlstra Cc: Qian Cai Cc: Rich Felker Cc: Robin Murphy Cc: Steve Capper Cc: Thomas Gleixner Cc: Tom Lendacky Cc: Tony Luck Cc: Vasily Gorbik Cc: Vlastimil Babka Cc: Wei Yang Cc: Wei Yang Cc: Will Deacon Cc: Yoshinori Sato Cc: Yu Zhao Cc: [4.13+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: David Hildenbrand Signed-off-by: Greg Kroah-Hartman commit a268d985f08935f565937cf36f0c1a1e0ca04ad3 Author: John Pittman Date: Mon Nov 11 16:43:20 2019 -0800 md/raid10: prevent access of uninitialized resync_pages offset commit 45422b704db392a6d79d07ee3e3670b11048bd53 upstream. Due to unneeded multiplication in the out_free_pages portion of r10buf_pool_alloc(), when using a 3-copy raid10 layout, it is possible to access a resync_pages offset that has not been initialized. This access translates into a crash of the system within resync_free_pages() while passing a bad pointer to put_page(). Remove the multiplication, preventing access to the uninitialized area. Fixes: f0250618361db ("md: raid10: don't use bio's vec table to manage resync pages") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: John Pittman Suggested-by: David Jeffery Reviewed-by: Laurence Oberman Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit f8dc0350d32bc4c7c3b27698bbde319ca1e632a3 Author: Denis Efremov Date: Fri Sep 27 01:56:04 2019 +0300 ath9k_hw: fix uninitialized variable data commit 80e84f36412e0c5172447b6947068dca0d04ee82 upstream. Currently, data variable in ar9003_hw_thermo_cal_apply() could be uninitialized if ar9300_otp_read_word() will fail to read the value. Initialize data variable with 0 to prevent an undefined behavior. This will be enough to handle error case when ar9300_otp_read_word() fails. Fixes: 80fe43f2bbd5 ("ath9k_hw: Read and configure thermocal for AR9462") Cc: Rajkumar Manoharan Cc: John W. Linville Cc: Kalle Valo Cc: "David S. Miller" Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit f0cfe98332d650f31b462207d63c496b4cedaee2 Author: Hui Peng Date: Sat Oct 19 14:42:23 2019 +0300 ath10k: Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe commit bfd6e6e6c5d2ee43a3d9902b36e01fc7527ebb27 upstream. The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects are initialized to point to the containing `ath10k_usb` object according to endpoint descriptors read from the device side, as shown below in `ath10k_usb_setup_pipe_resources`: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; // get the address from endpoint descriptor pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb, endpoint->bEndpointAddress, &urbcount); ...... // select the pipe object pipe = &ar_usb->pipes[pipe_num]; // initialize the ar_usb field pipe->ar_usb = ar_usb; } The driver assumes that the addresses reported in endpoint descriptors from device side to be complete. If a device is malicious and does not report complete addresses, it may trigger NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and `ath10k_usb_free_urb_to_pipe`. This patch fixes the bug by preventing potential NULL-ptr-deref. Signed-off-by: Hui Peng Reported-by: Hui Peng Reported-by: Mathias Payer Reviewed-by: Greg Kroah-Hartman [groeck: Add driver tag to subject, fix build warning] Signed-off-by: Guenter Roeck Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 4ae7392ab6f457b8d695df271d9344f54a326077 Author: Sean Christopherson Date: Mon Nov 11 14:12:27 2019 -0800 KVM: MMU: Do not treat ZONE_DEVICE pages as being reserved commit a78986aae9b2988f8493f9f65a587ee433e83bc3 upstream. Explicitly exempt ZONE_DEVICE pages from kvm_is_reserved_pfn() and instead manually handle ZONE_DEVICE on a case-by-case basis. For things like page refcounts, KVM needs to treat ZONE_DEVICE pages like normal pages, e.g. put pages grabbed via gup(). But for flows such as setting A/D bits or shifting refcounts for transparent huge pages, KVM needs to to avoid processing ZONE_DEVICE pages as the flows in question lack the underlying machinery for proper handling of ZONE_DEVICE pages. This fixes a hang reported by Adam Borowski[*] in dev_pagemap_cleanup() when running a KVM guest backed with /dev/dax memory, as KVM straight up doesn't put any references to ZONE_DEVICE pages acquired by gup(). Note, Dan Williams proposed an alternative solution of doing put_page() on ZONE_DEVICE pages immediately after gup() in order to simplify the auditing needed to ensure is_zone_device_page() is called if and only if the backing device is pinned (via gup()). But that approach would break kvm_vcpu_{un}map() as KVM requires the page to be pinned from map() 'til unmap() when accessing guest memory, unlike KVM's secondary MMU, which coordinates with mmu_notifier invalidations to avoid creating stale page references, i.e. doesn't rely on pages being pinned. [*] http://lkml.kernel.org/r/20190919115547.GA17963@angband.pl Reported-by: Adam Borowski Analyzed-by: David Hildenbrand Acked-by: Dan Williams Cc: stable@vger.kernel.org Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini [sean: backport to 4.x; resolve conflict in mmu.c] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 03bf4876a5935ab48e4dbf56ebdffd25e44378a5 Author: Tomas Bortoli Date: Fri Nov 1 21:42:44 2019 +0100 Bluetooth: Fix invalid-free in bcsp_close() commit cf94da6f502d8caecabd56b194541c873c8a7a3c upstream. Syzbot reported an invalid-free that I introduced fixing a memleak. bcsp_recv() also frees bcsp->rx_skb but never nullifies its value. Nullify bcsp->rx_skb every time it is freed. Signed-off-by: Tomas Bortoli Reported-by: syzbot+a0d209a4676664613e76@syzkaller.appspotmail.com Signed-off-by: Marcel Holtmann Cc: Alexander Potapenko Signed-off-by: Greg Kroah-Hartman commit 006360ec33d9387610f641c633aef0e523753b8d Author: Vinayak Menon Date: Fri Nov 15 17:35:00 2019 -0800 mm/page_io.c: do not free shared swap slots [ Upstream commit 5df373e95689b9519b8557da7c5bd0db0856d776 ] The following race is observed due to which a processes faulting on a swap entry, finds the page neither in swapcache nor swap. This causes zram to give a zero filled page that gets mapped to the process, resulting in a user space crash later. Consider parent and child processes Pa and Pb sharing the same swap slot with swap_count 2. Swap is on zram with SWP_SYNCHRONOUS_IO set. Virtual address 'VA' of Pa and Pb points to the shared swap entry. Pa Pb fault on VA fault on VA do_swap_page do_swap_page lookup_swap_cache fails lookup_swap_cache fails Pb scheduled out swapin_readahead (deletes zram entry) swap_free (makes swap_count 1) Pb scheduled in swap_readpage (swap_count == 1) Takes SWP_SYNCHRONOUS_IO path zram enrty absent zram gives a zero filled page Fix this by making sure that swap slot is freed only when swap count drops down to one. Link: http://lkml.kernel.org/r/1571743294-14285-1-git-send-email-vinmenon@codeaurora.org Fixes: aa8d22a11da9 ("mm: swap: SWP_SYNCHRONOUS_IO: skip swapcache only if swapped page has no other reference") Signed-off-by: Vinayak Menon Suggested-by: Minchan Kim Acked-by: Minchan Kim Cc: Michal Hocko Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 16a300fb1dbb119023275798bbd749c3a3a54d18 Author: Johannes Berg Date: Fri Feb 1 11:09:54 2019 +0100 cfg80211: call disconnect_wk when AP stops [ Upstream commit e005bd7ddea06784c1eb91ac5bb6b171a94f3b05 ] Since we now prevent regulatory restore during STA disconnect if concurrent AP interfaces are active, we need to reschedule this check when the AP state changes. This fixes never doing a restore when an AP is the last interface to stop. Or to put it another way: we need to re-check after anything we check here changes. Cc: stable@vger.kernel.org Fixes: 113f3aaa81bd ("cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces") Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2b3541ffdd05198b329d21920a0f606009a1058b Author: David Ahern Date: Wed Dec 12 15:27:38 2018 -0800 ipv6: Fix handling of LLA with VRF and sockets bound to VRF [ Upstream commit c2027d1e17582903e368abf5d4838b22a98f2b7b ] A recent commit allows sockets bound to a VRF to receive ipv6 link local packets. However, it only works for UDP and worse TCP connection attempts to the LLA with the only listener bound to the VRF just hang where as before the client gets a reset and connection refused. Fix by adjusting ir_iif for LL addresses and packets received through a device enslaved to a VRF. Fixes: 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF") Reported-by: Donald Sharp Cc: Mike Manning Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 091ed093c9c8a1c4c0243924131c8344383aeec3 Author: zhong jiang Date: Mon Apr 8 12:07:17 2019 +0800 mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock [ Upstream commit d2ab99403ee00d8014e651728a4702ea1ae5e52c ] When adding the memory by probing memory block in sysfs interface, there is an obvious issue that we will unlock the device_hotplug_lock when fails to takes it. That issue was introduced in Commit 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock") We should drop out in time when fails to take the device_hotplug_lock. Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock") Reported-by: Yang yingliang Signed-off-by: zhong jiang Reviewed-by: Oscar Salvador Reviewed-by: David Hildenbrand Acked-by: Michal Hocko Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 896f7398152baf02aec8696cd8141d76946b0eb2 Author: Masahiro Yamada Date: Thu Dec 6 12:55:25 2018 +0900 i2c: uniphier-f: fix timeout error after reading 8 bytes [ Upstream commit c2a653deaa81f5a750c0dfcbaf9f8e5195cbe4a5 ] I was totally screwed up in commit eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared"). Since that commit, if the number of read bytes is multiple of the FIFO size (8, 16, 24... bytes), the STOP condition could be issued twice, depending on the timing. If this happens, the controller will go wrong, resulting in the timeout error. It was more than 3 years ago when I wrote this driver, so my memory about this hardware was vague. Please let me correct the description in the commit log of eaba68785c2d. Clearing the IRQ status on exiting the IRQ handler is absolutely fine. This controller makes a pause while any IRQ status is asserted. If the IRQ status is cleared first, the hardware may start the next transaction before the IRQ handler finishes what it supposed to do. This partially reverts the bad commit with clear comments so that I will never repeat this mistake. I also investigated what is happening at the last moment of the read mode. The UNIPHIER_FI2C_INT_RF interrupt is asserted a bit earlier (by half a period of the clock cycle) than UNIPHIER_FI2C_INT_RB. I consulted a hardware engineer, and I got the following information: UNIPHIER_FI2C_INT_RF asserted at the falling edge of SCL at the 8th bit. UNIPHIER_FI2C_INT_RB asserted at the rising edge of SCL at the 9th (ACK) bit. In order to avoid calling uniphier_fi2c_stop() twice, check the latter interrupt. I also commented this because it is obscure hardware internal. Fixes: eaba68785c2d ("i2c: uniphier-f: fix race condition when IRQ is cleared") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1efa17ab9cb830119b5f456b5f0a37aa3f44adbe Author: Vignesh R Date: Tue Jan 15 12:28:32 2019 +0530 spi: omap2-mcspi: Fix DMA and FIFO event trigger size mismatch [ Upstream commit baf8b9f8d260c55a86405f70a384c29cda888476 ] Commit b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length") broke SPI transfers where bits_per_word != 8. This is because of mimsatch between McSPI FIFO level event trigger size (SPI word length) and DMA request size(word length * maxburst). This leads to data corruption, lockup and errors like: spi1.0: EOW timed out Fix this by setting DMA maxburst size to 1 so that McSPI FIFO level event trigger size matches DMA request size. Fixes: b682cffa3ac6 ("spi: omap2-mcspi: Set FIFO DMA trigger level to word length") Cc: stable@vger.kernel.org Reported-by: David Lechner Tested-by: David Lechner Signed-off-by: Vignesh R Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1b0f1b2dde066c8dd78c9df9e33c82eecf572dcc Author: Igor Konopko Date: Fri Nov 23 16:58:10 2018 +0100 nvme-pci: fix surprise removal [ Upstream commit 751a0cc0cd3a0d51e6aaf6fd3b8bd31f4ecfaf3e ] When a PCIe NVMe device is not present, nvme_dev_remove_admin() calls blk_cleanup_queue() on the admin queue, which frees the hctx for that queue. Moments later, on the same path nvme_kill_queues() calls blk_mq_unquiesce_queue() on admin queue and tries to access hctx of it, which leads to following OOPS: Oops: 0000 [#1] SMP PTI RIP: 0010:sbitmap_any_bit_set+0xb/0x40 Call Trace: blk_mq_run_hw_queue+0xd5/0x150 blk_mq_run_hw_queues+0x3a/0x50 nvme_kill_queues+0x26/0x50 nvme_remove_namespaces+0xb2/0xc0 nvme_remove+0x60/0x140 pci_device_remove+0x3b/0xb0 Fixes: cb4bfda62afa2 ("nvme-pci: fix hot removal during error handling") Signed-off-by: Igor Konopko Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 597a37d01b69671088d70fffffcfd38f10a1cda7 Author: Kishon Vijay Abraham I Date: Wed Oct 17 13:10:54 2018 +0530 PCI: keystone: Use quirk to limit MRRS for K2G [ Upstream commit 148e340c0696369fadbbddc8f4bef801ed247d71 ] PCI controller in K2G also has a limitation that memory read request size (MRRS) must not exceed 256 bytes. Use the quirk to limit MRRS (added for K2HK, K2L and K2E) for K2G as well. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit c0418c4a61aa52bf46c234ccc6a067ae0ddbd3ce Author: Nathan Chancellor Date: Wed Nov 7 01:56:40 2018 -0700 pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD [ Upstream commit cd8a145a066a1a3beb0ae615c7cb2ee4217418d7 ] Clang warns when one enumerated type is implicitly converted to another: drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion from enumeration type 'enum zynq_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18}, ~ ^~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion from enumeration type 'enum zynq_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true), ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from macro 'PCONFDUMP' .param = a, .display = b, .format = c, .has_arg = d \ ^ 2 warnings generated. It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns. Signed-off-by: Nathan Chancellor Acked-by: Michal Simek Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0858006cda38ef89c0263d081077ef7f21b53ca1 Author: Nathan Chancellor Date: Thu Nov 1 08:00:08 2018 -0700 pinctrl: lpc18xx: Use define directive for PIN_CONFIG_GPIO_PIN_INT [ Upstream commit f24bfb39975c241374cadebbd037c17960cf1412 ] Clang warns when one enumerated type is implicitly converted to another: drivers/pinctrl/pinctrl-lpc18xx.c:643:29: warning: implicit conversion from enumeration type 'enum lpc18xx_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] {"nxp,gpio-pin-interrupt", PIN_CONFIG_GPIO_PIN_INT, 0}, ~ ^~~~~~~~~~~~~~~~~~~~~~~ drivers/pinctrl/pinctrl-lpc18xx.c:648:12: warning: implicit conversion from enumeration type 'enum lpc18xx_pin_config_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] PCONFDUMP(PIN_CONFIG_GPIO_PIN_INT, "gpio pin int", NULL, true), ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded from macro 'PCONFDUMP' .param = a, .display = b, .format = c, .has_arg = d \ ^ 2 warnings generated. It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns. Link: https://github.com/ClangBuiltLinux/linux/issues/140 Signed-off-by: Nathan Chancellor Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5efa36e7f04abffe4f6553e6a5b3a6593bec10e7 Author: Nathan Chancellor Date: Wed Oct 31 17:46:54 2018 -0700 pinctrl: bcm2835: Use define directive for BCM2835_PINCONF_PARAM_PULL [ Upstream commit b40ac08ff886302a6aa457fd72e94a969f50e245 ] Clang warns when one enumerated type is implicitly converted to another: drivers/pinctrl/bcm/pinctrl-bcm2835.c:707:40: warning: implicit conversion from enumeration type 'enum bcm2835_pinconf_param' to different enumeration type 'enum pin_config_param' [-Wenum-conversion] configs[0] = pinconf_to_config_packed(BCM2835_PINCONF_PARAM_PULL, pull); ~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. It is expected that pinctrl drivers can extend pin_config_param because of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion isn't an issue. Most drivers that take advantage of this define the PIN_CONFIG variables as constants, rather than enumerated values. Do the same thing here so that Clang no longer warns. Signed-off-by: Nathan Chancellor Acked-by: Stefan Wahren Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bad4da12b7977e562e48ceee914d290e66768396 Author: Brian Masney Date: Wed Oct 31 20:11:47 2018 -0400 pinctrl: qcom: spmi-gpio: fix gpio-hog related boot issues [ Upstream commit 149a96047237574b756d872007c006acd0cc6687 ] When attempting to setup up a gpio hog, device probing would repeatedly fail with -EPROBE_DEFERED errors. It was caused by a circular dependency between the gpio and pinctrl frameworks. If the gpio-ranges property is present in device tree, then the gpio framework will handle the gpio pin registration and eliminate the circular dependency. See Christian Lamparter's commit a86caa9ba5d7 ("pinctrl: msm: fix gpio-hog related boot issues") for a detailed commit message that explains the issue in much more detail. The code comment in this commit came from Christian's commit. Signed-off-by: Brian Masney Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c24fe7807320ca9e881ee30e1a54b71b2c05ee1e Author: Sriram R Date: Fri Oct 19 14:42:59 2018 +0530 cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces [ Upstream commit 113f3aaa81bd56aba02659786ed65cbd9cb9a6fc ] Currently when an AP and STA interfaces are active in the same or different radios, regulatory settings are restored whenever the STA disconnects. This restores all channel information including dfs states in all radios. For example, if an AP interface is active in one radio and STA in another, when radar is detected on the AP interface, the dfs state of the channel will be changed to UNAVAILABLE. But when the STA interface disconnects, this issues a regulatory disconnect hint which restores all regulatory settings in all the radios attached and thereby losing the stored dfs state on the other radio where the channel was marked as unavailable earlier. Hence prevent such regulatory restore whenever another active beaconing interface is present in the same or other radios. Signed-off-by: Sriram R Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ee7d2473812be2fbadc419764eb580478f9f31ff Author: Quentin Monnet Date: Thu Nov 8 11:52:27 2018 +0000 tools: bpftool: pass an argument to silence open_obj_pinned() [ Upstream commit f120919f9905a2cad9dea792a28a11fb623f72c1 ] Function open_obj_pinned() prints error messages when it fails to open a link in the BPF virtual file system. However, in some occasions it is not desirable to print an error, for example when we parse all links under the bpffs root, and the error is due to some paths actually being symbolic links. Example output: # ls -l /sys/fs/bpf/ lrwxrwxrwx 1 root root 0 Oct 18 19:00 ip -> /sys/fs/bpf/tc/ drwx------ 3 root root 0 Oct 18 19:00 tc lrwxrwxrwx 1 root root 0 Oct 18 19:00 xdp -> /sys/fs/bpf/tc/ # bpftool --bpffs prog show Error: bpf obj get (/sys/fs/bpf): Permission denied Error: bpf obj get (/sys/fs/bpf): Permission denied # strace -e bpf bpftool --bpffs prog show bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/ip", bpf_fd=0}, 72) = -1 EACCES (Permission denied) Error: bpf obj get (/sys/fs/bpf): Permission denied bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/xdp", bpf_fd=0}, 72) = -1 EACCES (Permission denied) Error: bpf obj get (/sys/fs/bpf): Permission denied ... To fix it, pass a bool as a second argument to the function, and prevent it from printing an error when the argument is set to true. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 367e64ce11fc59fc51b41a8f0f2ba4b5daa23a17 Author: Frank Rowand Date: Thu Oct 4 20:40:21 2018 -0700 of: unittest: initialize args before calling of_*parse_*() [ Upstream commit eeb07c573ec307c53fe2f6ac6d8d11c261f64006 ] Callers of of_irq_parse_one() blindly use the pointer args.np without checking whether of_irq_parse_one() had an error and thus did not set the value of args.np. Initialize args to zero so that using the format "%pOF" to show the value of args.np will show "(null)" when of_irq_parse_one() has an error. This prevents the dereference of a random value. Make the same fix for callers of of_parse_phandle_with_args() and of_parse_phandle_with_args_map(). Reported-by: Guenter Roeck Tested-by: Alan Tull Signed-off-by: Frank Rowand Signed-off-by: Sasha Levin commit e4547e02854776bd8270a7493a5e9f40e77c7ce4 Author: Frank Rowand Date: Fri Oct 12 19:38:26 2018 -0700 of: unittest: allow base devicetree to have symbol metadata [ Upstream commit 5babefb7f7ab1f23861336d511cc666fa45ede82 ] The overlay metadata nodes in the FDT created from testcases.dts are not handled properly. The __fixups__ and __local_fixups__ node were added to the live devicetree, but should not be. Only the first property in the /__symbols__ node was added to the live devicetree if the live devicetree already contained a /__symbols node. All of the node's properties must be added. Tested-by: Alan Tull Signed-off-by: Frank Rowand Signed-off-by: Sasha Levin commit 1303c938c95377895deafce6067dd433c814f94f Author: YueHaibing Date: Thu Nov 8 02:08:43 2018 +0000 net: bcmgenet: return correct value 'ret' from bcmgenet_power_down [ Upstream commit 0db55093b56618088b9a1d445eb6e43b311bea33 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/broadcom/genet/bcmgenet.c: In function 'bcmgenet_power_down': drivers/net/ethernet/broadcom/genet/bcmgenet.c:1136:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] bcmgenet_power_down should return 'ret' instead of 0. Fixes: ca8cf341903f ("net: bcmgenet: propagate errors from bcmgenet_power_down") Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1d6a0dd6aa535e3c5d9d840e3d0cff55cefabaa8 Author: Colin Ian King Date: Mon Nov 5 09:43:52 2018 -0800 ACPICA: Use %d for signed int print formatting instead of %u [ Upstream commit f8ddf49b420112e28bdd23d7ad52d7991a0ccbe3 ] Fix warnings found using static analysis with cppcheck, use %d printf format specifier for signed ints rather than %u Signed-off-by: Colin Ian King Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d15b8b691725a432130358d198e909ccb48b403b Author: Dmitry Osipenko Date: Sun Oct 21 21:30:50 2018 +0300 clk: tegra20: Turn EMC clock gate into divider [ Upstream commit 514fddba845ed3a1b17e01e99cb3a2a52256a88a ] Kernel should never gate the EMC clock as it causes immediate lockup, so removing clk-gate functionality doesn't affect anything. Turning EMC clk gate into divider allows to implement glitch-less EMC scaling, avoiding reparenting to a backup clock. Signed-off-by: Dmitry Osipenko Acked-by: Peter De Schrijver Acked-by: Stephen Boyd Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 91c5f99d131ed3b231aaef7d4ed6799085b095a3 Author: Mike Manning Date: Wed Nov 7 15:36:07 2018 +0000 vrf: mark skb for multicast or link-local as enslaved to VRF [ Upstream commit 6f12fa775530195a501fb090d092c637f32d0cc5 ] The skb for packets that are multicast or to a link-local address are not marked as being enslaved to a VRF, if they are received on a socket bound to the VRF. This is needed for ND and it is preferable for the kernel not to have to deal with the additional use-cases if ll or mcast packets are handled as enslaved. However, this does not allow service instances listening on unbound and bound to VRF sockets to distinguish the VRF used, if packets are sent as multicast or to a link-local address. The fix is for the VRF driver to also mark these skb as being enslaved to the VRF. Signed-off-by: Mike Manning Reviewed-by: David Ahern Tested-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5c2a3997ae5b7d14431eda830bfd0d4d727a7ec9 Author: Tycho Andersen Date: Fri Nov 2 14:18:22 2018 -0600 dlm: don't leak kernel pointer to userspace [ Upstream commit 9de30f3f7f4d31037cfbb7c787e1089c1944b3a7 ] In copy_result_to_user(), we first create a struct dlm_lock_result, which contains a struct dlm_lksb, the last member of which is a pointer to the lvb. Unfortunately, we copy the entire struct dlm_lksb to the result struct, which is then copied to userspace at the end of the function, leaking the contents of sb_lvbptr, which is a valid kernel pointer in some cases (indeed, later in the same function the data it points to is copied to userspace). It is an error to leak kernel pointers to userspace, as it undermines KASLR protections (see e.g. 65eea8edc31 ("floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl") for another example of this). Signed-off-by: Tycho Andersen Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit afb4717ab81b5aca60cd9836788cb6e2e6a1bcba Author: Tycho Andersen Date: Fri Nov 2 14:18:20 2018 -0600 dlm: fix invalid free [ Upstream commit d968b4e240cfe39d39d80483bac8bca8716fd93c ] dlm_config_nodes() does not allocate nodes on failure, so we should not free() nodes when it fails. Signed-off-by: Tycho Andersen Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 30fc13ae88b2b6a40c130f243284ee030591a658 Author: Badhri Jagan Sridharan Date: Mon Oct 1 12:45:01 2018 -0700 usb: typec: tcpm: charge current handling for sink during hard reset [ Upstream commit 157c0f2f641a9938382b092c64548ebdabfe25e0 ] During the initial connect to a non-pd port, sink would hard reset twice before deeming that the port partner is non-pd. TCPM sets the the charge path to false during the hard reset. This causes unnecessary connects/disconnects of charge path and makes port take longer to charge from the non-pd ports. Avoid this by not setting the charge path to false unless the partner has already identified to be pd capable. When partner is a pd port, set the charge path to false in SNK_HARD_RESET_SINK_OFF. Set the current limits to default value based of CC pull up and resume the charge path when port enters SNK_HARD_RESET_SINK_ON. Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Rob Herring Reviewed-by: Heikki Krogerus -------- Changes in V3: Rebase on top of usb-next Changes in V2: Based on feedback of jackp@codeaurora.org - vsafe_5v_hard_reset flag from tcpc_config is removed - Patch only differentiates between pd port partner and non-pd port partner V1 version of the patch is here: https://lkml.org/lkml/2018/9/14/11 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5e989b6cad68f64512bfab2d04df48a47f5c24d2 Author: James Smart Date: Tue Oct 23 13:41:09 2018 -0700 scsi: lpfc: Correct loss of fc4 type on remote port address change [ Upstream commit d83ca3ea833d7a66d49225e4191c4e37cab8f079 ] An address change for a remote port cause PRLI for the wrong protocol to be sent. The node copy done in the discovery code skipped copying the fc4 protocols supported as well. Fix the copy logic for the address change. Beefed up log messages in this area as well. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a391709b636e9b78cf28494f38e42a30c37294f5 Author: James Smart Date: Tue Oct 23 13:41:08 2018 -0700 scsi: lpfc: Fix odd recovery in duplicate FLOGIs in point-to-point [ Upstream commit d496b9a7246cb9813da1fe49e14edbbbf8e232d5 ] Testing a point-to-point topology and a case of re-FLOGI without intervening link bouncing, showed an odd interaction with firmware and a resulting scenario where the driver no longer probed after accepting the new FLOGI. Work around the firmware issue by issuing a link bounce if a FLOGI is received after the link is already up and FLOGI's accepted. While debugging the issue, realized that some debug traces should be clarified to help in the future. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 05678af01a337a242da9744b15255cd6f08a436c Author: James Smart Date: Tue Oct 23 13:41:06 2018 -0700 scsi: lpfc: fcoe: Fix link down issue after 1000+ link bounces [ Upstream commit 036cad1f1ac9ce03e2db94b8460f98eaf1e1ee4c ] On FCoE adapters, when running link bounce test in a loop, initiator failed to login with switch switch and required driver reload to recover. Switch reached a point where all subsequent FLOGIs would be LS_RJT'd. Further testing showed the condition to be related to not performing FCF discovery between FLOGI's. Fix by monitoring FLOGI failures and once a repeated error is seen repeat FCF discovery. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e6d0262e1628e5d61d936a9e15ec5919a2abacbe Author: Shivasharan S Date: Tue Oct 16 23:37:44 2018 -0700 scsi: megaraid_sas: Fix goto labels in error handling [ Upstream commit 8a25fa17b6ed6e6c8101e9c68a10ae68a9025f2c ] During init, if pci_alloc_irq_vectors() fails, the driver has not yet setup the IRQs. Fix the goto labels and error handling for this case. Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 83e679606e78210a30f5f3906f8b8f64391f062b Author: Shivasharan S Date: Tue Oct 16 23:37:41 2018 -0700 scsi: megaraid_sas: Fix msleep granularity [ Upstream commit 9155cf30a3c4ef97e225d6daddf9bd4b173267e8 ] In megasas_transition_to_ready() driver waits 180seconds for controller to change FW state. Here we are calling msleep(1) in a loop for this. As explained in timers-howto.txt, msleep(1) will actually sleep longer than 1ms. If a faulty controller is connected, we will end up waiting for much more than 180 seconds causing unnecessary delays during load. Change the granularity of msleep() call from 1ms to 1000ms. Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ff997bf13c1e732139ec5b5d1eda998cf3b50320 Author: Suganath Prabu Date: Wed Oct 31 18:53:38 2018 +0530 scsi: mpt3sas: Fix driver modifying persistent data in Manufacturing page11 [ Upstream commit 97f35194093362a63b33caba2485521ddabe2c95 ] Currently driver is modifying both current & NVRAM/persistent data in Manufacturing page11. Driver should change only current copy of Manufacturing page11. It should not modify the persistent data. So removed the section of code where driver is modifying the persistent data of Manufacturing page11. Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 80224e3b08ffe85eb990af78e7e3532d779e7be4 Author: Suganath Prabu Date: Wed Oct 31 18:53:37 2018 +0530 scsi: mpt3sas: Don't modify EEDPTagMode field setting on SAS3.5 HBA devices [ Upstream commit 6cd1bc7b9b5075d395ba0120923903873fc7ea0e ] If EEDPTagMode field in manufacturing page11 is set then unset it. This is needed to fix a hardware bug only in SAS3/SAS2 cards. So, skipping EEDPTagMode changes in Manufacturing page11 for SAS 3.5 controllers. Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5553e2bdcb02bd0d9cb2c4115910fbc46a96b58b Author: Suganath Prabu Date: Wed Oct 31 18:53:36 2018 +0530 scsi: mpt3sas: Fix Sync cache command failure during driver unload [ Upstream commit 9029a72500b95578a35877a43473b82cb0386c53 ] This is to fix SYNC CACHE and START STOP command failures with DID_NO_CONNECT during driver unload. In driver's IO submission patch (i.e. in driver's .queuecommand()) driver won't allow any SCSI commands to the IOC when ioc->remove_host flag is set and hence SYNC CACHE commands which are issued to the target drives (where write cache is enabled) during driver unload time is failed with DID_NO_CONNECT status. Now modified the driver to allow SYNC CACHE and START STOP commands to IOC, even when remove_host flag is set. Signed-off-by: Suganath Prabu Reviewed-by: Bjorn Helgaas Reviewed-by: Andy Shevchenko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5f2dc610eb281af3f9f19e39b5ddb07598f033be Author: Florian Fainelli Date: Tue Nov 6 15:15:16 2018 -0800 net: dsa: bcm_sf2: Turn on PHY to allow successful registration [ Upstream commit c04a17d2a9ccf1eaba1c5a56f83e997540a70556 ] We are binding to the PHY using the SF2 slave MDIO bus that we create, binding involves reading the PHY's MII_PHYSID1/2 which won't be possible if the PHY is turned off. Temporarily turn it on/off for the bus probing to succeeed. This fixes unbind/bind problems where the port connecting to that PHY would be in error since it could not connect to it. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2ac94b9e902fa2abe9de0c9b8262fb9e147f4b3a Author: Shaokun Zhang Date: Mon Nov 5 19:25:30 2018 +0800 rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information [ Upstream commit 7d129adff3afbd3a449bc3593f2064ac546d58d3 ] RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x' prefix, which is somewhat misleading. Fix it to print hexadecimal, as was intended. Cc: Ping-Ke Shih Cc: Kalle Valo Signed-off-by: Shaokun Zhang Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 13d434fed1a2ce7c11b1c3a95a1c20c86b2bf8a7 Author: Dan Carpenter Date: Wed Oct 24 11:33:34 2018 +0300 wireless: airo: potential buffer overflow in sprintf() [ Upstream commit 3d39e1bb1c88f32820c5f9271f2c8c2fb9a52bac ] It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes of the ssid, but we accidentally use "%*s" (width) instead of "%.*s" (precision) so if the ssid doesn't have a NUL terminator this could lead to an overflow. Static analysis. Not tested. Fixes: e174961ca1a0 ("net: convert print_mac to %pM") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit fad934bb2e476d90957af95c8d51ede3bbfca4c9 Author: Ali MJ Al-Nasrawy Date: Tue Oct 23 19:12:35 2018 +0300 brcmsmac: never log "tid x is not agg'able" by default [ Upstream commit 96fca788e5788b7ea3b0050eb35a343637e0a465 ] This message greatly spams the log under heavy Tx of frames with BK access class which is especially true when operating as AP. It is also not informative as the "agg'ablity" of TIDs are set once and never change. Fix this by logging only in debug mode. Signed-off-by: Ali MJ Al-Nasrawy Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit bdb61fa50b708a45f21095f586fdd08921f3cf50 Author: Gustavo A. R. Silva Date: Mon Oct 22 13:51:03 2018 +0200 rtl8xxxu: Fix missing break in switch [ Upstream commit 307b00c5e695857ca92fc6a4b8ab6c48f988a1b1 ] Add missing break statement in order to prevent the code from falling through to the default case. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 06ed77066838a07a0126c4d09fc843d1a692c419 Author: Christophe JAILLET Date: Tue Oct 16 09:39:40 2018 +0200 wlcore: Fix the return value in case of error in 'wlcore_vendor_cmd_smart_config_start()' [ Upstream commit 3419348a97bcc256238101129d69b600ceb5cc70 ] We return 0 unconditionally at the end of 'wlcore_vendor_cmd_smart_config_start()'. However, 'ret' is set to some error codes in several error handling paths and we already return some error codes at the beginning of the function. Return 'ret' instead to propagate the error code. Fixes: 80ff8063e87c ("wlcore: handle smart config vendor commands") Signed-off-by: Christophe JAILLET Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit c68a499448e139192ca0b45dbe05ca47463a376d Author: Brian Norris Date: Mon Nov 5 14:35:22 2018 +0200 ath10k: snoc: fix unbalanced clock error handling [ Upstream commit 82e60d920e8ad70cd9a280ab156566755f1fe4aa ] Similar to regulator error handling, we should only start tearing down the 'i - 1' clock when clock 'i' fails to enable. Otherwise, we might end up with an unbalanced clock, where we never successfully enabled the clock, but we try to disable it anyway. Fixes: a6a793f98786 ("ath10k: vote for hardware resources for WCN3990") Signed-off-by: Brian Norris Reviewed-by: Douglas Anderson Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit c262dc0655dfdd1d61298a132027159d87e80407 Author: Lior David Date: Wed Oct 31 10:52:24 2018 +0200 wil6210: fix locking in wmi_call [ Upstream commit dc57731dbd535880fe6ced31c229262c34df7d64 ] Switch from spin_lock to spin_lock_irqsave, because wmi_ev_lock is used inside interrupt handler. Signed-off-by: Lior David Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ccb2390e89330d3a562c816408d571975dc8ae5e Author: Maya Erez Date: Wed Oct 31 10:52:20 2018 +0200 wil6210: fix RGF_CAF_ICR address for Talyn-MB [ Upstream commit 7c69709f8ed27197b16aa1c3f9b0744402b2fa02 ] RGF_CAF_ICR register location has changed in Talyn-MB. Add RGF_CAF_ICR_TALYN_MB to support the new address. Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 0e1304ae42c2174a5056fec0aa03ffa09776b1f2 Author: Maya Erez Date: Wed Oct 31 10:52:19 2018 +0200 wil6210: fix L2 RX status handling [ Upstream commit 04de15010aa42a92add66b159e3ae44b4287390f ] L2 RX status errors should not be treated as a bitmap and the actual error values should be checked. Print L2 errors as wil_err_ratelimited for easier debugging when such errors occurs. Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit aa2112d571521b68cfdb82d399a517041e9c4b7c Author: Ahmad Masri Date: Wed Oct 31 10:52:18 2018 +0200 wil6210: fix debugfs memory access alignment [ Upstream commit 84ec040d0fb25197584d28a0dedc355503cd19b9 ] All wil6210 device memory access should be 4 bytes aligned. In io blob wil6210 did not force alignment for read function, this caused alignment fault on some platforms. Fixing that by accessing all 4 lower bytes and return to host the requested data. Signed-off-by: Ahmad Masri Signed-off-by: Maya Erez Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit ea136e61e4df85f53c7fce53d2273c579cf6db9f Author: Arnd Bergmann Date: Sat Nov 3 16:39:28 2018 +0100 btrfs: avoid link error with CONFIG_NO_AUTO_INLINE [ Upstream commit 7e17916b35797396f681a3270245fd29c1e4c250 ] Note: this patch fixes a problem in a feature outside of btrfs ("kernel hacking: add a config option to disable compiler auto-inlining") and is applied ahead of time due to cross-subsystem dependencies. On 32-bit ARM with gcc-8, I see a link error with the addition of the CONFIG_NO_AUTO_INLINE option: fs/btrfs/super.o: In function `btrfs_statfs': super.c:(.text+0x67b8): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x67fc): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x6858): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x6920): undefined reference to `__aeabi_uldivmod' super.c:(.text+0x693c): undefined reference to `__aeabi_uldivmod' fs/btrfs/super.o:super.c:(.text+0x6958): more undefined references to `__aeabi_uldivmod' follow So far this is the only file that shows the behavior, so I'd propose to just work around it by marking the functions as 'static inline' that normally get inlined here. The reference to __aeabi_uldivmod comes from a div_u64() which has an optimization for a constant division that uses a straight '/' operator when the result should be known to the compiler. My interpretation is that as we turn off inlining, gcc still expects the result to be constant but fails to use that constant value. Link: https://lkml.kernel.org/r/20181103153941.1881966-1-arnd@arndb.de Reviewed-by: Nikolay Borisov Reviewed-by: Changbin Du Signed-off-by: Arnd Bergmann [ add the note ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4a035f2643c6b05bbd029e1f509f8e3843a93552 Author: Chiranjeevi Rapolu Date: Fri Oct 26 11:34:30 2018 -0400 media: ov13858: Check for possible null pointer [ Upstream commit 35629182eb8f931b0de6ed38c0efac58e922c801 ] Check for possible null pointer to avoid crash. Signed-off-by: Chiranjeevi Rapolu Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3ee72f30c1636c57c9fe0dbd925d25ecb10a9ff8 Author: Nickhu Date: Thu Oct 25 10:24:14 2018 +0800 nds32: Fix bug in bitfield.h [ Upstream commit 9aaafac8cffa1c1edb66e19a63841b7c86be07ca ] There two bitfield bug for perfomance counter in bitfield.h: PFM_CTL_offSEL1 21 --> 16 PFM_CTL_offSEL2 27 --> 22 This commit fix it. Signed-off-by: Nickhu Acked-by: Greentime Hu Signed-off-by: Greentime Hu Signed-off-by: Sasha Levin commit e6c6c0439a936e7fadc6a861cfa53ee61e43dae0 Author: Taehee Yoo Date: Mon Nov 5 22:31:41 2018 +0900 net: bpfilter: fix iptables failure if bpfilter_umh is disabled [ Upstream commit 97adaddaa6db7a8af81b9b11e30cbe3628cd6700 ] When iptables command is executed, ip_{set/get}sockopt() try to upload bpfilter.ko if bpfilter is enabled. if it couldn't find bpfilter.ko, command is failed. bpfilter.ko is generated if CONFIG_BPFILTER_UMH is enabled. ip_{set/get}sockopt() only checks CONFIG_BPFILTER. So that if CONFIG_BPFILTER is enabled and CONFIG_BPFILTER_UMH is disabled, iptables command is always failed. test config: CONFIG_BPFILTER=y # CONFIG_BPFILTER_UMH is not set test command: %iptables -L iptables: No chain/target/match by that name. Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 811c8141d663e399f9413eba23eb046c98b16665 Author: Andrei Vagin Date: Sun Nov 4 22:37:15 2018 -0800 sock_diag: fix autoloading of the raw_diag module [ Upstream commit c34c1287778b080ed692c0a46a8e345206cc29e6 ] IPPROTO_RAW isn't registred as an inet protocol, so inet_protos[protocol] is always NULL for it. Cc: Cyrill Gorcunov Cc: Xin Long Fixes: bf2ae2e4bf93 ("sock_diag: request _diag module only when the family or proto has been registered") Signed-off-by: Andrei Vagin Reviewed-by: Cyrill Gorcunov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3c69a033b416cdebf455787f51750e3ab0c12718 Author: Richard Guy Briggs Date: Wed Oct 10 16:22:57 2018 -0400 audit: print empty EXECVE args [ Upstream commit ea956d8be91edc702a98b7fe1f9463e7ca8c42ab ] Empty executable arguments were being skipped when printing out the list of arguments in an EXECVE record, making it appear they were somehow lost. Include empty arguments as an itemized empty string. Reproducer: autrace /bin/ls "" "/etc" ausearch --start recent -m execve -i | grep EXECVE type=EXECVE msg=audit(10/03/2018 13:04:03.208:1391) : argc=3 a0=/bin/ls a2=/etc With fix: type=EXECVE msg=audit(10/03/2018 21:51:38.290:194) : argc=3 a0=/bin/ls a1= a2=/etc type=EXECVE msg=audit(1538617898.290:194): argc=3 a0="/bin/ls" a1="" a2="/etc" Passes audit-testsuite. GH issue tracker at https://github.com/linux-audit/audit-kernel/issues/99 Signed-off-by: Richard Guy Briggs [PM: cleaned up the commit metadata] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 5dc441fbef91a8d05c0917942692d3c06d255e73 Author: Florian Fainelli Date: Thu Sep 27 12:27:11 2018 -0700 soc: bcm: brcmstb: Fix re-entry point with a THUMB2_KERNEL [ Upstream commit fb14ada11d62fb849fc357a25ef8016ba438ba10 ] When the kernel is built with CONFIG_THUMB2_KERNEL we would set the kernel's resume entry point to be a function that is already built as Thumb-2 code while the boot agent doing the resume is in ARM mode, so this does not work. There is a header label defined: cpu_resume_arm which we can use to do the switching for us. Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states (ARM)") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 9cdfff0a5e61b0eed6f8a81f178939f06dc5b65b Author: Icenowy Zheng Date: Thu Oct 18 15:07:29 2018 +0800 clk: sunxi-ng: enable so-said LDOs for A64 SoC's pll-mipi clock [ Upstream commit 859783d1390035e29ba850963bded2b4ffdf43b5 ] In the user manual of A64 SoC, the bit 22 and 23 of pll-mipi control register is called "LDO{1,2}_EN", and according to the BSP source code from Allwinner , the LDOs are enabled during the clock's enabling process. The clock failed to generate output if the two LDOs are not enabled. Add the two bits to the clock's gate bits, so that the LDOs are enabled when the PLL is enabled. Fixes: c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks") Signed-off-by: Icenowy Zheng Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit a2e6fe1f647f45ec3ad14922f05b34b8c4afd211 Author: Leonard Crestez Date: Mon Oct 8 15:28:01 2018 +0000 ARM: dts: imx6sx-sdb: Fix enet phy regulator [ Upstream commit 1ad9fb750a104f51851c092edd7b3553f0218428 ] Bindings for "fixed-regulator" only explicitly support "gpio" property, not "gpios". Fix by correcting the property name. The enet PHYs on imx6sx-sdb needs to be explicitly reset after a power cycle, this can be handled by the phy-reset-gpios property. Sadly this is not handled on suspend: the fec driver turns phy-supply off but doesn't assert phy-reset-gpios again on resume. Since additional phy-level work is required to support powering off the phy in suspend fix the problem by just marking the regulator as "boot-on" "always-on" so that it's never turned off. This behavior is equivalent to older releases. Keep the phy-reset-gpios property on fec anyway because it is a correct description of board design. This issue was exposed by commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") which causes the "gpios" property to also be parsed. Before that commit the "gpios" property had no effect, PHY reset was only handled in the the bootloader. This fixes linux-next boot failures previously reported here: https://lore.kernel.org/patchwork/patch/982437/#1177900 https://lore.kernel.org/patchwork/patch/994091/#1178304 Signed-off-by: Leonard Crestez Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 465073e44fda4982af05fb2d518ef5ce99b1fbe6 Author: Arnd Bergmann Date: Fri Nov 2 16:36:55 2018 +0100 openvswitch: fix linking without CONFIG_NF_CONNTRACK_LABELS [ Upstream commit a277d516de5f498c91d91189717ef7e01102ad27 ] When CONFIG_CC_OPTIMIZE_FOR_DEBUGGING is enabled, the compiler fails to optimize out a dead code path, which leads to a link failure: net/openvswitch/conntrack.o: In function `ovs_ct_set_labels': conntrack.c:(.text+0x2e60): undefined reference to `nf_connlabels_replace' In this configuration, we can take a shortcut, and completely remove the contrack label code. This may also help the regular optimization. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 31bced01fe77f5164201190bb488f09575000c1d Author: Valentin Schneider Date: Wed Sep 26 16:12:07 2018 +0100 sched/fair: Don't increase sd->balance_interval on newidle balance [ Upstream commit 3f130a37c442d5c4d66531b240ebe9abfef426b5 ] When load_balance() fails to move some load because of task affinity, we end up increasing sd->balance_interval to delay the next periodic balance in the hopes that next time we look, that annoying pinned task(s) will be gone. However, idle_balance() pays no attention to sd->balance_interval, yet it will still lead to an increase in balance_interval in case of pinned tasks. If we're going through several newidle balances (e.g. we have a periodic task), this can lead to a huge increase of the balance_interval in a very small amount of time. To prevent that, don't increase the balance interval when going through a newidle balance. This is a similar approach to what is done in commit 58b26c4c0257 ("sched: Increment cache_nice_tries only on periodic lb"), where we disregard newidle balance and rely on periodic balance for more stable results. Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Cc: Dietmar.Eggemann@arm.com Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: patrick.bellasi@arm.com Cc: vincent.guittot@linaro.org Link: http://lkml.kernel.org/r/1537974727-30788-2-git-send-email-valentin.schneider@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit ed023646c2cf2366d0d31beef688227b0a2bc15f Author: Peter Zijlstra Date: Fri Nov 2 14:22:25 2018 +0100 sched/topology: Fix off by one bug [ Upstream commit 993f0b0510dad98b4e6e39506834dab0d13fd539 ] With the addition of the NUMA identity level, we increased @level by one and will run off the end of the array in the distance sort loop. Fixed: 051f3ca02e46 ("sched/topology: Introduce NUMA identity node sched domain") Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit f9fca78e6cf2a44504dac45761c5195973f49c29 Author: Eric Dumazet Date: Wed Oct 31 08:39:13 2018 -0700 net: do not abort bulk send on BQL status [ Upstream commit fe60faa5063822f2d555f4f326c7dd72a60929bf ] Before calling dev_hard_start_xmit(), upper layers tried to cook optimal skb list based on BQL budget. Problem is that GSO packets can end up comsuming more than the BQL budget. Breaking the loop is not useful, since requeued packets are ahead of any packets still in the qdisc. It is also more expensive, since next TX completion will push these packets later, while skbs are not in cpu caches. It is also a behavior difference with TSO packets, that can break the BQL limit by a large amount. Note that drivers should use __netdev_tx_sent_queue() in order to have optimal xmit_more support, and avoid useless atomic operations as shown in the following patch. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d3b9ac2844fd0fe3eb2b19592aaced0abb0d6bb Author: Larry Chen Date: Fri Nov 2 15:48:27 2018 -0700 ocfs2: fix clusters leak in ocfs2_defrag_extent() [ Upstream commit 6194ae4242dec0c9d604bc05df83aa9260a899e4 ] ocfs2_defrag_extent() might leak allocated clusters. When the file system has insufficient space, the number of claimed clusters might be less than the caller wants. If that happens, the original code might directly commit the transaction without returning clusters. This patch is based on code in ocfs2_add_clusters_in_btree(). [akpm@linux-foundation.org: include localalloc.h, reduce scope of data_ac] Link: http://lkml.kernel.org/r/20180904041621.16874-3-lchen@suse.com Signed-off-by: Larry Chen Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6c150df9c2e80b5cf86f5a0d98beb7390ad63bfc Author: Changwei Ge Date: Fri Nov 2 15:48:19 2018 -0700 ocfs2: don't put and assigning null to bh allocated outside [ Upstream commit cf76c78595ca87548ca5e45c862ac9e0949c4687 ] ocfs2_read_blocks() and ocfs2_read_blocks_sync() are both used to read several blocks from disk. Currently, the input argument *bhs* can be NULL or NOT. It depends on the caller's behavior. If the function fails in reading blocks from disk, the corresponding bh will be assigned to NULL and put. Obviously, above process for non-NULL input bh is not appropriate. Because the caller doesn't even know its bhs are put and re-assigned. If buffer head is managed by caller, ocfs2_read_blocks and ocfs2_read_blocks_sync() should not evaluate it to NULL. It will cause caller accessing illegal memory, thus crash. Link: http://lkml.kernel.org/r/HK2PR06MB045285E0F4FBB561F9F2F9B3D5680@HK2PR06MB0452.apcprd06.prod.outlook.com Signed-off-by: Changwei Ge Reviewed-by: Guozhonghua Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6fd469d06eb840462329b60239b5f235cee9e925 Author: Changwei Ge Date: Fri Nov 2 15:48:11 2018 -0700 ocfs2: don't use iocb when EIOCBQUEUED returns [ Upstream commit 9e985787750db8aae87f02b67e908f28ac4d6b83 ] When -EIOCBQUEUED returns, it means that aio_complete() will be called from dio_complete(), which is an asynchronous progress against write_iter. Generally, IO is a very slow progress than executing instruction, but we still can't take the risk to access a freed iocb. And we do face a BUG crash issue. Using the crash tool, iocb is obviously freed already. crash> struct -x kiocb ffff881a350f5900 struct kiocb { ki_filp = 0xffff881a350f5a80, ki_pos = 0x0, ki_complete = 0x0, private = 0x0, ki_flags = 0x0 } And the backtrace shows: ocfs2_file_write_iter+0xcaa/0xd00 [ocfs2] aio_run_iocb+0x229/0x2f0 do_io_submit+0x291/0x540 SyS_io_submit+0x10/0x20 system_call_fastpath+0x16/0x75 Link: http://lkml.kernel.org/r/1523361653-14439-1-git-send-email-ge.changwei@h3c.com Signed-off-by: Changwei Ge Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit abc7968b86b1d09e1798341760197f6d1e9071f5 Author: Guozhonghua Date: Fri Nov 2 15:48:07 2018 -0700 ocfs2: without quota support, avoid calling quota recovery [ Upstream commit 21158ca85b73ddd0088076a5209cfd040513a8b5 ] During one dead node's recovery by other node, quota recovery work will be queued. We should avoid calling quota when it is not supported, so check the quota flags. Link: http://lkml.kernel.org/r/71604351584F6A4EBAE558C676F37CA401071AC9FB@H3CMLB12-EX.srv.huawei-3com.com Signed-off-by: guozhonghua Reviewed-by: Jan Kara Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 6a2245d828e4627df8927957b30602a04d9c2f07 Author: Roman Gushchin Date: Fri Nov 2 15:47:49 2018 -0700 mm: handle no memcg case in memcg_kmem_charge() properly [ Upstream commit e68599a3c3ad0f3171a7cb4e48aa6f9a69381902 ] Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting") on a system with "cgroup_disable=memory" boot option: the system panics with the following stack trace: BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 0 PID: 1 Comm: systemd Not tainted 4.19.0-preempt+ #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fed4 RIP: 0010:page_counter_try_charge+0x22/0xc0 Code: 41 5d c3 c3 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 0f 84 a7 00 00 00 41 56 48 89 f8 49 89 fe 49 Call Trace: try_charge+0xcb/0x780 memcg_kmem_charge_memcg+0x28/0x80 memcg_kmem_charge+0x8b/0x1d0 copy_process.part.41+0x1ca/0x2070 _do_fork+0xd7/0x3d0 do_syscall_64+0x5a/0x180 entry_SYSCALL_64_after_hwframe+0x49/0xbe The problem occurs because get_mem_cgroup_from_current() returns the NULL pointer if memory controller is disabled. Let's check if this is a case at the beginning of memcg_kmem_charge() and just return 0 if mem_cgroup_disabled() returns true. This is how we handle this case in many other places in the memory controller code. Link: http://lkml.kernel.org/r/20181029215123.17830-1-guro@fb.com Fixes: 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting") Signed-off-by: Roman Gushchin Reported-by: Mike Galbraith Acked-by: Rik van Riel Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Shakeel Butt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 08f07d9f5b17c5d1e0c4bafb75840e4f7ad6b764 Author: Len Brown Date: Tue Aug 7 20:22:28 2018 -0400 tools/power turbosat: fix AMD APIC-id output [ Upstream commit 3404155190ce09a1e5d8407e968fc19aac4493e3 ] turbostat recently gained a feature adding APIC and X2APIC columns. While they are disabled by-default, they are enabled with --debug or when explicitly requested, eg. $ sudo turbostat --quiet --show Package,Node,Core,CPU,APIC,X2APIC date But these columns erroneously showed zeros on AMD hardware. This patch corrects the APIC and X2APIC [sic] columns on AMD. Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit b167fee4e45d51d69c68dcd0a3495e576e7d6190 Author: Victor Kamensky Date: Tue Oct 30 16:37:10 2018 -0700 arm64: makefile fix build of .i file in external module case [ Upstream commit 98356eb0ae499c63e78073ccedd9a5fc5c563288 ] After 'a66649dab350 arm64: fix vdso-offsets.h dependency' if one will try to build .i file in case of external kernel module, build fails complaining that prepare0 target is missing. This issue came up with SystemTap when it tries to build variety of .i files for its own generated kernel modules trying to figure given kernel features/capabilities. The issue is that prepare0 is defined in top level Makefile only if KBUILD_EXTMOD is not defined. .i file rule depends on prepare and in case KBUILD_EXTMOD defined top level Makefile contains empty rule for prepare. But after mentioned commit arch/arm64/Makefile would introduce dependency on prepare0 through its own prepare target. Fix it to put proper ifdef KBUILD_EXTMOD around code introduced by mentioned commit. It matches what top level Makefile does. Acked-by: Kevin Brodsky Signed-off-by: Victor Kamensky Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit fa7f1bce27c064c204d942cc31c31a4c4cef451a Author: Keith Busch Date: Wed Oct 31 13:15:29 2018 -0600 nvme-pci: fix conflicting p2p resource adds [ Upstream commit 9fe5c59ff6a1e5e26a39b75489a1420e7eaaf0b1 ] The nvme pci driver had been adding its CMB resource to the P2P DMA subsystem everytime on on a controller reset. This results in the following warning: ------------[ cut here ]------------ nvme 0000:00:03.0: Conflicting mapping in same section WARNING: CPU: 7 PID: 81 at kernel/memremap.c:155 devm_memremap_pages+0xa6/0x380 ... Call Trace: pci_p2pdma_add_resource+0x153/0x370 nvme_reset_work+0x28c/0x17b1 [nvme] ? add_timer+0x107/0x1e0 ? dequeue_entity+0x81/0x660 ? dequeue_entity+0x3b0/0x660 ? pick_next_task_fair+0xaf/0x610 ? __switch_to+0xbc/0x410 process_one_work+0x1cf/0x350 worker_thread+0x215/0x3d0 ? process_one_work+0x350/0x350 kthread+0x107/0x120 ? kthread_park+0x80/0x80 ret_from_fork+0x1f/0x30 ---[ end trace f7ea76ac6ee72727 ]--- nvme nvme0: failed to register the CMB This patch fixes this by registering the CMB with P2P only once. Signed-off-by: Keith Busch Reviewed-by: Logan Gunthorpe Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0bbb8382db4c8c7d1b0dc894f3364719d91dbf7e Author: Michael Kelley Date: Thu Nov 1 00:35:05 2018 +0000 irq/matrix: Fix memory overallocation [ Upstream commit 57f01796f14fecf00d330fe39c8d2477ced9cd79 ] IRQ_MATRIX_SIZE is the number of longs needed for a bitmap, multiplied by the size of a long, yielding a byte count. But it is used to size an array of longs, which is way more memory than is needed. Change IRQ_MATRIX_SIZE so it is just the number of longs needed and the arrays come out the correct size. Fixes: 2f75d9e1c905 ("genirq: Implement bitmap matrix allocator") Signed-off-by: Michael Kelley Signed-off-by: Thomas Gleixner Cc: KY Srinivasan Link: https://lkml.kernel.org/r/1541032428-10392-1-git-send-email-mikelley@microsoft.com Signed-off-by: Sasha Levin commit ad8298fccd706b6c5fd23c20c77a1d38ecb34609 Author: Dave Jiang Date: Tue Aug 28 17:13:59 2018 -0700 ntb: intel: fix return value for ndev_vec_mask() [ Upstream commit 7756e2b5d68c36e170a111dceea22f7365f83256 ] ndev_vec_mask() should be returning u64 mask value instead of int. Otherwise the mask value returned can be incorrect for larger vectors. Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers") Signed-off-by: Dave Jiang Tested-by: Lucas Van Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 3bd4422af874152e95c743f71b86d57fc0a0d4d8 Author: Jon Mason Date: Mon Jun 11 16:13:12 2018 -0400 ntb_netdev: fix sleep time mismatch [ Upstream commit a861594b1b7ffd630f335b351c4e9f938feadb8e ] The tx_time should be in usecs (according to the comment above the variable), but the setting of the timer during the rearming is done in msecs. Change it to match the expected units. Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Suggested-by: Gerd W. Haeussler Signed-off-by: Jon Mason Acked-by: Dave Jiang Signed-off-by: Sasha Levin commit 8dbecf6c2f1737249701522e93c7952083a12826 Author: Huazhong Tan Date: Tue Oct 30 21:50:49 2018 +0800 net: hns3: bugfix for hclge_mdio_write and hclge_mdio_read [ Upstream commit 1c12493809924deda6c0834cb2f2c5a6dc786390 ] When there is a PHY, the driver needs to complete some operations through MDIO during reset reinitialization, so HCLGE_STATE_CMD_DISABLE is more suitable than HCLGE_STATE_RST_HANDLING to prevent the MDIO operation from being sent during the hardware reset. Fixes: b50ae26c57cb ("net: hns3: never send command queue message to IMP when reset) Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12eeb72afac226d9cb4c5555ebbcfebcc57f76f9 Author: Huazhong Tan Date: Tue Oct 30 21:50:48 2018 +0800 net: hns3: bugfix for is_valid_csq_clean_head() [ Upstream commit 6d71ec6cbf74ac9c2823ef751b1baa5b889bb3ac ] The HEAD pointer of the hardware command queue maybe equal to the command queue's next_to_use in the driver, so that does not belong to the invalid HEAD pointer, since the hardware may not process the command in time, causing the HEAD pointer to be too late to update. The variables' name in this function is unreadable, so give them a more readable one. Fixes: 3ff504908f95 ("net: hns3: fix a dead loop in hclge_cmd_csq_clean") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e3345108409c720bbce563d02443bc85431dab09 Author: Huazhong Tan Date: Tue Oct 30 21:50:45 2018 +0800 net: hns3: bugfix for reporting unknown vector0 interrupt repeatly problem [ Upstream commit 0d4411408a7fb9aad0645f23911d9bfdd2ce3177 ] The current driver supports handling two vector0 interrupts, reset and mailbox. When the hardware reports an interrupt of another type of interrupt source, if the driver does not process the interrupt, but enables the interrupt, the hardware will repeatedly report the unknown interrupt. Therefore, the driver enables the vector0 interrupt after clearing the known type of interrupt source. Other conditions are not enabled. Fixes: cd8c5c269b1d ("net: hns3: Fix for hclge_reset running repeatly problem") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0465d06d4c6bedde945864cc10cdf7a1da1f034 Author: Huazhong Tan Date: Tue Oct 30 21:50:44 2018 +0800 net: hns3: bugfix for buffer not free problem during resetting [ Upstream commit 73b907a083b8a8c1c62cb494bc9fbe6ae086c460 ] When hns3_get_ring_config()/hns3_queue_to_ring()/ hns3_get_vector_ring_chain() failed during resetting, the allocated memory has not been freed before these three functions return. So this patch adds error handler in these functions to fix it. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d9bc014c519fc2fb755bb397a07332010d520ab Author: Jacob Keller Date: Mon Oct 15 12:18:28 2018 -0700 fm10k: ensure completer aborts are marked as non-fatal after a resume [ Upstream commit e330af788998b0de4da4f5bd7ddd087507999800 ] VF drivers can trigger PCIe completer aborts any time they read a queue that they don't own. Even in nominal circumstances, it is not possible to prevent the VF driver from reading queues it doesn't own. VF drivers may attempt to read queues it previously owned, but which it no longer does due to a PF reset. Normally these completer aborts aren't an issue. However, on some platforms these trigger machine check errors. This is true even if we lower their severity from fatal to non-fatal. Indeed, we already have code for lowering the severity. We could attempt to mask these errors conditionally around resets, which is the most common time they would occur. However this would essentially be a race between the PF and VF drivers, and we may still occasionally see machine check exceptions on these strictly configured platforms. Instead, mask the errors entirely any time we resume VFs. By doing so, we prevent the completer aborts from being sent to the parent PCIe device, and thus these strict platforms will not upgrade them into machine check errors. Additionally, we don't lose any information by masking these errors, because we'll still report VFs which attempt to access queues via the FUM_BAD_VF_QACCESS errors. Without this change, on platforms where completer aborts cause machine check exceptions, the VF reading queues it doesn't own could crash the host system. Masking the completer abort prevents this, so we should mask it for good, and not just around a PCIe reset. Otherwise malicious or misconfigured VFs could cause the host system to crash. Because we are masking the error entirely, there is little reason to also keep setting the severity bit, so that code is also removed. Signed-off-by: Jacob Keller Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 2fed73906e97b57804c7e344838e88c1a1cc2b94 Author: Miroslav Lichvar Date: Fri Oct 12 13:13:39 2018 +0200 igb: shorten maximum PHC timecounter update interval [ Upstream commit 094bf4d0e9657f6ea1ee3d7e07ce3970796949ce ] The timecounter needs to be updated at least once per ~550 seconds in order to avoid a 40-bit SYSTIM timestamp to be misinterpreted as an old timestamp. Since commit 500462a9d ("timers: Switch to a non-cascading wheel"), scheduling of delayed work seems to be less accurate and a requested delay of 540 seconds may actually be longer than 550 seconds. Shorten the delay to 480 seconds to be sure the timecounter is updated in time. This fixes an issue with HW timestamps on 82580/I350/I354 being off by ~1100 seconds for few seconds every ~9 minutes. Cc: Jacob Keller Cc: Richard Cochran Cc: Thomas Gleixner Signed-off-by: Miroslav Lichvar Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 3081ae5e378f4ec1860b14457b03fe94e65374e7 Author: David Hildenbrand Date: Tue Oct 30 15:10:33 2018 -0700 powerpc/powernv: hold device_hotplug_lock when calling device_online() [ Upstream commit cec1680591d6d5b10ecc10f370210089416e98af ] device_online() should be called with device_hotplug_lock() held. Link: http://lkml.kernel.org/r/20180925091457.28651-5-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Rashmica Gupta Cc: Balbir Singh Cc: Michael Neuling Cc: Boris Ostrovsky Cc: Dan Williams Cc: Greg Kroah-Hartman Cc: Haiyang Zhang Cc: Heiko Carstens Cc: John Allen Cc: Jonathan Corbet Cc: Joonsoo Kim Cc: Juergen Gross Cc: Kate Stewart Cc: "K. Y. Srinivasan" Cc: Len Brown Cc: Martin Schwidefsky Cc: Mathieu Malaterre Cc: Michal Hocko Cc: Nathan Fontenot Cc: Oscar Salvador Cc: Philippe Ombredanne Cc: Rafael J. Wysocki Cc: "Rafael J. Wysocki" Cc: Stephen Hemminger Cc: Thomas Gleixner Cc: Vlastimil Babka Cc: YASUAKI ISHIMATSU Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 17523d7a1cc8c4dd79b078d8724c2af5ad2f3a4e Author: David Hildenbrand Date: Tue Oct 30 15:10:29 2018 -0700 mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock [ Upstream commit 381eab4a6ee81266f8dddc62e57376c7e584e5b8 ] There seem to be some problems as result of 30467e0b3be ("mm, hotplug: fix concurrent memory hot-add deadlock"), which tried to fix a possible lock inversion reported and discussed in [1] due to the two locks a) device_lock() b) mem_hotplug_lock While add_memory() first takes b), followed by a) during bus_probe_device(), onlining of memory from user space first took a), followed by b), exposing a possible deadlock. In [1], and it was decided to not make use of device_hotplug_lock, but rather to enforce a locking order. The problems I spotted related to this: 1. Memory block device attributes: While .state first calls mem_hotplug_begin() and the calls device_online() - which takes device_lock() - .online does no longer call mem_hotplug_begin(), so effectively calls online_pages() without mem_hotplug_lock. 2. device_online() should be called under device_hotplug_lock, however onlining memory during add_memory() does not take care of that. In addition, I think there is also something wrong about the locking in 3. arch/powerpc/platforms/powernv/memtrace.c calls offline_pages() without locks. This was introduced after 30467e0b3be. And skimming over the code, I assume it could need some more care in regards to locking (e.g. device_online() called without device_hotplug_lock. This will be addressed in the following patches. Now that we hold the device_hotplug_lock when - adding memory (e.g. via add_memory()/add_memory_resource()) - removing memory (e.g. via remove_memory()) - device_online()/device_offline() We can move mem_hotplug_lock usage back into online_pages()/offline_pages(). Why is mem_hotplug_lock still needed? Essentially to make get_online_mems()/put_online_mems() be very fast (relying on device_hotplug_lock would be very slow), and to serialize against addition of memory that does not create memory block devices (hmm). [1] http://driverdev.linuxdriverproject.org/pipermail/ driverdev-devel/ 2015-February/065324.html This patch is partly based on a patch by Vitaly Kuznetsov. Link: http://lkml.kernel.org/r/20180925091457.28651-4-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Pavel Tatashin Reviewed-by: Rashmica Gupta Reviewed-by: Oscar Salvador Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Greg Kroah-Hartman Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Rashmica Gupta Cc: Michael Neuling Cc: Balbir Singh Cc: Kate Stewart Cc: Thomas Gleixner Cc: Philippe Ombredanne Cc: Pavel Tatashin Cc: Vlastimil Babka Cc: Dan Williams Cc: Oscar Salvador Cc: YASUAKI ISHIMATSU Cc: Mathieu Malaterre Cc: John Allen Cc: Jonathan Corbet Cc: Joonsoo Kim Cc: Nathan Fontenot Cc: Rafael J. Wysocki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 02735d5987b949f290ba65d491a714bba38de905 Author: David Hildenbrand Date: Tue Oct 30 15:10:24 2018 -0700 mm/memory_hotplug: make add_memory() take the device_hotplug_lock [ Upstream commit 8df1d0e4a265f25dc1e7e7624ccdbcb4a6630c89 ] add_memory() currently does not take the device_hotplug_lock, however is aleady called under the lock from arch/powerpc/platforms/pseries/hotplug-memory.c drivers/acpi/acpi_memhotplug.c to synchronize against CPU hot-remove and similar. In general, we should hold the device_hotplug_lock when adding memory to synchronize against online/offline request (e.g. from user space) - which already resulted in lock inversions due to device_lock() and mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory hot-add deadlock"). add_memory()/add_memory_resource() will create memory block devices, so this really feels like the right thing to do. Holding the device_hotplug_lock makes sure that a memory block device can really only be accessed (e.g. via .online/.state) from user space, once the memory has been fully added to the system. The lock is not held yet in drivers/xen/balloon.c arch/powerpc/platforms/powernv/memtrace.c drivers/s390/char/sclp_cmd.c drivers/hv/hv_balloon.c So, let's either use the locked variants or take the lock. Don't export add_memory_resource(), as it once was exported to be used by XEN, which is never built as a module. If somebody requires it, we also have to export a locked variant (as device_hotplug_lock is never exported). Link: http://lkml.kernel.org/r/20180925091457.28651-3-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Pavel Tatashin Reviewed-by: Rafael J. Wysocki Reviewed-by: Rashmica Gupta Reviewed-by: Oscar Salvador Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Greg Kroah-Hartman Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Nathan Fontenot Cc: John Allen Cc: Michal Hocko Cc: Dan Williams Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: Mathieu Malaterre Cc: Pavel Tatashin Cc: YASUAKI ISHIMATSU Cc: Balbir Singh Cc: Haiyang Zhang Cc: Heiko Carstens Cc: Jonathan Corbet Cc: Kate Stewart Cc: "K. Y. Srinivasan" Cc: Martin Schwidefsky Cc: Michael Neuling Cc: Philippe Ombredanne Cc: Stephen Hemminger Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 023c071f101c6ab7640c37445f1ea8f8013d3f16 Author: Borislav Petkov Date: Tue Oct 30 15:07:13 2018 -0700 kernel/panic.c: do not append newline to the stack protector panic string [ Upstream commit 95c4fb78fb23081472465ca20d5d31c4b780ed82 ] ... because panic() itself already does this. Otherwise you have line-broken trailer: [ 1.836965] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: pgd_alloc+0x29e/0x2a0 [ 1.836965] ]--- Link: http://lkml.kernel.org/r/20181008202901.7894-1-bp@alien8.de Signed-off-by: Borislav Petkov Acked-by: Kees Cook Cc: Masahiro Yamada Cc: "Steven Rostedt (VMware)" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1914e5edd81131c3b7f6621f4c12832997dd2c93 Author: Colin Ian King Date: Tue Oct 30 15:06:35 2018 -0700 fs/hfs/extent.c: fix array out of bounds read of array extent [ Upstream commit 6c9a3f843a29d6894dfc40df338b91dbd78f0ae3 ] Currently extent and index i are both being incremented causing an array out of bounds read on extent[i]. Fix this by removing the extraneous increment of extent. Ernesto said: : This is only triggered when deleting a file with a resource fork. I : may be wrong because the documentation isn't clear, but I don't think : you can create those under linux. So I guess nobody was testing them. : : > A disk space leak, perhaps? : : That's what it looks like in general. hfs_free_extents() won't do : anything if the block count doesn't add up, and the error will be : ignored. Now, if the block count randomly does add up, we could see : some corruption. Detected by CoverityScan, CID#711541 ("Out of bounds read") Link: http://lkml.kernel.org/r/20180831140538.31566-1-colin.king@canonical.com Signed-off-by: Colin Ian King Reviewed-by: Ernesto A. Fernndez Cc: David Howells Cc: Al Viro Cc: Hin-Tak Leung Cc: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a9f38975eb981ff59ef3e943274a723c837da422 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:31 2018 -0700 hfs: update timestamp on truncate() [ Upstream commit 8cd3cb5061730af085a3f9890a3352f162b4e20c ] The vfs takes care of updating mtime on ftruncate(), but on truncate() it must be done by the module. Link: http://lkml.kernel.org/r/e1611eda2985b672ed2d8677350b4ad8c2d07e8a.1539316825.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0013adceb5211fce175c0bd30b4ebc81c265d97f Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:27 2018 -0700 hfsplus: update timestamps on truncate() [ Upstream commit dc8844aada735890a6de109bef327f5df36a982e ] The vfs takes care of updating ctime and mtime on ftruncate(), but on truncate() it must be done by the module. This patch can be tested with xfstests generic/313. Link: http://lkml.kernel.org/r/9beb0913eea37288599e8e1b7cec8768fb52d1b8.1539316825.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 38e7b916daa2d9c4161a2e46148693b2374c0296 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:24 2018 -0700 hfs: fix return value of hfs_get_block() [ Upstream commit 1267a07be5ebbff2d2739290f3d043ae137c15b4 ] Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfs is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfs_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/4538ab8c35ea37338490525f0f24cbc37227528c.1539195310.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 550da9ee35fd904b3814da10236802a555c13f2c Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:21 2018 -0700 hfsplus: fix return value of hfsplus_get_block() [ Upstream commit 839c3a6a5e1fbc8542d581911b35b2cb5cd29304 ] Direct writes to empty inodes fail with EIO. The generic direct-io code is in part to blame (a patch has been submitted as "direct-io: allow direct writes to empty inodes"), but hfsplus is worse affected than the other filesystems because the fallback to buffered I/O doesn't happen. The problem is the return value of hfsplus_get_block() when called with !create. Change it to be more consistent with the other modules. Link: http://lkml.kernel.org/r/2cd1301404ec7cf1e39c8f11a01a4302f1460ad6.1539195310.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Vyacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8687d57d247a4d7a217fcf324b34c5ded887c21a Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:17 2018 -0700 hfs: prevent btree data loss on ENOSPC [ Upstream commit 54640c7502e5ed41fbf4eedd499e85f9acc9698f ] Inserting a new record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes or extents. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. There is no need to reserve space before deleting a catalog record, as we do for hfsplus. This difference is because hfs index nodes have fixed length keys. Link: http://lkml.kernel.org/r/ab5fc8a7d5ffccfd5f27b1cf2cb4ceb6c110da74.1536269131.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0b54b59d8541ec9ca6160c77633bf8e11edfaaac Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:14 2018 -0700 hfsplus: prevent btree data loss on ENOSPC [ Upstream commit d92915c35bfaf763d78bf1d5ac7f183420e3bd99 ] Inserting or deleting a record in a btree may require splitting several of its nodes. If we hit ENOSPC halfway through, the new nodes will be left orphaned and their records will be lost. This could mean lost inodes, extents or xattrs. Henceforth, check the available disk space before making any changes. This still leaves the potential problem of corruption on ENOMEM. The patch can be tested with xfstests generic/027. Link: http://lkml.kernel.org/r/4596eef22fbda137b4ffa0272d92f0da15364421.1536269129.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7beaf6105e2e14a421a5ccb1d01fb730ea61d8c3 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:11 2018 -0700 hfs: fix BUG on bnode parent update [ Upstream commit ef75bcc5763d130451a99825f247d301088b790b ] hfs_brec_update_parent() may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. It is not possible for this to happen on a valid hfs filesystem because the index nodes have fixed length keys. For reasons I ignore, the hfs module does have support for a number of hfsplus features. A corrupt btree header may report variable length keys and trigger this BUG, so it's better to fix it. Link: http://lkml.kernel.org/r/cf9b02d57f806217a2b1bf5db8c3e39730d8f603.1535682463.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Reviewed-by: Andrew Morton Cc: Christoph Hellwig Cc: Viacheslav Dubeyko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1df96949ebfb210c9cc56c90e4159121d3c470c3 Author: Ernesto A. Fernández Date: Tue Oct 30 15:06:04 2018 -0700 hfsplus: fix BUG on bnode parent update [ Upstream commit 19a9d0f1acf75e8be8cfba19c1a34e941846fa2b ] Creating, renaming or deleting a file may hit BUG_ON() if the first record of both a leaf node and its parent are changed, and if this forces the parent to be split. This bug is triggered by xfstests generic/027, somewhat rarely; here is a more reliable reproducer: truncate -s 50M fs.iso mkfs.hfsplus fs.iso mount fs.iso /mnt i=1000 while [ $i -le 2400 ]; do touch /mnt/$i &>/dev/null ((++i)) done i=2400 while [ $i -ge 1000 ]; do mv /mnt/$i /mnt/$(perl -e "print $i x61") &>/dev/null ((--i)) done The issue is that a newly created bnode is being put twice. Reset new_node to NULL in hfs_brec_update_parent() before reaching goto again. Link: http://lkml.kernel.org/r/5ee1db09b60373a15890f6a7c835d00e76bf601d.1535682461.git.ernesto.mnd.fernandez@gmail.com Signed-off-by: Ernesto A. Fernández Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 08751e477f0eacf90a72df15dbda94f95c794fda Author: Rasmus Villemoes Date: Tue Oct 30 15:05:14 2018 -0700 lib/bitmap.c: fix remaining space computation in bitmap_print_to_pagebuf [ Upstream commit ce1091d471107dbf6f91db66a480a25950c9b9ff ] For various alignments of buf, the current expression computes 4096 ok 4095 ok 8190 8189 ... 4097 i.e., if the caller has already written two bytes into the page buffer, len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next boundary. So if the printed version of the bitmap is huge, scnprintf() ends up writing beyond the page boundary. I don't think any current callers actually write anything before bitmap_print_to_pagebuf, but the API seems to be designed to allow it. [akpm@linux-foundation.org: use offset_in_page(), per Andy] [akpm@linux-foundation.org: include mm.h for offset_in_page()] Link: http://lkml.kernel.org/r/20180818131623.8755-7-linux@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Reviewed-by: Andy Shevchenko Cc: Yury Norov Cc: Rasmus Villemoes Cc: Sudeep Holla Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1d58349459450f04cbd82e5f3bdd8c4e3699433b Author: Rasmus Villemoes Date: Tue Oct 30 15:05:07 2018 -0700 linux/bitmap.h: fix type of nbits in bitmap_shift_right() [ Upstream commit d9873969fa8725dc6a5a21ab788c057fd8719751 ] Most other bitmap API, including the OOL version __bitmap_shift_right, take unsigned nbits. This was accidentally left out from 2fbad29917c98. Link: http://lkml.kernel.org/r/20180818131623.8755-5-linux@rasmusvillemoes.dk Fixes: 2fbad29917c98 ("lib: bitmap: change bitmap_shift_right to take unsigned parameters") Signed-off-by: Rasmus Villemoes Reported-by: Yury Norov Reviewed-by: Andy Shevchenko Cc: Rasmus Villemoes Cc: Sudeep Holla Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8deaaf77ce2efb3f314c97fa2e1f73eb6899d8c3 Author: Rasmus Villemoes Date: Tue Oct 30 15:04:59 2018 -0700 linux/bitmap.h: handle constant zero-size bitmaps correctly [ Upstream commit 7275b097851a5e2e0dd4da039c7e96b59ac5314e ] The static inlines in bitmap.h do not handle a compile-time constant nbits==0 correctly (they dereference the passed src or dst pointers, despite only 0 words being valid to access). I had the 0-day buildbot chew on a patch [1] that would cause build failures for such cases without complaining, suggesting that we don't have any such users currently, at least for the 70 .config/arch combinations that was built. Should any turn up, make sure they use the out-of-line versions, which do handle nbits==0 correctly. This is of course not the most efficient, but it's much less churn than teaching all the static inlines an "if (zero_const_nbits())", and since we don't have any current instances, this doesn't affect existing code at all. [1] lkml.kernel.org/r/20180815085539.27485-1-linux@rasmusvillemoes.dk Link: http://lkml.kernel.org/r/20180818131623.8755-3-linux@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Reviewed-by: Andy Shevchenko Cc: Yury Norov Cc: Rasmus Villemoes Cc: Sudeep Holla Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 30598425aecc7af38f8786db3ab5317e07430db2 Author: Dan Carpenter Date: Tue Oct 30 15:04:32 2018 -0700 mm/gup_benchmark.c: prevent integer overflow in ioctl [ Upstream commit 4b408c74ee5a0b74fc9265c2fe39b0e7dec7c056 ] The concern here is that "gup->size" is a u64 and "nr_pages" is unsigned long. On 32 bit systems we could trick the kernel into allocating fewer pages than expected. Link: http://lkml.kernel.org/r/20181025061546.hnhkv33diogf2uis@kili.mountain Fixes: 64c349f4ae78 ("mm: add infrastructure for get_user_pages_fast() benchmarking") Signed-off-by: Dan Carpenter Acked-by: Kirill A. Shutemov Reviewed-by: Andrew Morton Cc: Stephen Rothwell Cc: Keith Busch Cc: "Michael S. Tsirkin" Cc: Kees Cook Cc: YueHaibing Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9663d294ae28ccd970bd0f1e8abbd8d7eb630943 Author: Ming Lei Date: Wed Oct 24 21:18:09 2018 +0800 block: call rq_qos_exit() after queue is frozen [ Upstream commit c57cdf7a9e51d97a43e29b8f4a04157875104000 ] rq_qos_exit() removes the current q->rq_qos, this action has to be done after queue is frozen, otherwise the IO queue path may never be waken up, then IO hang is caused. So fixes this issue by moving rq_qos_exit() after queue is frozen. Cc: Josef Bacik Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a125df22d134c341a1e7a998958ecaa2969256cd Author: Michael Ellerman Date: Mon Oct 29 22:23:53 2018 +1100 selftests/powerpc/cache_shape: Fix out-of-tree build [ Upstream commit 69f8117f17b332a68cd8f4bf8c2d0d3d5b84efc5 ] Use TEST_GEN_PROGS and don't redefine all, this makes the out-of-tree build work. We need to move the extra dependencies below the include of lib.mk, because it adds the $(OUTPUT) prefix if it's defined. We can also drop the clean rule, lib.mk does it for us. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 024cd793bbe1f3a0417f8b1f7a44fe9efc7a0f02 Author: Michael Ellerman Date: Mon Oct 29 22:23:52 2018 +1100 selftests/powerpc/switch_endian: Fix out-of-tree build [ Upstream commit 266bac361d5677e61a6815bd29abeb3bdced2b07 ] For the out-of-tree build to work we need to tell switch_endian_test to look for check-reversed.S in $(OUTPUT). Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit a4a660f7abd984c733b4a6599ef22031e2398146 Author: Joel Stanley Date: Mon Oct 29 22:23:50 2018 +1100 selftests/powerpc/signal: Fix out-of-tree build [ Upstream commit 27825349d7b238533a47e3d98b8bb0efd886b752 ] We should use TEST_GEN_PROGS, not TEST_PROGS. That tells the selftests makefile (lib.mk) that those tests are generated (built), and so it adds the $(OUTPUT) prefix for us, making the out-of-tree build work correctly. It also means we don't need our own clean rule, lib.mk does it. We also have to update the signal_tm rule to use $(OUTPUT). Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f74f406bbd0b29d58237a5d14d6cff69e00cf511 Author: Joel Stanley Date: Mon Oct 29 22:23:49 2018 +1100 selftests/powerpc/ptrace: Fix out-of-tree build [ Upstream commit c39b79082a38a4f8c801790edecbbb4d62ed2992 ] We should use TEST_GEN_PROGS, not TEST_PROGS. That tells the selftests makefile (lib.mk) that those tests are generated (built), and so it adds the $(OUTPUT) prefix for us, making the out-of-tree build work correctly. It also means we don't need our own clean rule, lib.mk does it. We also have to update the ptrace-pkey and core-pkey rules to use $(OUTPUT). Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 57aab8f0a33d5eab59d2108de0644f209941f39e Author: Joel Stanley Date: Wed Oct 31 11:39:34 2018 +1030 powerpc/xmon: Relax frame size for clang [ Upstream commit 9c87156cce5a63735d1218f0096a65c50a7a32aa ] When building with clang (8 trunk, 7.0 release) the frame size limit is hit: arch/powerpc/xmon/xmon.c:452:12: warning: stack frame size of 2576 bytes in function 'xmon_core' [-Wframe-larger-than=] Some investigation by Naveen indicates this is due to clang saving the addresses to printf format strings on the stack. While this issue is investigated, bump up the frame size limit for xmon when building with clang. Link: https://github.com/ClangBuiltLinux/linux/issues/252 Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 32d7474b7a08f432191c9781a05f6ba3585f0db9 Author: Hangbin Liu Date: Fri Oct 26 11:30:35 2018 +0800 ipv4/igmp: fix v1/v2 switchback timeout based on rfc3376, 8.12 [ Upstream commit 966c37f2d77eb44d47af8e919267b1ba675b2eca ] Similiar with ipv6 mcast commit 89225d1ce6af3 ("net: ipv6: mld: fix v1/v2 switchback timeout to rfc3810, 9.12.") i) RFC3376 8.12. Older Version Querier Present Timeout says: The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval. This value MUST be ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval). Currently we only use a hardcode value IGMP_V1/v2_ROUTER_PRESENT_TIMEOUT. Fix it by adding two new items mr_qi(Query Interval) and mr_qri(Query Response Interval) in struct in_device. Now we can calculate the switchback time via (mr_qrv * mr_qi) + mr_qri. We need update these values when receive IGMPv3 queries. Reported-by: Ying Xu Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 691bd94c15b107de103650d0656822fa9b639fa6 Author: Darrick J. Wong Date: Tue Oct 30 10:40:55 2018 +1100 vfs: avoid problematic remapping requests into partial EOF block [ Upstream commit 07d19dc9fbe9128378b9e226abe886fd8fd473df ] A deduplication data corruption is exposed in XFS and btrfs. It is caused by extending the block match range to include the partial EOF block, but then allowing unknown data beyond EOF to be considered a "match" to data in the destination file because the comparison is only made to the end of the source file. This corrupts the destination file when the source extent is shared with it. The VFS remapping prep functions only support whole block dedupe, but we still need to appear to support whole file dedupe correctly. Hence if the dedupe request includes the last block of the souce file, don't include it in the actual dedupe operation. If the rest of the range dedupes successfully, then reject the entire request. A subsequent patch will enable us to shorten dedupe requests correctly. When reflinking sub-file ranges, a data corruption can occur when the source file range includes a partial EOF block. This shares the unknown data beyond EOF into the second file at a position inside EOF, exposing stale data in the second file. If the reflink request includes the last block of the souce file, only proceed with the reflink operation if it lands at or past the destination file's current EOF. If it lands within the destination file EOF, reject the entire request with -EINVAL and make the caller go the hard way. A subsequent patch will enable us to shorten reflink requests correctly. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit cdc45f2047750b511409c1c7b6b7725d902d79a4 Author: Anton Ivanov Date: Tue Sep 25 08:47:13 2018 +0100 um: Make line/tty semantics use true write IRQ [ Upstream commit 917e2fd2c53eb3c4162f5397555cbd394390d4bc ] This fixes a long standing bug where large amounts of output could freeze the tty (most commonly seen on stdio console). While the bug has always been there it became more pronounced after moving to the new interrupt controller. The line semantics are now changed to have true IRQ write semantics which should further improve the tty/line subsystem stability and performance Signed-off-by: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit a17e3bbfb97c3ff7fa297f5193c1310faf6b749f Author: Masahiro Yamada Date: Tue Oct 16 12:01:49 2018 +0900 i2c: uniphier-f: fix race condition when IRQ is cleared [ Upstream commit eaba68785c2d24ebf1f0d46c24e11b79cc2f94c7 ] The current IRQ handler clears all the IRQ status bits when it bails out. This is dangerous because it might clear away the status bits that have just been set while processing the current handler. If this happens, the IRQ event for the latest transfer is lost forever. The IRQ status bits must be cleared *before* the next transfer is kicked. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a118403a5ecce1ba8da834bf1de501402851bc9b Author: Masahiro Yamada Date: Tue Oct 16 12:01:48 2018 +0900 i2c: uniphier-f: fix occasional timeout error [ Upstream commit 39226aaa85f002d695e3cafade3309e12ffdaecd ] Currently, a timeout error could happen at a repeated START condition. For a (non-repeated) START condition, the controller starts sending data when the UNIPHIER_FI2C_CR_STA bit is set. However, for a repeated START condition, the hardware starts running when the slave address is written to the TX FIFO - the write to the UNIPHIER_FI2C_CR register is actually unneeded. Because the hardware is already running before the IRQ is enabled for a repeated START, the driver may miss the IRQ event. In most cases, this problem does not show up since modern CPUs are much faster than the I2C transfer. However, it is still possible that a context switch happens after the controller starts, but before the IRQ register is set up. To fix this, - Do not write UNIPHIER_FI2C_CR for repeated START conditions. - Enable IRQ *before* writing the slave address to the TX FIFO. - Disable IRQ for the current CPU while queuing up the TX FIFO; If the CPU is interrupted by some task, the interrupt handler might be invoked due to the empty TX FIFO before completing the setup. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1466eae37a9f867674dceba9c7f17d7e8167456d Author: Masahiro Yamada Date: Tue Oct 16 12:01:47 2018 +0900 i2c: uniphier-f: make driver robust against concurrency [ Upstream commit f1fdcbbdf45d9609f3d4063b67e9ea941ba3a58f ] This is unlikely to happen, but it is possible for a CPU to enter the interrupt handler just after wait_for_completion_timeout() has expired. If this happens, the hardware is accessed from multiple contexts concurrently. Disable the IRQ after wait_for_completion_timeout(), and do nothing from the handler when the IRQ is disabled. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 10807b374663291a3571ba3092a1e2d3ffb7b2b9 Author: Jianchao Wang Date: Sat Oct 27 19:52:14 2018 +0800 block: fix the DISCARD request merge [ Upstream commit 69840466086d2248898020a08dda52732686c4e6 ] There are two cases when handle DISCARD merge. If max_discard_segments == 1, the bios/requests need to be contiguous to merge. If max_discard_segments > 1, it takes every bio as a range and different range needn't to be contiguous. But now, attempt_merge screws this up. It always consider contiguity for DISCARD for the case max_discard_segments > 1 and cannot merge contiguous DISCARD for the case max_discard_segments == 1, because rq_attempt_discard_merge always returns false in this case. This patch fixes both of the two cases above. Reviewed-by: Christoph Hellwig Reviewed-by: Ming Lei Signed-off-by: Jianchao Wang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b948d56951be8e8fe169c608cf384f5303ae4d0c Author: Sabrina Dubroca Date: Sun Oct 28 09:33:10 2018 +0100 macsec: let the administrator set UP state even if lowerdev is down [ Upstream commit 07bddef9839378bd6f95b393cf24c420529b4ef1 ] Currently, the kernel doesn't let the administrator set a macsec device up unless its lower device is currently up. This is inconsistent, as a macsec device that is up won't automatically go down when its lower device goes down. Now that linkstate propagation works, there's really no reason for this limitation, so let's remove it. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Reported-by: Radu Rendec Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5bdad7106fc509f27a627a94671ef2dd7136021 Author: Sabrina Dubroca Date: Sun Oct 28 09:33:09 2018 +0100 macsec: update operstate when lower device changes [ Upstream commit e6ac075882b2afcdf2d5ab328ce4ab42a1eb9593 ] Like all other virtual devices (macvlan, vlan), the operstate of a macsec device should match the state of its lower device. This is done by calling netif_stacked_transfer_operstate from its netdevice notifier. We also need to call netif_stacked_transfer_operstate when a new macsec device is created, so that its operstate is set properly. This is only relevant when we try to bring the device up directly when we create it. Radu Rendec proposed a similar patch, inspired from the 802.1q driver, that included changing the administrative state of the macsec device, instead of just the operstate. This version is similar to what the macvlan driver does, and updates only the operstate. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Reported-by: Radu Rendec Reported-by: Patrick Talbert Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4291e97c69f658d3d6ba1720d3c2fc820a1721aa Author: Andrea Arcangeli Date: Fri Oct 26 15:10:36 2018 -0700 mm: thp: fix MADV_DONTNEED vs migrate_misplaced_transhuge_page race condition [ Upstream commit d7c3393413fe7e7dc54498ea200ea94742d61e18 ] Patch series "migrate_misplaced_transhuge_page race conditions". Aaron found a new instance of the THP MADV_DONTNEED race against pmdp_clear_flush* variants, that was apparently left unfixed. While looking into the race found by Aaron, I may have found two more issues in migrate_misplaced_transhuge_page. These race conditions would not cause kernel instability, but they'd corrupt userland data or leave data non zero after MADV_DONTNEED. I did only minor testing, and I don't expect to be able to reproduce this (especially the lack of ->invalidate_range before migrate_page_copy, requires the latest iommu hardware or infiniband to reproduce). The last patch is noop for x86 and it needs further review from maintainers of archs that implement flush_cache_range() (not in CC yet). To avoid confusion, it's not the first patch that introduces the bug fixed in the second patch, even before removing the pmdp_huge_clear_flush_notify, that _notify suffix was called after migrate_page_copy already run. This patch (of 3): This is a corollary of ced108037c2aa ("thp: fix MADV_DONTNEED vs. numa balancing race"), 58ceeb6bec8 ("thp: fix MADV_DONTNEED vs. MADV_FREE race") and 5b7abeae3af8c ("thp: fix MADV_DONTNEED vs clear soft dirty race). When the above three fixes where posted Dave asked https://lkml.kernel.org/r/929b3844-aec2-0111-fef7-8002f9d4e2b9@intel.com but apparently this was missed. The pmdp_clear_flush* in migrate_misplaced_transhuge_page() was introduced in a54a407fbf7 ("mm: Close races between THP migration and PMD numa clearing"). The important part of such commit is only the part where the page lock is not released until the first do_huge_pmd_numa_page() finished disarming the pagenuma/protnone. The addition of pmdp_clear_flush() wasn't beneficial to such commit and there's no commentary about such an addition either. I guess the pmdp_clear_flush() in such commit was added just in case for safety, but it ended up introducing the MADV_DONTNEED race condition found by Aaron. At that point in time nobody thought of such kind of MADV_DONTNEED race conditions yet (they were fixed later) so the code may have looked more robust by adding the pmdp_clear_flush(). This specific race condition won't destabilize the kernel, but it can confuse userland because after MADV_DONTNEED the memory won't be zeroed out. This also optimizes the code and removes a superfluous TLB flush. [akpm@linux-foundation.org: reflow comment to 80 cols, fix grammar and typo (beacuse)] Link: http://lkml.kernel.org/r/20181013002430.698-2-aarcange@redhat.com Signed-off-by: Andrea Arcangeli Reported-by: Aaron Tomlin Acked-by: Mel Gorman Acked-by: Kirill A. Shutemov Cc: Jerome Glisse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ac1cad79bcad463ff2c886abf613dd0bc273ac3f Author: Keith Busch Date: Fri Oct 26 15:09:59 2018 -0700 tools/testing/selftests/vm/gup_benchmark.c: fix 'write' flag usage [ Upstream commit 319e0bec1aecb36c5ac6d23812af487ff2c8f47f ] If the '-w' parameter was provided, the benchmark would exit due to a mssing 'break'. Link: http://lkml.kernel.org/r/20181010195605.10689-3-keith.busch@intel.com Signed-off-by: Keith Busch Acked-by: Kirill A. Shutemov Reviewed-by: Andrew Morton Cc: Dave Hansen Cc: Dan Williams Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2d9d6c099eaf91523c7f73ec84c523afd196b18f Author: Dave Chinner Date: Fri Oct 26 15:09:45 2018 -0700 mm/page-writeback.c: fix range_cyclic writeback vs writepages deadlock [ Upstream commit 64081362e8ff4587b4554087f3cfc73d3e0a4cd7 ] We've recently seen a workload on XFS filesystems with a repeatable deadlock between background writeback and a multi-process application doing concurrent writes and fsyncs to a small range of a file. range_cyclic writeback Process 1 Process 2 xfs_vm_writepages write_cache_pages writeback_index = 2 cycled = 0 .... find page 2 dirty lock Page 2 ->writepage page 2 writeback page 2 clean page 2 added to bio no more pages write() locks page 1 dirties page 1 locks page 2 dirties page 1 fsync() .... xfs_vm_writepages write_cache_pages start index 0 find page 1 towrite lock Page 1 ->writepage page 1 writeback page 1 clean page 1 added to bio find page 2 towrite lock Page 2 page 2 is writeback write() locks page 1 dirties page 1 fsync() .... xfs_vm_writepages write_cache_pages start index 0 !done && !cycled sets index to 0, restarts lookup find page 1 dirty find page 1 towrite lock Page 1 page 1 is writeback lock Page 1 DEADLOCK because: - process 1 needs page 2 writeback to complete to make enough progress to issue IO pending for page 1 - writeback needs page 1 writeback to complete so process 2 can progress and unlock the page it is blocked on, then it can issue the IO pending for page 2 - process 2 can't make progress until process 1 issues IO for page 1 The underlying cause of the problem here is that range_cyclic writeback is processing pages in descending index order as we hold higher index pages in a structure controlled from above write_cache_pages(). The write_cache_pages() caller needs to be able to submit these pages for IO before write_cache_pages restarts writeback at mapping index 0 to avoid wcp inverting the page lock/writeback wait order. generic_writepages() is not susceptible to this bug as it has no private context held across write_cache_pages() - filesystems using this infrastructure always submit pages in ->writepage immediately and so there is no problem with range_cyclic going back to mapping index 0. However: mpage_writepages() has a private bio context, exofs_writepages() has page_collect fuse_writepages() has fuse_fill_wb_data nfs_writepages() has nfs_pageio_descriptor xfs_vm_writepages() has xfs_writepage_ctx All of these ->writepages implementations can hold pages under writeback in their private structures until write_cache_pages() returns, and hence they are all susceptible to this deadlock. Also worth noting is that ext4 has it's own bastardised version of write_cache_pages() and so it /may/ have an equivalent deadlock. I looked at the code long enough to understand that it has a similar retry loop for range_cyclic writeback reaching the end of the file and then promptly ran away before my eyes bled too much. I'll leave it for the ext4 developers to determine if their code is actually has this deadlock and how to fix it if it has. There's a few ways I can see avoid this deadlock. There's probably more, but these are the first I've though of: 1. get rid of range_cyclic altogether 2. range_cyclic always stops at EOF, and we start again from writeback index 0 on the next call into write_cache_pages() 2a. wcp also returns EAGAIN to ->writepages implementations to indicate range cyclic has hit EOF. writepages implementations can then flush the current context and call wpc again to continue. i.e. lift the retry into the ->writepages implementation 3. range_cyclic uses trylock_page() rather than lock_page(), and it skips pages it can't lock without blocking. It will already do this for pages under writeback, so this seems like a no-brainer 3a. all non-WB_SYNC_ALL writeback uses trylock_page() to avoid blocking as per pages under writeback. I don't think #1 is an option - range_cyclic prevents frequently dirtied lower file offset from starving background writeback of rarely touched higher file offsets. #2 is simple, and I don't think it will have any impact on performance as going back to the start of the file implies an immediate seek. We'll have exactly the same number of seeks if we switch writeback to another inode, and then come back to this one later and restart from index 0. #2a is pretty much "status quo without the deadlock". Moving the retry loop up into the wcp caller means we can issue IO on the pending pages before calling wcp again, and so avoid locking or waiting on pages in the wrong order. I'm not convinced we need to do this given that we get the same thing from #2 on the next writeback call from the writeback infrastructure. #3 is really just a band-aid - it doesn't fix the access/wait inversion problem, just prevents it from becoming a deadlock situation. I'd prefer we fix the inversion, not sweep it under the carpet like this. #3a is really an optimisation that just so happens to include the band-aid fix of #3. So it seems that the simplest way to fix this issue is to implement solution #2 Link: http://lkml.kernel.org/r/20181005054526.21507-1-david@fromorbit.com Signed-off-by: Dave Chinner Reviewed-by: Jan Kara Cc: Nicholas Piggin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit bcba80f38a003f0cfcebb8502ab81cb043a68977 Author: Jia-Ju Bai Date: Fri Oct 26 15:02:52 2018 -0700 fs/ocfs2/dlm/dlmdebug.c: fix a sleep-in-atomic-context bug in dlm_print_one_mle() [ Upstream commit 999865764f5f128896402572b439269acb471022 ] The kernel module may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] get_zeroed_page(GFP_NOFS) fs/ocfs2/dlm/dlmdebug.c, 332: get_zeroed_page in dlm_print_one_mle fs/ocfs2/dlm/dlmmaster.c, 240: dlm_print_one_mle in __dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 255: __dlm_put_mle in dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 254: spin_lock in dlm_put_ml [FUNC] get_zeroed_page(GFP_NOFS) fs/ocfs2/dlm/dlmdebug.c, 332: get_zeroed_page in dlm_print_one_mle fs/ocfs2/dlm/dlmmaster.c, 240: dlm_print_one_mle in __dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 222: __dlm_put_mle in dlm_put_mle_inuse fs/ocfs2/dlm/dlmmaster.c, 219: spin_lock in dlm_put_mle_inuse To fix this bug, GFP_NOFS is replaced with GFP_ATOMIC. This bug is found by my static analysis tool DSAC. Link: http://lkml.kernel.org/r/20180901112528.27025-1-baijiaju1990@gmail.com Signed-off-by: Jia-Ju Bai Reviewed-by: Andrew Morton Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 99b3146b799ab983b1b639334dd0a2eba40844ca Author: Andrey Ryabinin Date: Fri Oct 26 15:02:30 2018 -0700 arm64: lib: use C string functions with KASAN enabled [ Upstream commit 19a2ca0fb560fd7be7b5293c6b652c6d6078dcde ] ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(), str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm code, thus it can potentially miss many bugs. Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is enabled, so the generic implementations from lib/string.c will be used. We can't just remove the asm functions because efistub uses them. And we can't have two non-weak functions either, so declare the asm functions as weak. Link: http://lkml.kernel.org/r/20180920135631.23833-2-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Reported-by: Kyeongdon Kim Cc: Alexander Potapenko Cc: Ard Biesheuvel Cc: Dmitry Vyukov Cc: Mark Rutland Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b84e965c7edb55405956dbbec93a0754a97c4526 Author: David S. Miller Date: Fri Oct 26 15:39:49 2018 -0700 sparc64: Rework xchg() definition to avoid warnings. [ Upstream commit 6c2fc9cddc1ffdef8ada1dc8404e5affae849953 ] Such as: fs/ocfs2/file.c: In function ‘ocfs2_file_write_iter’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) and drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_xdp_setup’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e4cad4365e0e2458c0ae48b2a9c8c0f0207f31f Author: Felipe Rechia Date: Wed Oct 24 10:57:22 2018 -0300 powerpc/process: Fix flush_all_to_thread for SPE [ Upstream commit e901378578c62202594cba0f6c076f3df365ec91 ] Fix a bug introduced by the creation of flush_all_to_thread() for processors that have SPE (Signal Processing Engine) and use it to compute floating-point operations. >From userspace perspective, the problem was seen in attempts of computing floating-point operations which should generate exceptions. For example: fork(); float x = 0.0 / 0.0; isnan(x); // forked process returns False (should be True) The operation above also should always cause the SPEFSCR FINV bit to be set. However, the SPE floating-point exceptions were turned off after a fork(). Kernel versions prior to the bug used flush_spe_to_thread(), which first saves SPEFSCR register values in tsk->thread and then calls giveup_spe(tsk). After commit 579e633e764e, the save_all() function was called first to giveup_spe(), and then the SPEFSCR register values were saved in tsk->thread. This would save the SPEFSCR register values after disabling SPE for that thread, causing the bug described above. Fixes 579e633e764e ("powerpc: create flush_all_to_thread()") Signed-off-by: Felipe Rechia Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 54299e1cf3793df8fe266dac00f7083b1378b08f Author: Martin Lau Date: Wed Oct 24 20:42:25 2018 +0000 bpf, btf: fix a missing check bug in btf_parse [ Upstream commit 4a6998aff82a20a1aece86a186d8e5263f8b2315 ] Wenwen Wang reported: In btf_parse(), the header of the user-space btf data 'btf_data' is firstly parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then verified. If no error happens during the verification process, the whole data of 'btf_data', including the header, is then copied to 'data' in btf_parse(). It is obvious that the header is copied twice here. More importantly, no check is enforced after the second copy to make sure the headers obtained in these two copies are same. Given that 'btf_data' resides in the user space, a malicious user can race to modify the header between these two copies. By doing so, the user can inject inconsistent data, which can cause undefined behavior of the kernel and introduce potential security risk. This issue is similar to the one fixed in commit 8af03d1ae2e1 ("bpf: btf: Fix a missing check bug"). To fix it, this patch copies the user 'btf_data' *before* parsing / verifying the BTF header. Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)") Signed-off-by: Martin KaFai Lau Co-developed-by: Wenwen Wang Acked-by: Song Liu Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 8044e741eee42db4a08f1d284144ef2d482996be Author: Taehee Yoo Date: Wed Oct 24 20:15:17 2018 +0900 bpf: devmap: fix wrong interface selection in notifier_call [ Upstream commit f592f804831f1cf9d1f9966f58c80f150e6829b5 ] The dev_map_notification() removes interface in devmap if unregistering interface's ifindex is same. But only checking ifindex is not enough because other netns can have same ifindex. so that wrong interface selection could occurred. Hence netdev pointer comparison code is added. v2: compare netdev pointer instead of using net_eq() (Daniel Borkmann) v1: Initial patch Fixes: 2ddf71e23cc2 ("net: add notifier hooks for devmap bpf map") Signed-off-by: Taehee Yoo Acked-by: Song Liu Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 7b557dbdc51947b92dcfe8f13d6fd59d2353d2d9 Author: Tristram Ha Date: Wed Oct 24 14:51:23 2018 -0700 net: ethernet: cadence: fix socket buffer corruption problem [ Upstream commit 899ecaedd15599c22553d158f53b127cc1632dc2 ] Socket buffer is not re-created when headroom is 2 and tailroom is 1. Signed-off-by: Tristram Ha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3681b901e94a18e9fbe505f4c7f34536c931ce92 Author: Geert Uytterhoeven Date: Fri Oct 12 09:20:15 2018 +0200 thermal: rcar_thermal: Prevent hardware access during system suspend [ Upstream commit 3a31386217628ffe2491695be2db933c25dde785 ] On r8a7791/koelsch, sometimes the following message is printed during system suspend: rcar_thermal e61f0000.thermal: thermal sensor was broken This happens if the workqueue runs while the device is already suspended. Fix this by using the freezable system workqueue instead, cfr. commit 51e20d0e3a60cf46 ("thermal: Prevent polling from happening during system suspend"). Fixes: e0a5172e9eec7f0d ("thermal: rcar: add interrupt support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit 436e610bf195a59a9d5b1c47a75a8ebdd1f250bb Author: Sergei Shtylyov Date: Wed Oct 3 23:47:34 2018 +0300 thermal: rcar_thermal: fix duplicate IRQ request [ Upstream commit df016bbba63743bbef9ff5c6c282561211dd72cc ] The driver on R8A77995 requests the same IRQ twice since platform_get_resource() is always called for the 1st IRQ resource. Fixes: 1969d9dc2079 ("thermal: rcar_thermal: add r8a77995 support") Signed-off-by: Sergei Shtylyov Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Reviewed-by: Daniel Lezcano Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit 51aa1a10fbac2faabcee67b882ca5bf8129cb1bb Author: Peng Hao Date: Fri Oct 12 03:53:50 2018 +0800 selftests: fix warning: "_GNU_SOURCE" redefined [ Upstream commit 0387662d1b6c5ad2950d8e94d5e380af3f15c05c ] Makefile contains -D_GNU_SOURCE. remove define "_GNU_SOURCE" in c files. Signed-off-by: Peng Hao Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit c62be4108883a7aee896e4e1417a1e00cf0bb89a Author: Andrea Parri Date: Tue Oct 16 16:13:46 2018 +0200 selftests: kvm: Fix -Wformat warnings [ Upstream commit fb363e2d20351e1d16629df19e7bce1a31b3227a ] Fixes the following warnings: dirty_log_test.c: In function ‘help’: dirty_log_test.c:216:9: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=] printf(" -i: specify iteration counts (default: %"PRIu64")\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/test_util.h:18:0, from dirty_log_test.c:16: /usr/include/inttypes.h:105:34: note: format string is defined here # define PRIu64 __PRI64_PREFIX "u" dirty_log_test.c:218:9: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=] printf(" -I: specify interval in ms (default: %"PRIu64" ms)\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/test_util.h:18:0, from dirty_log_test.c:16: /usr/include/inttypes.h:105:34: note: format string is defined here # define PRIu64 __PRI64_PREFIX "u" Signed-off-by: Andrea Parri Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit 5802cb25de861943f88e96eb43a9aaf42544fb5b Author: Jerry Hoemann Date: Wed Sep 26 15:23:08 2018 -0600 selftests: watchdog: Fix error message. [ Upstream commit 04d5e4bd37516ad60854eb74592c7dbddd75d277 ] Printf's say errno but print the string version of error. Make consistent. Signed-off-by: Jerry Hoemann Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit 74685702363cc13dac2915bf47b49fa18627c666 Author: Shuah Khan (Samsung OSG) Date: Wed Sep 26 13:07:11 2018 -0600 selftests: watchdog: fix message when /dev/watchdog open fails [ Upstream commit 9a244229a4b850b11952a0df79607c69b18fd8df ] When /dev/watchdog open fails, watchdog exits with "watchdog not enabled" message. This is incorrect when open fails due to insufficient privilege. Fix message to clearly state the reason when open fails with EACCESS when a non-root user runs it. Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit 58ceffabad41aaab4dcf68490b10133344a2377e Author: Masami Hiramatsu Date: Thu Aug 30 23:16:13 2018 +0900 selftests/ftrace: Fix to test kprobe $comm arg only if available [ Upstream commit 2452c96e617a0ff6fb2692e55217a3fa57a7322c ] Test $comm in kprobe-event argument syntax testcase only if it is supported on the kernel because $comm has been introduced 4.8 kernel. So on older stable kernel, it should be skipped. Signed-off-by: Masami Hiramatsu Signed-off-by: Shuah Khan (Samsung OSG) Signed-off-by: Sasha Levin commit adcb6d9ff121bcff8365ab42321d71fbed4725ea Author: Keiji Hayashibara Date: Wed Oct 24 18:34:29 2018 +0900 spi: uniphier: fix incorrect property items [ Upstream commit 3511ba7d4ca6f39e2d060bb94e42a41ad1fee7bf ] This commit fixes incorrect property because it was different from the actual. The parameters of '#address-cells' and '#size-cells' were removed, and 'interrupts', 'pinctrl-names' and 'pinctrl-0' were added. Fixes: 4dcd5c2781f3 ("spi: add DT bindings for UniPhier SPI controller") Signed-off-by: Keiji Hayashibara Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c2075f792c6bf10809577bec6cf8d0d347ba056 Author: Garry McNulty Date: Wed Oct 3 20:51:21 2018 +0100 fs/cifs: fix uninitialised variable warnings [ Upstream commit ef2298a06d012973bbc592b86fe5ff730d4d0c63 ] In some error conditions, resp_buftype can be passed uninitialised to free_rsp_buf(), potentially resulting in a spurious debug message. If resp_buftype randomly had the value 1 (CIFS_SMALL_BUFFER) then this would log a debug message. The rsp pointer is initialised to NULL so there is no other side-effect. Detected by CoverityScan, CID 1438585 ("Uninitialized scalar variable") Detected by CoverityScan, CID 1438667 ("Uninitialized scalar variable") Detected by CoverityScan, CID 1438764 ("Uninitialized scalar variable") Signed-off-by: Garry McNulty Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Signed-off-by: Sasha Levin commit c5621fbd656077c2d888d341059ce5a180c906bd Author: Masahisa Kojima Date: Tue Oct 23 20:24:26 2018 +0900 net: socionext: Stop PHY before resetting netsec [ Upstream commit 8e850f25b5812aefedec6732732eb10e7b47cb5c ] In ndo_stop, driver resets the netsec ethernet controller IP. When the netsec IP is reset, HW running mode turns to NRM mode and driver has to wait until this mode transition completes. But mode transition to NRM will not complete if the PHY is in normal operation state. Netsec IP requires PHY is in power down state when it is reset. This modification stops the PHY before resetting netsec. Together with this modification, phy_addr is stored in netsec_priv structure because ndev->phydev is not yet ready in ndo_init. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Masahisa Kojima Signed-off-by: Yoshitoyo Osaki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0a6fa6119ab178a50dfb8c82921bac54b2982d56 Author: Marek Szyprowski Date: Wed Sep 5 13:54:07 2018 +0200 mfd: max8997: Enale irq-wakeup unconditionally [ Upstream commit efddff27c886e729a7f84a7205bd84d7d4af7336 ] IRQ wake up support for MAX8997 driver was initially configured by respective property in pdata. However, after the driver conversion to device-tree, setting it was left as 'todo'. Nowadays most of other PMIC MFD drivers initialized from device-tree assume that they can be an irq wakeup source, so enable it also for MAX8997. This fixes support for wakeup from MAX8997 RTC alarm. Signed-off-by: Marek Szyprowski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 5a04242e8c2357dfb3dd0af4dbca24c5e0aa774a Author: Andy Shevchenko Date: Thu Aug 30 19:52:52 2018 +0300 mfd: intel_soc_pmic_bxtwc: Chain power button IRQs as well [ Upstream commit 9f8ddee1dab836ca758ca8fc555ab5a3aaa5d3fd ] Power button IRQ actually has a second level of interrupts to distinguish between UI and POWER buttons. Moreover, current implementation looks awkward in approach to handle second level IRQs by first level related IRQ chip. To address above issues, split power button IRQ to be chained as well. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit dd72391c9a5380a96351e9dba7a0a7cf7fd23a39 Author: Fabio Estevam Date: Tue Aug 28 17:02:40 2018 -0300 mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC values [ Upstream commit 55143439b7b501882bea9d95a54adfe00ffc79a3 ] When trying to read any MC13892 ADC channel on a imx51-babbage board: The MC13892 PMIC shutdowns completely. After debugging this issue and comparing the MC13892 and MC13783 initializations done in the vendor kernel, it was noticed that the CHRGRAWDIV bit of the ADC0 register was not being set. This bit is set by default after power on, but the driver was clearing it. After setting this bit it is possible to read the ADC values correctly. Signed-off-by: Fabio Estevam Tested-by: Chris Healy Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 02c9ec11860f217006bc04c16d960cdba8de1c23 Author: Sapthagiri Baratam Date: Tue Aug 21 19:52:44 2018 +0530 mfd: arizona: Correct calling of runtime_put_sync [ Upstream commit 6b269a41a4520f7eb639e61a45ebbb9c9267d5e0 ] Don't call runtime_put_sync when clk32k_ref is ARIZONA_32KZ_MCLK2 as there is no corresponding runtime_get_sync call. MCLK1 is not in the AoD power domain so if it is used as 32kHz clock source we need to hold a runtime PM reference to keep the device from going into low power mode. Fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks") Signed-off-by: Sapthagiri Baratam Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e79d230832d02e4783df5fc62ad7c8752fe846c4 Author: Ivan Khoronzhuk Date: Mon Oct 22 21:51:36 2018 +0300 net: ethernet: ti: cpsw: unsync mcast entries while switch promisc mode [ Upstream commit 9737cc99dd14b5b8b9d267618a6061feade8ea68 ] After flushing all mcast entries from the table, the ones contained in mc list of ndev are not restored when promisc mode is toggled off, because they are considered as synched with ALE, thus, in order to restore them after promisc mode - reset syncing info. This fix touches only switch mode devices, including single port boards like Beagle Bone. Fixes: commit 5da1948969bc ("net: ethernet: ti: cpsw: fix lost of mcast packets while rx_mode update") Signed-off-by: Ivan Khoronzhuk Reviewed-by: Grygorii Strashko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c011435110f150abba12ab187c131fa902e2520 Author: Dan Carpenter Date: Fri Oct 19 23:11:11 2018 +0300 qlcnic: fix a return in qlcnic_dcb_get_capability() [ Upstream commit c94f026fb742b2d3199422751dbc4f6fc0e753d8 ] These functions are supposed to return one on failure and zero on success. Returning a zero here could cause uninitialized variable bugs in several of the callers. For example: drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:1660 get_iscsi_dcb_priority() error: uninitialized symbol 'caps'. Fixes: 48365e485275 ("qlcnic: dcb: Add support for CEE Netlink interface.") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 321c40dce58185672882e9250ce333eec1f91886 Author: Nathan Chancellor Date: Fri Oct 19 11:00:30 2018 -0700 mISDN: Fix type of switch control variable in ctrl_teimanager [ Upstream commit aeb5e02aca91522733eb1db595ac607d30c87767 ] Clang warns (trimmed for brevity): drivers/isdn/mISDN/tei.c:1193:7: warning: overflow converting case value to switch condition type (2147764552 to 18446744071562348872) [-Wswitch] case IMHOLD_L1: ^ drivers/isdn/mISDN/tei.c:1187:7: warning: overflow converting case value to switch condition type (2147764550 to 18446744071562348870) [-Wswitch] case IMCLEAR_L2: ^ 2 warnings generated. The root cause is that the _IOC macro can generate really large numbers, which don't find into type int. My research into how GCC and Clang are handling this at a low level didn't prove fruitful and surveying the kernel tree shows that aside from here and a few places in the scsi subsystem, everything that uses _IOC is at least of type 'unsigned int'. Make that change here because as nothing in this function cares about the signedness of the variable and it removes ambiguity, which is never good when dealing with compilers. While we're here, remove the unnecessary local variable ret (just return -EINVAL and 0 directly). Link: https://github.com/ClangBuiltLinux/linux/issues/67 Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 074af1668038e5743bddb413681e345d632e7a97 Author: Chao Yu Date: Sun Oct 7 19:06:15 2018 +0800 f2fs: spread f2fs_set_inode_flags() [ Upstream commit 9149a5eb606152df158eb7d7da5a34e84b574189 ] This patch changes codes as below: - use f2fs_set_inode_flags() to update i_flags atomically to avoid potential race. - synchronize F2FS_I(inode)->i_flags to inode->i_flags in f2fs_new_inode(). - use f2fs_set_inode_flags() to simply codes in f2fs_quota_{on,off}. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e7f81efae3b5c90684a83dc95aab1ba5c8c7b7cf Author: Chao Yu Date: Fri Jul 27 18:15:16 2018 +0800 f2fs: fix to spread clear_cold_data() [ Upstream commit 2baf07818549c8bb8d7b3437e889b86eab56d38e ] We need to drop PG_checked flag on page as well when we clear PG_uptodate flag, in order to avoid treating the page as GCing one later. Signed-off-by: Weichao Guo Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 733fddc346515d1d44c577efa7d36cb02fb57a3f Author: Dan Carpenter Date: Wed Sep 19 13:35:00 2018 +0300 thermal: armada: fix a test in probe() [ Upstream commit d1d2c290b3c04b65fa6132eeebe50a070746d8f6 ] The platform_get_resource() function doesn't return error pointers, it returns NULL on error. Fixes: 3d4e51844a4e ("thermal: armada: convert driver to syscon register accesses") Signed-off-by: Dan Carpenter Reviewed-by: Miquel Raynal Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin commit bb925b9bece25e3c53fb06dc0cbcc4f3e40b196e Author: Vincent Chen Date: Tue Oct 2 16:52:31 2018 +0800 RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap [ Upstream commit 827a438156e4c423b6875a092e272933952a2910 ] For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK. Signed-off-by: Vincent Chen Reviewed-by: Christoph Hellwig Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 829aa617bf6e061964a724d48a2cb892752fa5ef Author: Nathan Chancellor Date: Fri Oct 19 13:43:45 2018 -0700 rtc: s35390a: Change buf's type to u8 in s35390a_init [ Upstream commit ef0f02fd69a02b50e468a4ddbe33e3d81671e248 ] Clang warns: drivers/rtc/rtc-s35390a.c:124:27: warning: implicit conversion from 'int' to 'char' changes value from 192 to -64 [-Wconstant-conversion] buf = S35390A_FLAG_RESET | S35390A_FLAG_24H; ~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ 1 warning generated. Update buf to be an unsigned 8-bit integer, which matches the buf member in struct i2c_msg. https://github.com/ClangBuiltLinux/linux/issues/145 Signed-off-by: Nathan Chancellor Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 8112f3d4ed036ca5caacecad23e31e805fb93ec6 Author: Luis Henriques Date: Tue Oct 9 18:54:28 2018 +0100 ceph: only allow punch hole mode in fallocate [ Upstream commit bddff633ab7bc60a18a86ac8b322695b6f8594d0 ] Current implementation of cephfs fallocate isn't correct as it doesn't really reserve the space in the cluster, which means that a subsequent call to a write may actually fail due to lack of space. In fact, it is currently possible to fallocate an amount space that is larger than the free space in the cluster. It has behaved this way since the initial commit ad7a60de882a ("ceph: punch hole support"). Since there's no easy solution to fix this at the moment, this patch simply removes support for all fallocate operations but FALLOC_FL_PUNCH_HOLE (which implies FALLOC_FL_KEEP_SIZE). Link: https://tracker.ceph.com/issues/36317 Signed-off-by: Luis Henriques Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 146fb4b0d4fe8a35e3cc28cd7a9fa69a5d1ee8ab Author: Yan, Zheng Date: Fri Sep 28 09:10:29 2018 +0800 ceph: fix dentry leak in ceph_readdir_prepopulate [ Upstream commit c58f450bd61511d897efc2ea472c69630635b557 ] Signed-off-by: "Yan, Zheng" Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 083757d848597e5e33528c931751ceb8a98bc6c0 Author: Quentin Monnet Date: Sat Oct 20 23:01:50 2018 +0100 tools: bpftool: fix completion for "bpftool map update" [ Upstream commit fe8ecccc10b3adc071de05ca7af728ca1a4ac9aa ] When trying to complete "bpftool map update" commands, the call to printf would print an error message that would show on the command line if no map is found to complete the command line. Fix it by making sure we have map ids to complete the line with, before we try to print something. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 570c05378d971ab29e6e67500c8b0e6fdd19dc93 Author: Quentin Monnet Date: Sat Oct 20 22:58:44 2018 +0100 selftests/bpf: fix return value comparison for tests in test_libbpf.sh [ Upstream commit c5fa5d602221362f8341ecd9e32d83194abf5bd9 ] The return value for each test in test_libbpf.sh is compared with if (( $? == 0 )) ; then ... This works well with bash, but not with dash, that /bin/sh is aliased to on some systems (such as Ubuntu). Let's replace this comparison by something that works on both shells. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3173e226ca412a80267f471ce173e326895198df Author: Nicholas Piggin Date: Tue Aug 28 18:11:27 2018 +1000 powerpc/64s/radix: Fix radix__flush_tlb_collapsed_pmd double flushing pmd [ Upstream commit dd76ff5af35350fd6d5bb5b069e73b6017f66893 ] Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b43c5287f6bca1bfaef43326130515c1256856ff Author: Michael Ellerman Date: Tue Aug 14 21:05:20 2018 +1000 powerpc/mm/radix: Fix small page at boundary when splitting [ Upstream commit 81d1b54dec95209ab5e5be2cf37182885f998753 ] When we have CONFIG_STRICT_KERNEL_RWX enabled, we want to split the linear mapping at the text/data boundary so we can map the kernel text read only. Currently we always use a small page at the text/data boundary, even when that's not necessary: Mapped 0x0000000000000000-0x0000000000e00000 with 2.00 MiB pages Mapped 0x0000000000e00000-0x0000000001000000 with 64.0 KiB pages Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages This is because the check that the mapping crosses the __init_begin boundary is too strict, it also returns true when we map exactly up to the boundary. So fix it to check that the mapping would actually map past __init_begin, and with that we see: Mapped 0x0000000000000000-0x0000000040000000 with 2.00 MiB pages Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit b499fa070ee4827931c443811a08cced55f8f00a Author: Michael Ellerman Date: Tue Aug 14 20:48:22 2018 +1000 powerpc/mm/radix: Fix overuse of small pages in splitting logic [ Upstream commit 3b5657ed5b4e27ccf593a41ff3c5aa27dae8df18 ] When we have CONFIG_STRICT_KERNEL_RWX enabled, we want to split the linear mapping at the text/data boundary so we can map the kernel text read only. But the current logic uses small pages for the entire text section, regardless of whether a larger page size would fit. eg. with the boundary at 16M we could use 2M pages, but instead we use 64K pages up to the 16M boundary: Mapped 0x0000000000000000-0x0000000001000000 with 64.0 KiB pages Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages This is because the test is checking if addr is < __init_begin and addr + mapping_size is >= _stext. But that is true for all pages between _stext and __init_begin. Instead what we want to check is if we are crossing the text/data boundary, which is at __init_begin. With that fixed we see: Mapped 0x0000000000000000-0x0000000000e00000 with 2.00 MiB pages Mapped 0x0000000000e00000-0x0000000001000000 with 64.0 KiB pages Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages ie. we're correctly using 2MB pages below __init_begin, but we still drop down to 64K pages unnecessarily at the boundary. Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 434551e9fd4485b18df07c8566fb2df59105dcc0 Author: Michael Ellerman Date: Fri Aug 10 22:29:26 2018 +1000 powerpc/mm/radix: Fix off-by-one in split mapping logic [ Upstream commit 5c6499b7041b43807dfaeda28aa87fc0e62558f7 ] When we have CONFIG_STRICT_KERNEL_RWX enabled, we try to split the kernel linear (1:1) mapping so that the kernel text is in a separate page to kernel data, so we can mark the former read-only. We could achieve that just by always using 64K pages for the linear mapping, but we try to be smarter. Instead we use huge pages when possible, and only switch to smaller pages when necessary. However we have an off-by-one bug in that logic, which causes us to calculate the wrong boundary between text and data. For example with the end of the kernel text at 16M we see: radix-mmu: Mapped 0x0000000000000000-0x0000000001200000 with 64.0 KiB pages radix-mmu: Mapped 0x0000000001200000-0x0000000040000000 with 2.00 MiB pages radix-mmu: Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages ie. we mapped from 0 to 18M with 64K pages, even though the boundary between text and data is at 16M. With the fix we see we're correctly hitting the 16M boundary: radix-mmu: Mapped 0x0000000000000000-0x0000000001000000 with 64.0 KiB pages radix-mmu: Mapped 0x0000000001000000-0x0000000040000000 with 2.00 MiB pages radix-mmu: Mapped 0x0000000040000000-0x0000000100000000 with 1.00 GiB pages Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ee35e01b0f08affff2c03dbd1c1f11bababf908e Author: Aravinda Prasad Date: Tue Oct 16 17:20:05 2018 +0530 powerpc/pseries: Export raw per-CPU VPA data via debugfs [ Upstream commit c6c26fb55e8e4b3fc376be5611685990a17de27a ] This patch exports the raw per-CPU VPA data via debugfs. A per-CPU file is created which exports the VPA data of that CPU to help debug some of the VPA related issues or to analyze the per-CPU VPA related statistics. v3: Removed offline CPU check. v2: Included offline CPU check and other review comments. Signed-off-by: Aravinda Prasad Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 9ed143cf730d6a13415da0a6a3456560bb4bc6cf Author: Gustavo A. R. Silva Date: Thu Oct 18 18:59:39 2018 +0200 scsi: hisi_sas: Fix NULL pointer dereference [ Upstream commit f4445bb93d82a984657b469e63118c2794a4c3d3 ] There is a NULL pointer dereference in case *slot* happens to be NULL at lines 1053 and 1878: struct hisi_sas_cq *cq = &hisi_hba->cq[slot->dlvry_queue]; Notice that *slot* is being NULL checked at lines 1057 and 1881: if (slot), which implies it may be NULL. Fix this by placing the declaration and definition of variable cq, which contains the pointer dereference slot->dlvry_queue, after slot has been properly NULL checked. Addresses-Coverity-ID: 1474515 ("Dereference before null check") Addresses-Coverity-ID: 1474520 ("Dereference before null check") Fixes: 584f53fe5f52 ("scsi: hisi_sas: Fix the race between IO completion and timeout for SMP/internal IO") Signed-off-by: Gustavo A. R. Silva Reviewed-by: Xiang Chen Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ff6618e06cb4548b8ceaed1855ee39976a1f4aaf Author: David S. Miller Date: Fri Oct 19 10:52:52 2018 -0700 sparc: Fix parport build warnings. [ Upstream commit 46b8306480fb424abd525acc1763da1c63a27d8a ] If PARPORT_PC_FIFO is not enabled, do not provide the dma lock macros and lock definition. Otherwise: ./arch/sparc/include/asm/parport.h:24:24: warning: ‘dma_spin_lock’ defined but not used [-Wunused-variable] static DEFINE_SPINLOCK(dma_spin_lock); ^~~~~~~~~~~~~ ./include/linux/spinlock_types.h:81:39: note: in definition of macro ‘DEFINE_SPINLOCK’ #define DEFINE_SPINLOCK(x) spinlock_t x = __SPIN_LOCK_UNLOCKED(x) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3d02e3bb3cfe1a9289b1ee27dec2f6d1248d48bd Author: Jithu Joseph Date: Fri Oct 12 15:51:01 2018 -0700 x86/intel_rdt: Prevent pseudo-locking from using stale pointers [ Upstream commit b61b8bba18fe2b63d38fdaf9b83de25e2d787dfe ] When the last CPU in an rdt_domain goes offline, its rdt_domain struct gets freed. Current pseudo-locking code is unaware of this scenario and tries to dereference the freed structure in a few places. Add checks to prevent pseudo-locking code from doing this. While further work is needed to seamlessly restore resource groups (not just pseudo-locking) to their configuration when the domain is brought back online, the immediate issue of invalid pointers is addressed here. Fixes: f4e80d67a5274 ("x86/intel_rdt: Resctrl files reflect pseudo-locked information") Fixes: 443810fe61605 ("x86/intel_rdt: Create debugfs files for pseudo-locking testing") Fixes: 746e08590b864 ("x86/intel_rdt: Create character device exposing pseudo-locked region") Fixes: 33dc3e410a0d9 ("x86/intel_rdt: Make CPU information accessible for pseudo-locked regions") Signed-off-by: Jithu Joseph Signed-off-by: Reinette Chatre Signed-off-by: Thomas Gleixner Cc: fenghua.yu@intel.com Cc: tony.luck@intel.com Cc: gavin.hindman@intel.com Cc: hpa@zytor.com Link: https://lkml.kernel.org/r/231f742dbb7b00a31cc104416860e27dba6b072d.1539384145.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit b6e44f7439510a0058afed5779ed9640a802e0e9 Author: Vignesh R Date: Mon Oct 15 12:08:28 2018 +0530 spi: omap2-mcspi: Set FIFO DMA trigger level to word length [ Upstream commit b682cffa3ac6d9d9e16e9b413c45caee3b391fab ] McSPI has 32 byte FIFO in Transmit-Receive mode. Current code tries to configuration FIFO watermark level for DMA trigger to be GCD of transfer length and max FIFO size which would mean trigger level may be set to 32 for transmit-receive mode if length is aligned. This does not work in case of SPI slave mode where FIFO always needs to have data ready whenever master starts the clock. With DMA trigger size of 32 there will be a small window during slave TX where DMA is still putting data into FIFO but master would have started clock for next byte, resulting in shifting out of stale data. Similarly, on Slave RX side there may be RX FIFO overflow Fix this by setting FIFO watermark for DMA trigger to word length. This means DMA is triggered as soon as FIFO has space for word length bytes and DMA would make sure FIFO is almost always full therefore improving FIFO occupancy in both master and slave mode. Signed-off-by: Vignesh R Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad9a4e963c9270370934ad93c5760c26a521b058 Author: Christoph Hellwig Date: Thu Apr 12 10:38:08 2018 +0200 swiotlb: do not panic on mapping failures [ Upstream commit 8088546832aa2c0d8f99dd56edf6384f8a9b63b3 ] All properly written drivers now have error handling in the dma_map_single / dma_map_page callers. As swiotlb_tbl_map_single already prints a useful warning when running out of swiotlb pool space we can also remove swiotlb_full entirely as it serves no purpose now. Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy Signed-off-by: Sasha Levin commit 9b572e8bc0385c05009b173f0385ee7d1fb45583 Author: Thomas Richter Date: Mon Oct 15 14:39:29 2018 +0100 s390/perf: Return error when debug_register fails [ Upstream commit ec0c0bb489727de0d4dca6a00be6970ab8a3b30a ] Return an error when the function debug_register() fails allocating the debug handle. Also remove the registered debug handle when the initialization fails later on. Signed-off-by: Thomas Richter Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 641f1f798c80e0e93126a1b4fd91667c5a0918da Author: Nathan Chancellor Date: Wed Oct 17 11:04:19 2018 -0700 atm: zatm: Fix empty body Clang warnings [ Upstream commit 64b9d16e2d02ca6e5dc8fcd30cfd52b0ecaaa8f4 ] Clang warns: drivers/atm/zatm.c:513:7: error: while loop has empty body [-Werror,-Wempty-body] zwait; ^ drivers/atm/zatm.c:513:7: note: put the semicolon on a separate line to silence this warning Get rid of this warning by using an empty do-while loop. While we're at it, add parentheses to make it clear that this is a function-like macro. Link: https://github.com/ClangBuiltLinux/linux/issues/42 Suggested-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f9304c6277ededc5dad10c9f22f05bbb1c7f07c3 Author: J. Bruce Fields Date: Thu Oct 18 15:27:02 2018 -0400 sunrpc: safely reallow resvport min/max inversion [ Upstream commit 826799e66e8683e5698e140bb9ef69afc8c0014e ] Commits ffb6ca33b04b and e08ea3a96fc7 prevent setting xprt_min_resvport greater than xprt_max_resvport, but may also break simple code that sets one parameter then the other, if the new range does not overlap the old. Also it looks racy to me, unless there's some serialization I'm not seeing. Granted it would probably require malicious privileged processes (unless there's a chance these might eventually be settable in unprivileged containers), but still it seems better not to let userspace panic the kernel. Simpler seems to be to allow setting the parameters to whatever you want but interpret xprt_min_resvport > xprt_max_resvport as the empty range. Fixes: ffb6ca33b04b "sunrpc: Prevent resvport min/max inversion..." Fixes: e08ea3a96fc7 "sunrpc: Prevent rexvport min/max inversion..." Signed-off-by: J. Bruce Fields Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7983dea8c368c396c2e246885336496c67573300 Author: Trond Myklebust Date: Thu Oct 18 17:03:56 2018 -0400 SUNRPC: Fix a compile warning for cmpxchg64() [ Upstream commit e732f4485a150492b286f3efc06f9b34dd6b9995 ] Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit a0ec7f6eabe88eb72acfef786c706c453fef6872 Author: Peng Hao Date: Thu Oct 18 23:18:36 2018 +0800 selftests/bpf: fix file resource leak in load_kallsyms [ Upstream commit 1bd70d2eba9d90eb787634361f0f6fa2c86b3f6d ] FILE pointer variable f is opened but never closed. Signed-off-by: Peng Hao Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 56b8b18321223aa3574856f17457539e8c117726 Author: Heinz Mauelshagen Date: Fri Oct 12 20:24:25 2018 +0200 dm raid: avoid bitmap with raid4/5/6 journal device [ Upstream commit d857ad75edf3c0066fcd920746f9dc75382b3324 ] With raid4/5/6, journal device and write intent bitmap are mutually exclusive. Signed-off-by: Heinz Mauelshagen Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 4de506d51177d8ad2a48a212408c494c67efbd15 Author: Xin Long Date: Wed Oct 17 03:07:51 2018 +0800 sctp: use sk_wmem_queued to check for writable space [ Upstream commit cd305c74b0f8b49748a79a8f67fc8e5e3e0c4794 ] sk->sk_wmem_queued is used to count the size of chunks in out queue while sk->sk_wmem_alloc is for counting the size of chunks has been sent. sctp is increasing both of them before enqueuing the chunks, and using sk->sk_wmem_alloc to check for writable space. However, sk_wmem_alloc is also increased by 1 for the skb allocked for sending in sctp_packet_transmit() but it will not wake up the waiters when sk_wmem_alloc is decreased in this skb's destructor. If msg size is equal to sk_sndbuf and sendmsg is waiting for sndbuf, the check 'msg_len <= sctp_wspace(asoc)' in sctp_wait_for_sndbuf() will keep waiting if there's a skb allocked in sctp_packet_transmit, and later even if this skb got freed, the waiting thread will never get waked up. This issue has been there since very beginning, so we change to use sk->sk_wmem_queued to check for writable space as sk_wmem_queued is not increased for the skb allocked for sending, also as TCP does. SOCK_SNDBUF_LOCK check is also removed here as it's for tx buf auto tuning which I will add in another patch. Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f7f2a0666a31d824e98e54220bba96f5ac2f4ee Author: Colin Ian King Date: Tue Oct 16 19:03:43 2018 +0100 usbip: tools: fix atoi() on non-null terminated string [ Upstream commit e325808c0051b16729ffd472ff887c6cae5c6317 ] Currently the call to atoi is being passed a single char string that is not null terminated, so there is a potential read overrun along the stack when parsing for an integer value. Fix this by instead using a 2 char string that is initialized to all zeros to ensure that a 1 char read into the string is always terminated with a \0. Detected by cppcheck: "Invalid atoi() argument nr 1. A nul-terminated string is required." Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with vudc backend") Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 283d9618e22b7ff43ac6fc16c35f3c4d24fbb733 Author: Mattias Jacobsson <2pi@mok.nu> Date: Tue Oct 16 14:20:08 2018 +0200 USB: misc: appledisplay: fix backlight update_status return code [ Upstream commit 090158555ff8d194a98616034100b16697dd80d0 ] Upon success the update_status handler returns a positive number corresponding to the number of bytes transferred by usb_control_msg. However the return code of the update_status handler should indicate if an error occurred(negative) or how many bytes of the user's input to sysfs that was consumed. Return code zero indicates all bytes were consumed. The bug can for example result in the update_status handler being called twice, the second time with only the "unconsumed" part of the user's input to sysfs. Effectively setting an incorrect brightness. Change the update_status handler to return zero for all successful transactions and forward usb_control_msg's error code upon failure. Signed-off-by: Mattias Jacobsson <2pi@mok.nu> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 80a23f70d546a6fc74561ce7f9e4e65cb6580791 Author: Jon Derrick Date: Mon Oct 15 18:48:07 2018 -0600 PCI: vmd: Detach resources after stopping root bus [ Upstream commit dc8af3a827df6d4bb925d3b81b7ec94a7cce9482 ] The VMD removal path calls pci_stop_root_busi(), which tears down the pcie tree, including detaching all of the attached drivers. During driver detachment, devices may use pci_release_region() to release resources. This path relies on the resource being accessible in resource tree. By detaching the child domain from the parent resource domain prior to stopping the bus, we are preventing the list traversal from finding the resource to be freed. If we instead detach the resource after stopping the bus, we will have properly freed the resource and detaching is simply accounting at that point. Without this order, the resource is never freed and is orphaned on VMD removal, leading to a warning: [ 181.940162] Trying to free nonexistent resource Fixes: 2c2c5c5cd213 ("x86/PCI: VMD: Attach VMD resources to parent domain's resource tree") Signed-off-by: Jon Derrick [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi Reviewed-by: Keith Busch Signed-off-by: Sasha Levin commit b0f69ccfff3a353d08ee2aa5bb3a39f701d2482d Author: Benjamin Herrenschmidt Date: Mon Oct 15 11:18:49 2018 +1100 macintosh/windfarm_smu_sat: Fix debug output [ Upstream commit fc0c8b36d379a046525eacb9c3323ca635283757 ] There's some antiquated debug output that's trying to do a hand-made hexdump and turning into horrible 1-byte-per-line output these days. Use print_hex_dump() instead Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 86f63146f8861b00dbb4c2c2def8edae4c44b6f1 Author: Philipp Klocke Date: Thu Oct 18 12:33:02 2018 +0200 ALSA: i2c/cs8427: Fix int to char conversion [ Upstream commit eb7ebfa3c1989aa8e59d5e68ab3cddd7df1bfb27 ] Compiling with clang yields the following warning: sound/i2c/cs8427.c:140:31: warning: implicit conversion from 'int' to 'char' changes value from 160 to -96 [-Wconstant-conversion] data[0] = CS8427_REG_AUTOINC | CS8427_REG_CORU_DATABUF; ~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ Because CS8427_REG_AUTOINC is defined as 128, it is too big for a char field. So change data from char to unsigned char, that it can hold the value. This patch does not change the generated code. Signed-off-by: Philipp Klocke Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 46729b27706a381193c8dbf911e7d0a7004f770a Author: Ulf Hansson Date: Wed Oct 3 16:38:15 2018 +0200 PM / Domains: Deal with multiple states but no governor in genpd [ Upstream commit 2c9b7f8772033cc8bafbd4eefe2ca605bf3eb094 ] A caller of pm_genpd_init() that provides some states for the genpd via the ->states pointer in the struct generic_pm_domain, should also provide a governor. This because it's the job of the governor to pick a state that satisfies the constraints. Therefore, let's print a warning to inform the user about such bogus configuration and avoid to bail out, by instead picking the shallowest state before genpd invokes the ->power_off() callback. Signed-off-by: Ulf Hansson Reviewed-by: Lina Iyer Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cf800f2b630b4f7b16a808b0f1f33ad810c6ebad Author: Hans de Goede Date: Wed Oct 17 10:59:28 2018 +0200 ACPI / scan: Create platform device for INT33FE ACPI nodes [ Upstream commit 589edb56b424876cbbf61547b987a1f57d7ea99d ] Bay and Cherry Trail devices with a Dollar Cove or Whiskey Cove PMIC have an ACPI node with a HID of INT33FE which is a "virtual" battery device implementing a standard ACPI battery interface which depends upon a proprietary, undocument OpRegion called BMOP. Since we do have docs for the actual fuel-gauges used on these boards we instead use native fuel-gauge drivers talking directly to the fuel-gauge ICs on boards which rely on this INT33FE device for their battery monitoring. On boards with a Dollar Cove PMIC the INT33FE device's resources (_CRS) describe a non-existing I2C client at address 0x6b with a bus-speed of 100KHz. This is a problem on some boards since there are actual devices on that same bus which need a speed of 400KHz to function properly. This commit adds the INT33FE HID to the list of devices with I2C resources which should be enumerated as a platform-device rather then letting the i2c-core instantiate an i2c-client matching the first I2C resource, so that its bus-speed will not influence the max speed of the I2C bus. This fixes e.g. the touchscreen not working on the Teclast X98 II Plus. The INT33FE device on boards with a Whiskey Cove PMIC is somewhat special. Its first I2C resource is for a secondary I2C address of the PMIC itself, which is already described in an ACPI device with an INT34D3 HID. But it has 3 more I2C resources describing 3 other chips for which we do need to instantiate I2C clients and which need device-connections added between them for things to work properly. This special case is handled by the drivers/platform/x86/intel_cht_int33fe.c code. Before this commit that code was binding to the i2c-client instantiated for the secondary I2C address of the PMIC, since we now instantiate a platform device for the INT33FE device instead, this commit also changes the intel_cht_int33fe driver from an i2c driver to a platform driver. This also brings the intel_cht_int33fe drv inline with how we instantiate multiple i2c clients from a single ACPI device in other cases, as done by the drivers/platform/x86/i2c-multi-instantiate.c code. Reported-and-tested-by: Alexander Meiler Signed-off-by: Hans de Goede Acked-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cb6a3096ec2f97a3ab59daeda91866a7e29c0255 Author: Steven Rostedt (VMware) Date: Wed Oct 17 16:59:51 2018 -0400 kprobes, x86/ptrace.h: Make regs_get_kernel_stack_nth() not fault on bad stack [ Upstream commit c2712b858187f5bcd7b042fe4daa3ba3a12635c0 ] Andy had some concerns about using regs_get_kernel_stack_nth() in a new function regs_get_kernel_argument() as if there's any error in the stack code, it could cause a bad memory access. To be on the safe side, call probe_kernel_read() on the stack address to be extra careful in accessing the memory. A helper function, regs_get_kernel_stack_nth_addr(), was added to just return the stack address (or NULL if not on the stack), that will be used to find the address (and could be used by other functions) and read the address with kernel_probe_read(). Requested-by: Andy Lutomirski Signed-off-by: Steven Rostedt (VMware) Reviewed-by: Joel Fernandes (Google) Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Masami Hiramatsu Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20181017165951.09119177@gandalf.local.home Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit f0f842a1a9f98a637e20171828f3279b1def4083 Author: Brian Foster Date: Thu Oct 18 17:21:49 2018 +1100 xfs: clear ail delwri queued bufs on unmount of shutdown fs [ Upstream commit efc3289cf8d39c34502a7cc9695ca2fa125aad0c ] In the typical unmount case, the AIL is forced out by the unmount sequence before the xfsaild task is stopped. Since AIL items are removed on writeback completion, this means that the AIL ->ail_buf_list delwri queue has been drained. This is not always true in the shutdown case, however. It's possible for buffers to sit on a delwri queue for a period of time across submission attempts if said items are locked or have been relogged and pinned since first added to the queue. If the attempt to log such an item results in a log I/O error, the error processing can shutdown the fs, remove the item from the AIL, stale the buffer (dropping the LRU reference) and clear its delwri queue state. The latter bit means the buffer will be released from a delwri queue on the next submission attempt, but this might never occur if the filesystem has shutdown and the AIL is empty. This means that such buffers are held indefinitely by the AIL delwri queue across destruction of the AIL. Aside from being a memory leak, these buffers can also hold references to in-core perag structures. The latter problem manifests as a generic/475 failure, reproducing the following asserts at unmount time: XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 151 XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 132 To prevent this problem, clear the AIL delwri queue as a final step before xfsaild() exit. The !empty state should never occur in the normal case, so add an assert to catch unexpected problems going forward. [dgc: add comment explaining need for xfs_buf_delwri_cancel() after calling xfs_buf_delwri_submit_nowait().] Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit bb64349b6f5635d8688d186b06b4b2b24c0310a4 Author: Dave Chinner Date: Thu Oct 18 17:21:29 2018 +1100 xfs: fix use-after-free race in xfs_buf_rele [ Upstream commit 37fd1678245f7a5898c1b05128bc481fb403c290 ] When looking at a 4.18 based KASAN use after free report, I noticed that racing xfs_buf_rele() may race on dropping the last reference to the buffer and taking the buffer lock. This was the symptom displayed by the KASAN report, but the actual issue that was reported had already been fixed in 4.19-rc1 by commit e339dd8d8b04 ("xfs: use sync buffer I/O for sync delwri queue submission"). Despite this, I think there is still an issue with xfs_buf_rele() in this code: release = atomic_dec_and_lock(&bp->b_hold, &pag->pag_buf_lock); spin_lock(&bp->b_lock); if (!release) { ..... If two threads race on the b_lock after both dropping a reference and one getting dropping the last reference so release = true, we end up with: CPU 0 CPU 1 atomic_dec_and_lock() atomic_dec_and_lock() spin_lock(&bp->b_lock) spin_lock(&bp->b_lock) b_lru_ref = 0> freebuf = true spin_unlock(&bp->b_lock) xfs_buf_free(bp) spin_unlock(&bp->b_lock) IOWs, we can't safely take bp->b_lock after dropping the hold reference because the buffer may go away at any time after we drop that reference. However, this can be fixed simply by taking the bp->b_lock before we drop the reference. It is safe to nest the pag_buf_lock inside bp->b_lock as the pag_buf_lock is only used to serialise against lookup in xfs_buf_find() and no other locks are held over or under the pag_buf_lock there. Make this clear by documenting the buffer lock orders at the top of the file. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Reviewed-by: Carlos Maiolino Signed-off-by: Sasha Levin commit e0e8d83e4878692a4915a29524573e05dd59e117 Author: Netanel Belgazal Date: Wed Oct 17 10:04:21 2018 +0000 net: ena: Fix Kconfig dependency on X86 [ Upstream commit 8c590f9776386b8f697fd0b7ed6142ae6e3de79e ] The Kconfig limitation of X86 is to too wide. The ENA driver only requires a little endian dependency. Change the dependency to be on little endian CPU. Signed-off-by: Netanel Belgazal Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7ac437558e4a68f0127cba24bad6f98cff5c736f Author: Kyeongdon Kim Date: Tue Oct 16 14:57:26 2018 +0900 net: fix warning in af_unix [ Upstream commit 33c4368ee2589c165aebd8d388cbd91e9adb9688 ] This fixes the "'hash' may be used uninitialized in this function" net/unix/af_unix.c:1041:20: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized] addr->hash = hash ^ sk->sk_type; Signed-off-by: Kyeongdon Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5e110ec2d924171458f4099c53b04b7e30ffa929 Author: Marek Behún Date: Sat Oct 13 14:40:31 2018 +0200 net: dsa: mv88e6xxx: Fix 88E6141/6341 2500mbps SERDES speed [ Upstream commit 26422340da467538cd65eaa9c65538039ee99c8c ] This is a fix for the port_set_speed method for the Topaz family. Currently the same method is used as for the Peridot family, but this is wrong for the SERDES port. On Topaz, the SERDES port is port 5, not 9 and 10 as in Peridot. Moreover setting alt_bit on Topaz only makes sense for port 0 (for (differentiating 100mbps vs 200mbps). The SERDES port does not support more than 2500mbps, so alt_bit does not make any difference. Signed-off-by: Marek Behún Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 274726bcf5bac48ecc825a5c228fd5a630f932ac Author: Finn Thain Date: Tue Oct 16 16:31:25 2018 +1100 scsi: zorro_esp: Limit DMA transfers to 65535 bytes [ Upstream commit b7ded0e8b0d11b6df1c4e5aa23a26e6629c21985 ] The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so the chip's Transfer Counter register is only 16 bits wide (not 24). A larger transfer cannot work and will theoretically result in a failed command and a "DMA length is zero" error. Fixes: 3109e5ae0311 ("scsi: zorro_esp: New driver for Amiga Zorro NCR53C9x boards") Signed-off-by: Finn Thain Cc: Michael Schmitz Tested-by: Michael Schmitz Reviewed-by: Michael Schmitz Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1f13afca914fcd80f07c80ab36ccc6b6005460ed Author: Christoph Hellwig Date: Thu Oct 11 16:17:15 2018 +0200 scsi: dc395x: fix DMA API usage in sg_update_list [ Upstream commit 6c404a68bf83b4135a8a9aa1c388ebdf98e8ba7f ] We need to transfer device ownership to the CPU before we can manipulate the mapped data. Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e95ec662b1267022143ae03afdcc65715a76dc89 Author: Christoph Hellwig Date: Thu Oct 11 16:17:14 2018 +0200 scsi: dc395x: fix dma API usage in srb_done [ Upstream commit 3a5bd7021184dec2946f2a4d7a8943f8a5713e52 ] We can't just transfer ownership to the CPU and then unmap, as this will break with swiotlb. Instead unmap the command and sense buffer a little earlier in the I/O completion handler and get rid of the pci_dma_sync_sg_for_cpu call entirely. Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 95655b10529d2b9beee913088b762df0146238be Author: Marcel Ziswiler Date: Tue Oct 16 12:47:29 2018 +0200 ASoC: tegra_sgtl5000: fix device_node refcounting [ Upstream commit a85227da2dcc291b762c8482a505bc7d0d2d4b07 ] Similar to the following: commit 4321723648b0 ("ASoC: tegra_alc5632: fix device_node refcounting") commit 7c5dfd549617 ("ASoC: tegra: fix device_node refcounting") Signed-off-by: Marcel Ziswiler Acked-by: Jon Hunter Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f1f1002a998749efca04627a2aca3e09fe96bd48 Author: Alexandre Belloni Date: Tue Oct 16 16:21:39 2018 +0200 clk: at91: audio-pll: fix audio pmc type [ Upstream commit 7fa75007b7d7421aea59ff2b12ab1bd65a5abfa6 ] The allocation for the audio pmc is using the size of struct clk_audio_pad instead of struct clk_audio_pmc. This works fine because the former is larger than the latter but it is safer to be correct. Fixes: ("0865805d82d4 clk: at91: add audio pll clock drivers") Signed-off-by: Alexandre Belloni Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f15b802890bbfe30cae63f5d05531467db2e75d4 Author: Lubomir Rintel Date: Mon Sep 10 14:01:44 2018 +0200 clk: mmp2: fix the clock id for sdh2_clk and sdh3_clk [ Upstream commit 4917fb90eec7c26dac1497ada3bd4a325f670fcc ] A typo that makes it impossible to get the correct clocks for MMP2_CLK_SDH2 and MMP2_CLK_SDH3. Signed-off-by: Lubomir Rintel Fixes: 1ec770d92a62 ("clk: mmp: add mmp2 DT support for clock driver") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6391dd5eb0ef9fe7367819e32640dc853e8fd0c0 Author: Honghui Zhang Date: Mon Oct 15 16:08:56 2018 +0800 PCI: mediatek: Fixup MSI enablement logic by enabling MSI before clocks [ Upstream commit 3828d60fd2ef99f97a677c1f95af2ab3e65e2576 ] Commit 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") added MSI support but enabled MSI in the wrong place, at a step in the probe sequence where clocks were not still enabled. Fix this issue by calling mtk_pcie_enable_msi() in mtk_pcie_startup_port_v2() since clocks are enabled when mtk_pcie_startup_port_v2() is called. To avoid forward declaration of mtk_pcie_enable_msi(), move the mtk_pcie_startup_port_v2() function definition in the file. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Honghui Zhang [lorenzo.pieralisi@arm.com: squashed commit and adapted log] Signed-off-by: Lorenzo Pieralisi Acked-by: Ryder Lee Signed-off-by: Sasha Levin commit 305c262fb8ee63d8343a258704eb72876cdca9c7 Author: Keith Busch Date: Mon Oct 15 10:19:06 2018 -0600 nvme-pci: fix hot removal during error handling [ Upstream commit cb4bfda62afa25b4eee3d635d33fccdd9485dd7c ] A removal waits for the reset_work to complete. If a surprise removal occurs around the same time as an error triggered controller reset, and reset work happened to dispatch a command to the removed controller, the command won't be recovered since the timeout work doesn't do anything during error recovery. We wouldn't want to wait for timeout handling anyway, so this patch fixes this by disabling the controller and killing admin queues prior to syncing with the reset_work. Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4e4b97f59050f5ede5ef13b8db8d2fdf13aab136 Author: Bart Van Assche Date: Wed Oct 10 08:08:20 2018 -0700 nvmet-fcloop: suppress a compiler warning [ Upstream commit 1216e9ef18b84f4fb5934792368fb01eb3540520 ] Building with W=1 enables the compiler warning -Wimplicit-fallthrough=3. That option does not recognize the fall-through comment in the fcloop driver. Add a fall-through comment that is recognized for -Wimplicit-fallthrough=3. This patch avoids that the compiler reports the following warning when building with W=1: drivers/nvme/target/fcloop.c:647:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (op == NVMET_FCOP_READDATA) ^ Signed-off-by: Bart Van Assche Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2f1e4e65ba415908212d93d665a8338dad1aac8a Author: Bart Van Assche Date: Mon Oct 8 14:28:52 2018 -0700 nvmet: avoid integer overflow in the discard code [ Upstream commit 8eacd1bd21d6913ec27e6120e9a8733352e191d3 ] Although I'm not sure whether it is a good idea to support large discard commands, I think integer overflow for discard ranges larger than 4 GB should be avoided. This patch avoids that smatch reports the following: drivers/nvme/target/io-cmd-file.c:249:1 nvmet_file_execute_discard() warn: should '((range.nlb)) << req->ns->blksize_shift' be a 64 bit type? Fixes: d5eff33ee6f8 ("nvmet: add simple file backed ns support") Signed-off-by: Bart Van Assche Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 30ca1af4948123174d1b63bf6d6f967857a6a638 Author: Nathan Chancellor Date: Wed Oct 10 14:40:07 2018 -0700 crypto: ccree - avoid implicit enum conversion [ Upstream commit 18e732b8035d175181aae2ded127994cb01694f7 ] Clang warns when one enumerated type is implicitly converted to another and this happens in several locations in this driver, ultimately related to the set_cipher_{mode,config0} functions. set_cipher_mode expects a mode of type drv_cipher_mode and set_cipher_config0 expects a mode of type drv_crypto_direction. drivers/crypto/ccree/cc_ivgen.c:58:35: warning: implicit conversion from enumeration type 'enum cc_desc_direction' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(&iv_seq[idx], DESC_DIRECTION_ENCRYPT_ENCRYPT); drivers/crypto/ccree/cc_hash.c:99:28: warning: implicit conversion from enumeration type 'enum cc_hash_conf_pad' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(desc, HASH_DIGEST_RESULT_LITTLE_ENDIAN); drivers/crypto/ccree/cc_aead.c:1643:30: warning: implicit conversion from enumeration type 'enum drv_hash_hw_mode' to different enumeration type 'enum drv_cipher_mode' [-Wenum-conversion] set_cipher_mode(&desc[idx], DRV_HASH_HW_GHASH); Since this fundamentally isn't a problem because these values just represent simple integers for a shift operation, make it clear to Clang that this is okay by making the mode parameter in both functions an int. Link: https://github.com/ClangBuiltLinux/linux/issues/46 Signed-off-by: Nathan Chancellor Acked-by: Gilad Ben-Yossef Reviewed-by: Nick Desaulniers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5bbeb4fcf39a96caab99d22c612edb7239af4063 Author: Nathan Chancellor Date: Wed Oct 3 18:06:15 2018 -0700 scsi: iscsi_tcp: Explicitly cast param in iscsi_sw_tcp_host_get_param [ Upstream commit 20054597f169090109fc3f0dfa1a48583f4178a4 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/iscsi_tcp.c:803:15: warning: implicit conversion from enumeration type 'enum iscsi_host_param' to different enumeration type 'enum iscsi_param' [-Wenum-conversion] &addr, param, buf); ^~~~~ 1 warning generated. iscsi_conn_get_addr_param handles ISCSI_HOST_PARAM_IPADDRESS just fine so add an explicit cast to iscsi_param to make it clear to Clang that this is expected behavior. Link: https://github.com/ClangBuiltLinux/linux/issues/153 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 06815ae5e27f3dd6ab2f4c318f85e50c7d2dce37 Author: Nathan Chancellor Date: Thu Sep 27 16:56:52 2018 -0700 scsi: bfa: Avoid implicit enum conversion in bfad_im_post_vendor_event [ Upstream commit 761c830ec7b3d0674b3ad89cefd77a692634e305 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/bfa/bfa_fcs_lport.c:379:26: warning: implicit conversion from enumeration type 'enum bfa_lport_aen_event' to different enumeration type 'enum bfa_ioc_aen_event' [-Wenum-conversion] BFA_AEN_CAT_LPORT, event); ^~~~~ The root cause of these warnings is the bfad_im_post_vendor_event function, which expects a value from enum bfa_ioc_aen_event but there are multiple instances of values from enums bfa_port_aen_event, bfa_audit_aen_event, and bfa_lport_aen_event being used in this function. Given that this doesn't appear to be a problem since cat helps with differentiating the events, just change evt's type to int so that no conversion needs to happen and Clang won't warn. Update aen_type's type in bfa_aen_entry_s as members that hold enumerated types should be int. Link: https://github.com/ClangBuiltLinux/linux/issues/147 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f4bf2dc77826c0dfa98aed87ae829e0f070c2e61 Author: Nathan Chancellor Date: Wed Sep 26 17:12:00 2018 -0700 scsi: isci: Change sci_controller_start_task's return type to sci_status [ Upstream commit 362b5da3dfceada6e74ecdd7af3991bbe42c0c0f ] Clang warns when an enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:3476:13: warning: implicit conversion from enumeration type 'enum sci_task_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = sci_controller_start_task(ihost, ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/host.c:2744:10: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return SCI_SUCCESS; ~~~~~~ ^~~~~~~~~~~ drivers/scsi/isci/host.c:2753:9: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return status; ~~~~~~ ^~~~~~ Avoid all of these implicit conversion by just making sci_controller_start_task use sci_status. This silences Clang and has no functional change since sci_task_status has all of its values mapped to something in sci_status. Link: https://github.com/ClangBuiltLinux/linux/issues/153 Signed-off-by: Nathan Chancellor Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3a40068dc831b5e364b709613996754962e95cab Author: Nathan Chancellor Date: Wed Sep 26 17:11:50 2018 -0700 scsi: isci: Use proper enumerated type in atapi_d2h_reg_frame_handler [ Upstream commit e9e9a103528c7e199ead6e5374c9c52cf16b5802 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:1629:13: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/request.c:1631:12: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ status is of type sci_status but SCI_IO_FAILURE_RESPONSE_VALID is of type sci_io_status. Use SCI_FAILURE_IO_RESPONSE_VALID, which is from sci_status and has SCI_IO_FAILURE_RESPONSE_VALID's exact value since that is what SCI_IO_FAILURE_RESPONSE_VALID is mapped to in the isci.h file. Link: https://github.com/ClangBuiltLinux/linux/issues/153 Signed-off-by: Nathan Chancellor Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6288f52ed258d688726a31e7206061fad4833994 Author: Joseph Lo Date: Thu Sep 27 10:32:03 2018 +0800 clk: tegra: Fixes for MBIST work around [ Upstream commit a4dbbceeee3e0ba670875a147237d6566de78840 ] Fix some incorrect data in LVL2 offset and bit mask. Fixes: e403d0057343 ("clk: tegra: MBIST work around for Tegra210") Signed-off-by: Joseph Lo Signed-off-by: Peter De Schrijver Acked-by: Jon Hunter Acked-by: Peter De Schrijver Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5a487f40e717b99855be143497118de0452064d1 Author: Uros Bizjak Date: Thu Oct 11 19:40:43 2018 +0200 KVM/x86: Fix invvpid and invept register operand size in 64-bit mode [ Upstream commit 5ebb272b2ea7e02911a03a893f8d922d49f9bb4a ] Register operand size of invvpid and invept instruction in 64-bit mode has always 64 bits. Adjust inline function argument type to reflect correct size. Signed-off-by: Uros Bizjak Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 7392aa08f8a4386c99d5c6506a79e2ccd5b4701f Author: Sean Christopherson Date: Wed Sep 26 09:23:46 2018 -0700 KVM: nVMX: move check_vmentry_postreqs() call to nested_vmx_enter_non_root_mode() [ Upstream commit 7671ce21b13b9596163a29f4712cb2451a9b97dc ] In preparation of supporting checkpoint/restore for nested state, commit ca0bde28f2ed ("kvm: nVMX: Split VMCS checks from nested_vmx_run()") modified check_vmentry_postreqs() to only perform the guest EFER consistency checks when nested_run_pending is true. But, in the normal nested VMEntry flow, nested_run_pending is only set after check_vmentry_postreqs(), i.e. the consistency check is being skipped. Alternatively, nested_run_pending could be set prior to calling check_vmentry_postreqs() in nested_vmx_run(), but placing the consistency checks in nested_vmx_enter_non_root_mode() allows us to split prepare_vmcs02() and interleave the preparation with the consistency checks without having to change the call sites of nested_vmx_enter_non_root_mode(). In other words, the rest of the consistency check code in nested_vmx_run() will be joining the postreqs checks in future patches. Fixes: ca0bde28f2ed ("kvm: nVMX: Split VMCS checks from nested_vmx_run()") Signed-off-by: Sean Christopherson Cc: Jim Mattson Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 9fe573d539a827d123ba7503cc8ac2301424d26b Author: Sean Christopherson Date: Wed Sep 26 09:23:42 2018 -0700 KVM: nVMX: reset cache/shadows when switching loaded VMCS [ Upstream commit b7031fd40fcc741b0f9b0c04c8d844e445858b84 ] Reset the vm_{entry,exit}_controls_shadow variables as well as the segment cache after loading a new VMCS in vmx_switch_vmcs(). The shadows/cache track VMCS data, i.e. they're stale every time we switch to a new VMCS regardless of reason. This fixes a bug where stale control shadows would be consumed after a nested VMExit due to a failed consistency check. Suggested-by: Jim Mattson Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit cec14148c1a9ce23f404e01d56cb466b39dbe1c4 Author: Jakub Kicinski Date: Tue Oct 16 15:19:09 2018 -0700 nfp: bpf: protect against mis-initializing atomic counters [ Upstream commit 527db74b71ee5a279f818aae51f2c26b4e5c7648 ] Atomic operations on the NFP are currently always in big endian. The driver keeps track of regions of memory storing atomic values and byte swaps them accordingly. There are corner cases where the map values may be initialized before the driver knows they are used as atomic counters. This can happen either when the datapath is performing the update and the stack contents are unknown or when map is updated before the program which will use it for atomic values is loaded. To avoid situation where user initializes the value to 0 1 2 3 and then after loading a program which uses the word as an atomic counter starts reading 3 2 1 0 - only allow atomic counters to be initialized to endian-neutral values. For updates from the datapath the stack information may not be as precise, so just allow initializing such values to 0. Example code which would break: struct bpf_map_def SEC("maps") rxcnt = { .type = BPF_MAP_TYPE_HASH, .key_size = sizeof(__u32), .value_size = sizeof(__u64), .max_entries = 1, }; int xdp_prog1() { __u64 nonzeroval = 3; __u32 key = 0; __u64 *value; value = bpf_map_lookup_elem(&rxcnt, &key); if (!value) bpf_map_update_elem(&rxcnt, &key, &nonzeroval, BPF_ANY); else __sync_fetch_and_add(value, 1); return XDP_PASS; } $ offload bpftool map dump key: 00 00 00 00 value: 00 00 00 03 00 00 00 00 should be: $ offload bpftool map dump key: 00 00 00 00 value: 03 00 00 00 00 00 00 00 Reported-by: David Beckett Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bfe01cddb81a58a1a24062a4d562496116f7c560 Author: Gustavo A. R. Silva Date: Tue Oct 16 11:12:23 2018 +0200 scsi: ips: fix missing break in switch [ Upstream commit 5d25ff7a544889bc4b749fda31778d6a18dddbcb ] Add missing break statement in order to prevent the code from falling through to case TEST_UNIT_READY. Addresses-Coverity-ID: 1357338 ("Missing break in switch") Suggested-by: Martin K. Petersen Signed-off-by: Gustavo A. R. Silva Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 073f454cc28ce791a236f9a02a48346d7041b0ee Author: Rahul Verma Date: Tue Oct 16 03:59:18 2018 -0700 qed: Align local and global PTT to propagate through the APIs. [ Upstream commit 706d08913d1f68610c32b4a001026aa989878dd9 ] Align the use of local PTT to propagate through the qed_mcp* API's. Global ptt should not be used. Register access should be done through layers. Register address is mapped into a PTT, PF translation table. Several interface functions require a PTT to direct read/write into register. There is a pool of PTT maintained, and several PTT are used simultaneously to access device registers in different flows. Same PTT should not be used in flows that can run concurrently. To avoid running out of PTT resources, too many PTT should not be acquired without releasing them. Every PF has a global PTT, which is used throughout the life of PF, in most important flows for register access. Generic functions acquire the PTT locally and release after the use. This patch aligns the use of Global PTT and Local PTT accordingly. Signed-off-by: Rahul Verma Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 45f89cf0f329ac86e59ec18e163f6e5cb274dd49 Author: Omar Sandoval Date: Thu Oct 11 12:20:46 2018 -0700 amiflop: clean up on errors during setup [ Upstream commit 53d0f8dbde89cf6c862c7a62e00c6123e02cba41 ] The error handling in fd_probe_drives() doesn't clean up at all. Fix it up in preparation for converting to blk-mq. While we're here, get rid of the commented out amiga_floppy_remove(). Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4043bc0f634bf349da5612e87e189a6d71bad504 Author: Hans de Goede Date: Sun Oct 14 17:12:02 2018 +0200 pwm: lpss: Only set update bit if we are actually changing the settings [ Upstream commit 2153bbc12f77fb2203276befc0f0dddbfb023bb1 ] According to the datasheet the update bit must be set if the on-time-div or the base-unit changes. Now that we properly order device resume on Cherry Trail so that the GFX0 _PS0 method no longer exits with an error, we end up with a sequence of events where we are writing the same values twice in a row. First the _PS0 method restores the duty cycle of 0% the GPU driver set on suspend and then the GPU driver first updates just the enabled bit in the pwm_state from 0 to 1, causing us to write the same values again, before restoring the pre-suspend duty-cycle in a separate pwm_apply call. When writing the update bit the second time, without changing any of the values the update bit clears immediately / instantly, instead of staying 1 for a while as usual. After this the next setting of the update bit seems to be ignored, causing the restoring of the pre-suspend duty-cycle to not get applied. This makes the backlight come up with a 0% dutycycle after suspend/resume. Any further brightness changes after this do work. This commit moves the setting of the update bit into pwm_lpss_prepare() and only sets the bit if we have actually changed any of the values. This avoids the setting of the update bit the second time we configure the PWM to 0% dutycycle, this fixes the backlight coming up with 0% duty-cycle after a suspend/resume. Signed-off-by: Hans de Goede Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit ad78a958663aa7d37a41de5779f048e2334ecd09 Author: Christophe JAILLET Date: Tue Oct 16 08:22:28 2018 +0200 pinctrl: sunxi: Fix a memory leak in 'sunxi_pinctrl_build_state()' [ Upstream commit a93a676b079144009f55fff2ab0e34c3b7258c8a ] If 'krealloc()' fails, 'pctl->functions' is set to NULL. We should instead use a temp variable in order to be able to free the previously allocated memeory, in case of OOM. Signed-off-by: Christophe JAILLET Acked-by: Maxime Ripard Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fae3cf8874c38c40746dfe90ebcd674da72e88f8 Author: Selvin Xavier Date: Mon Oct 8 03:28:04 2018 -0700 RDMA/bnxt_re: Avoid resource leak in case the NQ registration fails [ Upstream commit 5df950994934814a8b91f0cf9f653842d2ba082d ] In case the NQ alloc/enable fails, free up the already allocated/enabled NQ before reporting failure. Also, track the alloc/enable using proper state checking. Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b1bf1e424dcb619e6954355afa488a65b632a0c6 Author: Devesh Sharma Date: Mon Oct 8 03:28:01 2018 -0700 RDMA/bnxt_re: Fix qp async event reporting [ Upstream commit 4c01f2e3a906a0d2d798be5751c331cf501bc129 ] Reports affiliated async event on the qp-async event channel instead of global event channel. Signed-off-by: Devesh Sharma Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2f241e333f7b5cb7e5aca9a02c1775e800db9e2e Author: Selvin Xavier Date: Mon Oct 8 03:27:55 2018 -0700 RDMA/bnxt_re: Avoid NULL check after accessing the pointer [ Upstream commit eae4ad1b0c9a77ef0cbac212d58d46976eaacfc1 ] This is reported by smatch check. rcfw->creq_bar_reg_iomem is accessed in bnxt_qplib_rcfw_stop_irq and this variable check afterwards doesn't make sense. Also, rcfw->creq_bar_reg_iomem will never be NULL. So Removing this check. Reported-by: Dan Carpenter Fixes: 6e04b1035689 ("RDMA/bnxt_re: Fix broken RoCE driver due to recent L2 driver changes") Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bbeeadb7bab415bef91cdd8a86fbc9d1891cbaa1 Author: Xiang Chen Date: Mon Sep 24 23:06:31 2018 +0800 scsi: hisi_sas: Free slot later in slot_complete_vx_hw() [ Upstream commit 3e178f3ecfcf91a258e832b0f0843a4cfd9059ac ] If an SSP/SMP IO times out, it may be actually in reality be simultaneously processing completion of the slot in slot_complete_vx_hw(). Then if the slot is freed in slot_complete_vx_hw() (this IPTT is freed and it may be re-used by other slot), and we may abort the wrong slot in hisi_sas_abort_task(). So to solve the issue, free the slot after the check of SAS_TASK_STATE_ABORTED in slot_complete_vx_hw(). Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 628cae51693a71ef71b0a54a4734d2817eb30976 Author: Xiang Chen Date: Mon Sep 24 23:06:30 2018 +0800 scsi: hisi_sas: Fix the race between IO completion and timeout for SMP/internal IO [ Upstream commit 584f53fe5f529d877968c711a095923c1ed12307 ] If SMP/internal IO times out, we will possibly free the task immediately. However if the IO actually completes at the same time, the IO completion may refer to task which has been freed. So to solve the issue, flush the tasklet to finish IO completion before free'ing slot/task. Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d10b7dd14a37dcc5c5fc21ad9119ad614f924f36 Author: Luo Jiaxing Date: Mon Sep 24 23:06:28 2018 +0800 scsi: hisi_sas: Feed back linkrate(max/min) when re-attached [ Upstream commit 5a54691f874ab29ec82f08bc6936866a3ccdaa91 ] At directly attached situation, if the user modifies the sysfs interface of maximum_linkrate and minimum_linkrate to renegotiate the linkrate between SAS controller and target, the value of both files mentioned above should have change to user setting after renegotiate is over, but it remains unchanged. To fix this bug, maximum_linkrate and minimum_linkrate will be directly fed back to relevant sas_phy structure. Signed-off-by: Luo Jiaxing Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 92ac0e3249746a852478af8c644aa81657c479ad Author: Angelo Dureghello Date: Fri Sep 7 14:44:25 2018 +0200 m68k: fix command-line parsing when passed from u-boot [ Upstream commit 381fdd62c38344a771aed06adaf14aae65c47454 ] This patch fixes command_line array zero-terminated one byte over the end of the array, causing boot to hang. Signed-off-by: Angelo Dureghello Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 4ab1594e699ed2371e7ea9e6893b58e4038a40fc Author: Julien Folly Date: Tue Oct 9 19:47:45 2018 +0200 w1: IAD Register is yet readable trough iad sys file. Fix snprintf (%u for unsigned, count for max size). [ Upstream commit 6eaafbb6998e999467cf78a76e155ee00e372b14 ] IAD Register is yet readable trough the "iad" sys file. A write to the "iad" sys file enables or disables the current measurement, but it was not possible to get the measured value by reading it. Fix: %u in snprintf for unsigned values (vdd and vad) Fix: Avoid possibles overflows (Usage of the 'count' variables) Signed-off-by: Julien Folly Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d11d985d0a8285cc308a61c2464ad68e8e1f4ff8 Author: Wenwen Wang Date: Wed Oct 10 18:38:28 2018 -0500 misc: mic: fix a DMA pool free failure [ Upstream commit 6b995f4eec34745f6cb20d66d5277611f0b3c3fa ] In _scif_prog_signal(), the boolean variable 'x100' is used to indicate whether the MIC Coprocessor is X100. If 'x100' is true, the status descriptor will be used to write the value to the destination. Otherwise, a DMA pool will be allocated for this purpose. Specifically, if the DMA pool is allocated successfully, two memory addresses will be returned. One is for the CPU and the other is for the device to access the DMA pool. The former is stored to the variable 'status' and the latter is stored to the variable 'src'. After the allocation, the address in 'src' is saved to 'status->src_dma_addr', which is actually in the DMA pool, and 'src' is then modified. Later on, if an error occurs, the execution flow will transfer to the label 'dma_fail', which will check 'x100' and free up the allocated DMA pool if 'x100' is false. The point here is that 'status->src_dma_addr' is used for freeing up the DMA pool. As mentioned before, 'status->src_dma_addr' is in the DMA pool. And thus, the device is able to modify this data. This can potentially cause failures when freeing up the DMA pool because of the modified device address. This patch avoids the above issue by using the variable 'src' (with necessary calculation) to free up the DMA pool. Signed-off-by: Wenwen Wang Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a2204a2955544d140689a639a236a00ee69dd4ac Author: Duncan Laurie Date: Fri Oct 12 10:04:45 2018 -0600 gsmi: Fix bug in append_to_eventlog sysfs handler [ Upstream commit 655603de68469adaff16842ac17a5aec9c9ce89b ] The sysfs handler should return the number of bytes consumed, which in the case of a successful write is the entire buffer. Also fix a bug where param.data_len was being set to (count - (2 * sizeof(u32))) instead of just (count - sizeof(u32)). The latter is correct because we skip over the leading u32 which is our param.type, but we were also incorrectly subtracting sizeof(u32) on the line where we were actually setting param.data_len: param.data_len = count - sizeof(u32); This meant that for our example event.kernel_software_watchdog with total length 10 bytes, param.data_len was just 2 prior to this change. To test, successfully append an event to the log with gsmi sysfs. This sample event is for a "Kernel Software Watchdog" > xxd -g 1 event.kernel_software_watchdog 0000000: 01 00 00 00 ad de 06 00 00 00 > cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog > mosys eventlog list | tail -1 14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog Signed-off-by: Duncan Laurie Reviewed-by: Vadim Bendebury Reviewed-by: Stefan Reinauer Signed-off-by: Furquan Shaikh Tested-by: Furquan Shaikh Reviewed-by: Aaron Durbin Reviewed-by: Justin TerAvest [zwisler: updated changelog for 2nd bug fix and upstream] Signed-off-by: Ross Zwisler Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc08097f261966ad18071383f01c16f0ce1d839c Author: Nikolay Borisov Date: Thu Sep 13 11:35:10 2018 +0300 btrfs: handle error of get_old_root [ Upstream commit 315bed43fea532650933e7bba316a7601d439edf ] In btrfs_search_old_slot get_old_root is always used with the assumption it cannot fail. However, this is not true in rare circumstance it can fail and return null. This will lead to null point dereference when the header is read. Fix this by checking the return value and properly handling NULL by setting ret to -EIO and returning gracefully. Coverity-id: 1087503 Signed-off-by: Nikolay Borisov Reviewed-by: Lu Fengqi Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1b49c453a5645f483cd6b7733919a36f9c492f98 Author: Su Yue Date: Wed Sep 5 11:07:33 2018 +0800 btrfs: defrag: use btrfs_mod_outstanding_extents in cluster_pages_for_defrag [ Upstream commit 28c4a3e21ad030d7571ee9b1b246a5cbfd886627 ] Since commit 8b62f87bad9c ("Btrfs: rework outstanding_extents"), manual operations of outstanding_extent in btrfs_inode are replaced by btrfs_mod_outstanding_extents(). The one in cluster_pages_for_defrag seems to be lost, so replace it of btrfs_mod_outstanding_extents(). Fixes: 8b62f87bad9c ("Btrfs: rework outstanding_extents") Signed-off-by: Su Yue Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9325e8f4688ce4df65dc9c1b4698f75f3ab9a515 Author: Honghui Zhang Date: Mon Oct 15 16:08:53 2018 +0800 PCI: mediatek: Fix class type for MT7622 to PCI_CLASS_BRIDGE_PCI [ Upstream commit a7f172ab6a8e755e60311f27512034b0441ef421 ] commit 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class type for MT7622") erroneously set the class type for MT7622 to PCI_CLASS_BRIDGE_HOST. The PCIe controller of MT7622 integrates a Root Port that has type 1 configuration space header and related bridge windows. The HW default value of this bridge's class type is invalid. Fix its class type and set it to PCI_CLASS_BRIDGE_PCI to match the hardware implementation. Fixes: 101c92dc80c8 ("PCI: mediatek: Set up vendor ID and class type for MT7622") Signed-off-by: Honghui Zhang [lorenzo.pieralisi@arm.com: reworked the commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Ryder Lee Signed-off-by: Sasha Levin commit dfffae314a0259452488917d3aa162b5291e6343 Author: Chaotian Jing Date: Sat Oct 13 15:20:47 2018 +0800 mmc: mediatek: fix cannot receive new request when msdc_cmd_is_ready fail [ Upstream commit f38a9774ddde9d79b3487dd888edd8b8623552af ] when msdc_cmd_is_ready return fail, the req_timeout work has not been inited and cancel_delayed_work() will return false, then, the request return directly and never call mmc_request_done(). so need call mod_delayed_work() before msdc_cmd_is_ready() Signed-off-by: Chaotian Jing Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e2c158f5852295be92473b3b36b163e1935a97d2 Author: Chaotian Jing Date: Sat Oct 13 15:20:46 2018 +0800 mmc: mediatek: fill the actual clock for mmc debugfs [ Upstream commit 56f6cbbed0463f1c78d602b17c315916cc1cd238 ] as the mmc core layer has the mmc->actual_clock, so fill it and drop msdc_host->sclk. Signed-off-by: Chaotian Jing Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e3fa491211c405ac5a3ce0c8171e2511ed847a92 Author: Sergei Shtylyov Date: Fri Oct 12 22:48:22 2018 +0300 spi: sh-msiof: fix deferred probing [ Upstream commit f34c6e6257aa477cdfe7e9bbbecd3c5648ecda69 ] Since commit 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") platform_get_irq() can return -EPROBE_DEFER. However, the driver overrides an error returned by that function with -ENOENT which breaks the deferred probing. Propagate upstream an error code returned by platform_get_irq() and remove the bogus "platform" from the error message, while at it... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Signed-off-by: Sergei Shtylyov Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2cd0b70c55b0e71f578134510107d002d52ee235 Author: Jens Axboe Date: Sun Oct 14 13:20:48 2018 -0600 cdrom: don't attempt to fiddle with cdo->capability [ Upstream commit 8f94004e2a51a3ea195cf3447eb5d5906f36d8b3 ] We can't modify cdo->capability as it is defined as a const. Change the modification hack to just WARN_ON_ONCE() if we hit any of the invalid combinations. This fixes a regression for pcd, which doesn't work after the constify patch. Fixes: 853fe1bf7554 ("cdrom: Make device operations read-only") Tested-by: Ondrej Zary Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0c5c34c1aaf3651fc4271a642b70a39b3729a5bd Author: Jens Axboe Date: Thu Oct 11 14:56:14 2018 -0600 skd: fixup usage of legacy IO API [ Upstream commit 6d1f9dfde7343c4ebfb8f84dcb333af571bb3b22 ] We need to be using the mq variant of request requeue here. Fixes: ca33dd92968b ("skd: Convert to blk-mq") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 196b007ac0a6060f20ba9383dc6c98b827def052 Author: Carl Huang Date: Thu Oct 11 15:55:26 2018 +0800 ath10k: allocate small size dma memory in ath10k_pci_diag_write_mem [ Upstream commit 0738b4998c6d1caf9ca2447b946709a7278c70f1 ] ath10k_pci_diag_write_mem may allocate big size of the dma memory based on the parameter nbytes. Take firmware diag download as example, the biggest size is about 500K. In some systems, the allocation is likely to fail because it can't acquire such a large contiguous dma memory. The fix is to allocate a small size dma memory. In the loop, driver copies the data to the allocated dma memory and writes to the destination until all the data is written. Tested with QCA6174 PCI with firmware-6.bin_WLAN.RM.4.4.1-00119-QCARMSWP-1, this also affects QCA9377 PCI. Signed-off-by: Carl Huang Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 17fbe3c91ad48eb43247cd372e5a0af73b8a6113 Author: Rakesh Pillai Date: Tue Oct 2 23:33:13 2018 +0530 ath10k: set probe request oui during driver start [ Upstream commit f1157695c527d4ee949ac83f743f80107751a70c ] Currently the wmi command for setting probe request oui, needed for mac randomization, is sent during the mac register. At this time, during the driver init the wmi has already been detached. This can cause unexpected behavior since the firmware is already down and the wmi has been detached. Send the wmi command for setting probe request oui during the driver start. This will make sure that the firmware is started and wmi is initialized before we send this command. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: 60e1d0fb290197fe505dff6e4e3b7e4d258dbf60 Signed-off-by: Rakesh Pillai Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 8111f99f7c4478370953f3d62ac298329e050d23 Author: Ali MJ Al-Nasrawy Date: Wed Oct 3 19:21:39 2018 +0300 brcmsmac: AP mode: update beacon when TIM changes [ Upstream commit 2258ee58baa554609a3cc3996276e4276f537b6d ] Beacons are not updated to reflect TIM changes. This is not compliant with power-saving client stations as the beacons do not have valid TIM and can cause the network to stall at random occasions and to have highly variable latencies. Fix it by updating beacon templates on mac80211 set_tim callback. Addresses an issue described in: https://marc.info/?i=20180911163534.21312d08%20()%20manjaro Signed-off-by: Ali MJ Al-Nasrawy Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 20e42ddf6c1d4a769a87009d758b9d904046dac9 Author: Lorenzo Bianconi Date: Tue Oct 9 10:57:06 2018 +0200 mt76x0: phy: fix restore phase in mt76x0_phy_recalibrate_after_assoc [ Upstream commit 4df942733fd26d9378a4a00619be348c771e0190 ] Fix restore value configured in MT_BBP(IBI, 9) register in mt76x0_phy_recalibrate_after_assoc routine. Fixes: 10de7a8b4ab9 ("mt76x0: phy files") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8cb568162524e6585bdcc08170525b1ffa0cce53 Author: Felix Fietkau Date: Mon Oct 8 10:39:24 2018 +0200 mt76: do not store aggregation sequence number for null-data frames [ Upstream commit 5155938d8a0fe0e0251435cae02539e81fb8e407 ] Fixes a rare corner case where a BlockAckReq might get the wrong sequence number. Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b95998fb6c500790fc4f13ae5feadac72cfa4e1d Author: Dan Carpenter Date: Sat Oct 13 13:28:43 2018 +0300 EDAC, thunderx: Fix memory leak in thunderx_l2c_threaded_isr() [ Upstream commit d8c27ba86a2fd806d3957e5a9b30e66dfca2a61d ] Fix memory leak in L2c threaded interrupt handler. [ bp: Rewrite commit message. ] Fixes: 41003396f932 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver") Signed-off-by: Dan Carpenter Signed-off-by: Borislav Petkov CC: David Daney CC: Jan Glauber CC: Mauro Carvalho Chehab CC: Sergey Temerkhanov CC: linux-edac Link: http://lkml.kernel.org/r/20181013102843.GG16086@mwanda Signed-off-by: Sasha Levin commit 97aab1a43a2fbefdd863db2fd794bcf4a2edf273 Author: Sam Bobroff Date: Wed Sep 12 11:23:22 2018 +1000 powerpc/eeh: Fix use of EEH_PE_KEEP on wrong field [ Upstream commit 473af09b56dc4be68e4af33220ceca6be67aa60d ] eeh_add_to_parent_pe() sometimes removes the EEH_PE_KEEP flag, but it incorrectly removes it from pe->type, instead of pe->state. However, rather than clearing it from the correct field, remove it. Inspection of the code shows that it can't ever have had any effect (even if it had been cleared from the correct field), because the field is never tested after it is cleared by the statement in question. The clear statement was added by commit 807a827d4e74 ("powerpc/eeh: Keep PE during hotplug"), but it didn't explain why it was necessary. Signed-off-by: Sam Bobroff Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit bd2a7e53cd6e246ff469761bddc21c04d8d3d9a8 Author: Sam Bobroff Date: Wed Sep 12 11:23:21 2018 +1000 powerpc/eeh: Fix null deref for devices removed during EEH [ Upstream commit bcbe3730531239abd45ab6c6af4a18078b37dd47 ] If a device is removed during EEH processing (either by a driver's handler or as part of recovery), it can lead to a null dereference in eeh_pe_report_edev(). To handle this, skip devices that have been removed. Signed-off-by: Sam Bobroff Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 16e4657a1d2542dba2fce2c91ace742e2e47f6e7 Author: Joel Stanley Date: Wed Oct 10 13:15:22 2018 +1030 powerpc/boot: Disable vector instructions [ Upstream commit e8e132e6885962582784b6fa16a80d07ea739c0f ] This will avoid auto-vectorisation when building with higher optimisation levels. We don't know if the machine can support VSX and even if it's present it's probably not going to be enabled at this point in boot. These flag were both added prior to GCC 4.6 which is the minimum compiler version supported by upstream, thanks to Segher for the details. Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 5346c840373348deb53bb2977ffb6b340770d201 Author: Joel Stanley Date: Wed Oct 10 09:58:03 2018 +1030 powerpc/boot: Fix opal console in boot wrapper [ Upstream commit 1a855eaccf353f7ed1d51a3d4b3af727ccbd81ca ] As of commit 10c77dba40ff ("powerpc/boot: Fix build failure in 32-bit boot wrapper") the opal code is hidden behind CONFIG_PPC64_BOOT_WRAPPER, but the boot wrapper avoids include/linux, so it does not get the normal Kconfig flags. We can drop the guard entirely as in commit f8e8e69cea49 ("powerpc/boot: Only build OPAL code when necessary") the makefile only includes opal.c in the build if CONFIG_PPC64_BOOT_WRAPPER is set. Fixes: 10c77dba40ff ("powerpc/boot: Fix build failure in 32-bit boot wrapper") Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 4505cff2ef4a6df512bf329c02fc73ffbead23d6 Author: Dan Carpenter Date: Mon Oct 1 19:44:58 2018 +0300 powerpc: Fix signedness bug in update_flash_db() [ Upstream commit 014704e6f54189a203cc14c7c0bb411b940241bc ] The "count < sizeof(struct os_area_db)" comparison is type promoted to size_t so negative values of "count" are treated as very high values and we accidentally return success instead of a negative error code. This doesn't really change runtime much but it fixes a static checker warning. Signed-off-by: Dan Carpenter Acked-by: Geoff Levand Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 93b943c0602f98999a274ec2c09a98771d54e134 Author: Al Viro Date: Wed Sep 12 20:57:18 2018 -0400 synclink_gt(): fix compat_ioctl() [ Upstream commit 27230e51349fde075598c1b59d15e1ff802f3f6e ] compat_ptr() for pointer-taking ones... Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 8d67a4ecb4735292427fc54fcb604328122aa0a6 Author: Al Viro Date: Wed Sep 12 20:53:46 2018 -0400 pty: fix compat ioctls [ Upstream commit 50f45326afab723df529eca54095e2feac24da2d ] pointer-taking ones need compat_ptr(); int-taking one doesn't. Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit fa3fe5f442ab54662458489212c6c781c5408bd8 Author: Andreas Gruenbacher Date: Thu Sep 27 15:30:25 2018 +0100 gfs2: Fix marking bitmaps non-full [ Upstream commit ec23df2b0cf3e1620f5db77972b7fb735f267eff ] Reservations in gfs can span multiple gfs2_bitmaps (but they won't span multiple resource groups). When removing a reservation, we want to clear the GBF_FULL flags of all involved gfs2_bitmaps, not just that of the first bitmap. Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Reviewed-by: Steven Whitehouse Signed-off-by: Sasha Levin commit 26a4c6a562ceb419e42cd5b0fa05752b8ff3db60 Author: Alan Douglas Date: Thu Oct 11 17:15:54 2018 +0100 PCI: cadence: Write MSI data with 32bits [ Upstream commit e81e36a96bb56f243b5ac1d114c37c086761595b ] According to the PCIe specification, although the MSI data is only 16bits, the upper 16bits should be written as 0. Use writel instead of writew when writing the MSI data to the host. Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller") Signed-off-by: Alan Douglas Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit ca71f9c8adc2f61246158a1bdc9cd5e21db52773 Author: Gustavo A. R. Silva Date: Wed Oct 10 17:13:13 2018 +0200 pinctrl: madera: Fix uninitialized variable bug in madera_mux_set_mux [ Upstream commit 4fe81669df50889ff1072c030c59df5f1fa6534e ] There is a potential execution path in which variable *ret* is checked in an IF statement, and then its value is used to report an error at line 659 without being properly initialized previously: 659 if (ret) 660 dev_err(priv->dev, "Failed to write to 0x%x (%d)\n", reg, ret); Fix this by initializing variable *ret* to 0 in order to avoid unpredictable or unintended results. Addresses-Coverity-ID: 1471969 ("Uninitialized scalar variable") Fixes: 218d72a77b0b ("pinctrl: madera: Add driver for Cirrus Logic Madera codecs") Signed-off-by: Gustavo A. R. Silva Acked-by: Charles Keepax Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4465a916eaa733c0dd369a108a4c0c349bfcc013 Author: Sergey Senozhatsky Date: Wed Oct 10 20:33:08 2018 +0900 printk: fix integer overflow in setup_log_buf() [ Upstream commit d2130e82e9454304e9b91ba9da551b5989af8c27 ] The way we calculate logbuf free space percentage overflows signed integer: int free; free = __LOG_BUF_LEN - log_next_idx; pr_info("early log buf free: %u(%u%%)\n", free, (free * 100) / __LOG_BUF_LEN); We support LOG_BUF_LEN of up to 1<<25 bytes. Since setup_log_buf() is called during early init, logbuf is mostly empty, so __LOG_BUF_LEN - log_next_idx is close to 1<<25. Thus when we multiply it by 100, we overflow signed integer value range: 100 is 2^6 + 2^5 + 2^2. Example, booting with LOG_BUF_LEN 1<<25 and log_buf_len=2G boot param: [ 0.075317] log_buf_len: -2147483648 bytes [ 0.075319] early log buf free: 33549896(-28%) Make "free" unsigned integer and use appropriate printk() specifier. Link: http://lkml.kernel.org/r/20181010113308.9337-1-sergey.senozhatsky@gmail.com To: Steven Rostedt Cc: linux-kernel@vger.kernel.org Cc: Sergey Senozhatsky Signed-off-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 90d73768ddb6eac2df86c60072fbfe4d87e1d051 Author: Sergey Senozhatsky Date: Tue Oct 2 11:38:35 2018 +0900 printk: lock/unlock console only for new logbuf entries [ Upstream commit 3ac37a93fa9217e576bebfd4ba3e80edaaeb2289 ] Prior to commit 5c2992ee7fd8a29 ("printk: remove console flushing special cases for partial buffered lines") we would do console_cont_flush() for each pr_cont() to print cont fragments, so console_unlock() would actually print data: pr_cont(); console_lock(); console_unlock() console_cont_flush(); // print cont fragment ... pr_cont(); console_lock(); console_unlock() console_cont_flush(); // print cont fragment We don't do console_cont_flush() anymore, so when we do pr_cont() console_unlock() does nothing (unless we flushed the cont buffer): pr_cont(); console_lock(); console_unlock(); // noop ... pr_cont(); console_lock(); console_unlock(); // noop ... pr_cont(); cont_flush(); console_lock(); console_unlock(); // print data We also wakeup klogd purposelessly for pr_cont() output - un-flushed cont buffer is not stored in log_buf; there is nothing to pull. Thus we can console_lock()/console_unlock()/wake_up_klogd() only when we know that we log_store()-ed a message and there is something to print to the consoles/syslog. Link: http://lkml.kernel.org/r/20181002023836.4487-3-sergey.senozhatsky@gmail.com To: Steven Rostedt Cc: Andrew Morton Cc: Dmitriy Vyukov Cc: Tetsuo Handa Cc: Tejun Heo Cc: Peter Zijlstra Cc: LKML Cc: Sergey Senozhatsky Signed-off-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 8888689bd43356f17750992e3723e3271a6abeee Author: Michael Schupikov Date: Sun Oct 7 13:58:10 2018 +0200 crypto: testmgr - fix sizeof() on COMP_BUF_SIZE [ Upstream commit 22a8118d329334833cd30f2ceb36d28e8cae8a4f ] After allocation, output and decomp_output both point to memory chunks of size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using sizeof(COMP_BUF_SIZE) as parameter to memset(), because sizeof(COMP_BUF_SIZE) provides the size of the constant and not the size of allocated memory. Instead, the whole allocated memory is meant to be zeroed out. Use COMP_BUF_SIZE as parameter to memset() directly in order to accomplish this. Fixes: 336073840a872 ("crypto: testmgr - Allow different compression results") Signed-off-by: Michael Schupikov Reviewed-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3757657af27ea8314c05f78dbae3105d2b40ed29 Author: Takashi Sakamoto Date: Fri Oct 12 14:25:22 2018 +0900 ALSA: isight: fix leak of reference to firewire unit in error path of .probe callback [ Upstream commit 51e68fb0929c29e47e9074ca3e99ffd6021a1c5a ] In some error paths, reference count of firewire unit is not decreased. This commit fixes the bug. Fixes: 5b14ec25a79b('ALSA: firewire: release reference count of firewire unit in .remove callback of bus driver') Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 49a9643b5e8d305876f8de52af7946379c77033d Author: Adrian Bunk Date: Wed Feb 13 15:59:38 2019 +0200 mwifiex: Fix NL80211_TX_POWER_LIMITED [ Upstream commit 65a576e27309120e0621f54d5c81eb9128bd56be ] NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC, which is the opposite of what should happen and can cause nasty regulatory problems. if/else converted to a switch without default to make gcc warn on unhandled enum values. Signed-off-by: Adrian Bunk Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit e80e88ef6057c7947409bda9898387d25e54aaa9 Author: Chris Wilson Date: Mon Nov 11 13:32:03 2019 +0000 drm/i915/userptr: Try to acquire the page lock around set_page_dirty() commit 2d691aeca4aecbb8d0414a777a46981a8e142b05 upstream. set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). However, following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012 Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: cb6d7c7dc7ff ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: 505a8ec7e11a ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"") References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers") Signed-off-by: Chris Wilson Cc: Lionel Landwerlin Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk (cherry picked from commit 0d4bbe3d407f79438dc4f87943db21f7134cfc65) Signed-off-by: Joonas Lahtinen (cherry picked from commit cee7fb437edcdb2f9f8affa959e274997f5dca4d) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit a0ee03bb5269b336f9d75f507f59dbcd83397fa1 Author: Chris Wilson Date: Sat Nov 9 10:53:56 2019 +0000 drm/i915/pmu: "Frequency" is reported as accumulated cycles commit add3eeed3683e2636ef524db48e1a678757c8e96 upstream. We report "frequencies" (actual-frequency, requested-frequency) as the number of accumulated cycles so that the average frequency over that period may be determined by the user. This means the units we report to the user are Mcycles (or just M), not MHz. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20191109105356.5273-1-chris@chris-wilson.co.uk (cherry picked from commit e88866ef02851c88fe95a4bb97820b94b4d46f36) Signed-off-by: Joonas Lahtinen (cherry picked from commit a7d87b70d6da96c6772e50728c8b4e78e4cbfd55) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 8a67fbf6597122c4a5e2c48716bc441364357eef Author: Evan Quan Date: Thu Nov 14 15:30:39 2019 +0800 drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs commit 355d991cb6ff6ae76b5e28b8edae144124c730e4 upstream. Otherwise, the error message prompted will confuse user. Signed-off-by: Evan Quan Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e8d355befc4220a6f15c8d75c76858f2eb36611d Author: Andrey Ryabinin Date: Thu Nov 21 17:54:01 2019 -0800 mm/ksm.c: don't WARN if page is still mapped in remove_stable_node() commit 9a63236f1ad82d71a98aa80320b6cb618fb32f44 upstream. It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in remove_stable_node() when it races with __mmput() and squeezes in between ksm_exit() and exit_mmap(). WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150 Call Trace: remove_all_stable_nodes+0x12b/0x330 run_store+0x4ef/0x7b0 kernfs_fop_write+0x200/0x420 vfs_write+0x154/0x450 ksys_write+0xf9/0x1d0 do_syscall_64+0x99/0x510 entry_SYSCALL_64_after_hwframe+0x49/0xbe Remove the warning as there is nothing scary going on. Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com Fixes: cbf86cfe04a6 ("ksm: remove old stable nodes more thoroughly") Signed-off-by: Andrey Ryabinin Acked-by: Hugh Dickins Cc: Andrea Arcangeli Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b28da9da6e51544f7e876ed6892f30b75c926742 Author: Joseph Qi Date: Thu Nov 21 17:53:52 2019 -0800 Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()" commit 94b07b6f9e2e996afff7395de6b35f34f4cb10bf upstream. This reverts commit 56e94ea132bb5c2c1d0b60a6aeb34dcb7d71a53d. Commit 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") introduces a regression that fail to create directory with mount option user_xattr and acl. Actually the reported NULL pointer dereference case can be correctly handled by loc->xl_ops->xlo_add_entry(), so revert it. Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com Fixes: 56e94ea132bb ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") Signed-off-by: Joseph Qi Reported-by: Thomas Voegtle Acked-by: Changwei Ge Cc: Jia-Ju Bai Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 67380639dfdbb6be15563b4973785d2bd4bc8f8a Author: Laurent Vivier Date: Thu Nov 14 13:25:48 2019 +0100 virtio_console: allocate inbufs in add_port() only if it is needed commit d791cfcbf98191122af70b053a21075cb450d119 upstream. When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 kernel error: virtio-ports vport2p2: Error allocating inbufs qemu error: virtio-serial-bus: Guest failure in adding port 2 for device \ virtio-serial0.0 This happens because buffers for the in_vq are allocated when the port is added but are not released when the port is unplugged. They are only released when virtconsole is removed (see a7a69ec0d8e4) To avoid the problem and to be symmetric, we could allocate all the buffers in init_vqs() as they are released in remove_vqs(), but it sounds like a waste of memory. Rather than that, this patch changes add_port() logic to ignore ENOSPC error in fill_queue(), which means queue has already been filled. Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset") Cc: mst@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Laurent Vivier Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 65d153c8ed6505075740f005122d01298f6e474a Author: Sun Ke Date: Tue Nov 19 14:09:11 2019 +0800 nbd:fix memory leak in nbd_get_socket() commit dff10bbea4be47bdb615b036c834a275b7c68133 upstream. Before returning NULL, put the sock first. Cc: stable@vger.kernel.org Fixes: cf1b2326b734 ("nbd: verify socket is supported during setup") Reviewed-by: Josef Bacik Reviewed-by: Mike Christie Signed-off-by: Sun Ke Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 036588ec6888ad085c9a2edc5c0bac12297f5e35 Author: Laura Abbott Date: Tue Nov 12 17:10:26 2019 -0500 tools: gpio: Correctly add make dependencies for gpio_utils commit 0161a94e2d1c713bd34d72bc0239d87c31747bf7 upstream. gpio tools fail to build correctly with make parallelization: $ make -s -j24 ld: gpio-utils.o: file not recognized: file truncated make[1]: *** [/home/labbott/linux_upstream/tools/build/Makefile.build:145: lsgpio-in.o] Error 1 make: *** [Makefile:43: lsgpio-in.o] Error 2 make: *** Waiting for unfinished jobs.... This is because gpio-utils.o is used across multiple targets. Fix this by making gpio-utios.o a proper dependency. Cc: Signed-off-by: Laura Abbott Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 7cb8ee734c18eec586c8ed061696b6211a7f158c Author: Thierry Reding Date: Fri Nov 8 17:07:46 2019 +0100 gpio: max77620: Fixup debounce delays commit b0391479ae04dfcbd208b9571c375064caad9a57 upstream. When converting milliseconds to microseconds in commit fffa6af94894 ("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps were introduced between the various ranges supported by the controller. Fix this by changing the start of each range to the value immediately following the end of the previous range. This way a debounce time of, say 8250 us will translate into 16 ms instead of returning an -EINVAL error. Typically the debounce delay is only ever set through device tree and specified in milliseconds, so we can never really hit this issue because debounce times are always a multiple of 1000 us. The only notable exception for this is drivers/mmc/host/mmc-spi.c where the CD GPIO is requested, which passes a 1 us debounce time. According to a comment preceeding that code this should actually be 1 ms (i.e. 1000 us). Reported-by: Pavel Machek Signed-off-by: Thierry Reding Acked-by: Pavel Machek Cc: Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 70d594d17ebb5c4e98bba6da2ec665fdbf82b0cb Author: Stefano Garzarella Date: Tue Jul 30 17:43:33 2019 +0200 vhost/vsock: split packets to send using multiple buffers commit 6dbd3e66e7785a2f055bf84d98de9b8fd31ff3f5 upstream. If the packets to sent to the guest are bigger than the buffer available, we can split them, using multiple buffers and fixing the length in the packet header. This is safe since virtio-vsock supports only stream sockets. Signed-off-by: Stefano Garzarella Reviewed-by: Stefan Hajnoczi Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 48bc34efbc655e9f569c1620d13fc7d3182d6f2d Author: Maor Gottlieb Date: Thu Sep 5 09:56:10 2019 +0300 net/mlx5: Fix auto group size calculation [ Upstream commit 97fd8da281f80e7e69e0114bc906575734d4dfaf ] Once all the large flow groups (defined by the user when the flow table is created - max_num_groups) were created, then all the following new flow groups will have only one flow table entry, even though the flow table has place to larger groups. Fix the condition to prefer large flow group. Fixes: f0d22d187473 ("net/mlx5_core: Introduce flow steering autogrouped flow table") Signed-off-by: Maor Gottlieb Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 28a4cc2b5d6fcf468adb615930ee3439f198dee2 Author: Eran Ben Elisha Date: Sun Nov 17 10:18:59 2019 +0200 net/mlxfw: Verify FSM error code translation doesn't exceed array size [ Upstream commit 30e9e0550bf693c94bc15827781fe42dd60be634 ] Array mlxfw_fsm_state_err_str contains value to string translation, when values are provided by mlxfw_dev. If value is larger than MLXFW_FSM_STATE_ERR_MAX, return "unknown error" as expected instead of reading an address than exceed array size. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Signed-off-by: Eran Ben Elisha Acked-by: Jiri Pirko Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 7c1a5381778288e4b4c18780916285ffa4d2ab77 Author: Roi Dayan Date: Wed Nov 13 14:42:00 2019 +0200 net/mlx5e: Fix set vf link state error flow [ Upstream commit 751021218f7e66ee9bbaa2be23056e447cd75ec4 ] Before this commit the ndo always returned success. Fix that. Fixes: 1ab2068a4c66 ("net/mlx5: Implement vports admin state backup/restore") Signed-off-by: Roi Dayan Reviewed-by: Vlad Buslov Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 1ff2a0f8692f48c1081554a4226cfd3913c0ff4f Author: Martin Habets Date: Thu Nov 21 17:52:15 2019 +0000 sfc: Only cancel the PPS workqueue if it exists [ Upstream commit 723eb53690041740a13ac78efeaf6804f5d684c9 ] The workqueue only exists for the primary PF. For other functions we hit a WARN_ON in kernel/workqueue.c. Fixes: 7c236c43b838 ("sfc: Add support for IEEE-1588 PTP") Signed-off-by: Martin Habets Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 13512a5eb818d6787433eee1d67877437f8c9f12 Author: Xin Long Date: Mon Nov 18 17:39:34 2019 +0800 net: sched: ensure opts_len <= IP_TUNNEL_OPTS_MAX in act_tunnel_key [ Upstream commit 4f0e97d070984d487df027f163e52bb72d1713d8 ] info->options_len is 'u8' type, and when opts_len with a value > IP_TUNNEL_OPTS_MAX, 'info->options_len = opts_len' will cast int to u8 and set a wrong value to info->options_len. Kernel crashed in my test when doing: # opts="0102:80:00800022" # for i in {1..99}; do opts="$opts,0102:80:00800022"; done # ip link add name geneve0 type geneve dstport 0 external # tc qdisc add dev eth0 ingress # tc filter add dev eth0 protocol ip parent ffff: \ flower indev eth0 ip_proto udp action tunnel_key \ set src_ip 10.0.99.192 dst_ip 10.0.99.193 \ dst_port 6081 id 11 geneve_opts $opts \ action mirred egress redirect dev geneve0 So we should do the similar check as cls_flower does, return error when opts_len > IP_TUNNEL_OPTS_MAX in tunnel_key_copy_opts(). Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key") Signed-off-by: Xin Long Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2ba6a4f5402e3ac972802178b6b2f1965fcd26a4 Author: Davide Caratti Date: Tue Nov 19 23:47:33 2019 +0100 net/sched: act_pedit: fix WARN() in the traffic path [ Upstream commit f67169fef8dbcc1ac6a6a109ecaad0d3b259002c ] when configuring act_pedit rules, the number of keys is validated only on addition of a new entry. This is not sufficient to avoid hitting a WARN() in the traffic path: for example, it is possible to replace a valid entry with a new one having 0 extended keys, thus causing splats in dmesg like: pedit BUG: index 42 WARNING: CPU: 2 PID: 4054 at net/sched/act_pedit.c:410 tcf_pedit_act+0xc84/0x1200 [act_pedit] [...] RIP: 0010:tcf_pedit_act+0xc84/0x1200 [act_pedit] Code: 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ac 00 00 00 48 8b 44 24 10 48 c7 c7 a0 c4 e4 c0 8b 70 18 e8 1c 30 95 ea <0f> 0b e9 a0 fa ff ff e8 00 03 f5 ea e9 14 f4 ff ff 48 89 58 40 e9 RSP: 0018:ffff888077c9f320 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffac2983a2 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888053927bec RBP: dffffc0000000000 R08: ffffed100a726209 R09: ffffed100a726209 R10: 0000000000000001 R11: ffffed100a726208 R12: ffff88804beea780 R13: ffff888079a77400 R14: ffff88804beea780 R15: ffff888027ab2000 FS: 00007fdeec9bd740(0000) GS:ffff888053900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffdb3dfd000 CR3: 000000004adb4006 CR4: 00000000001606e0 Call Trace: tcf_action_exec+0x105/0x3f0 tcf_classify+0xf2/0x410 __dev_queue_xmit+0xcbf/0x2ae0 ip_finish_output2+0x711/0x1fb0 ip_output+0x1bf/0x4b0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x180c/0x2430 sock_sendmsg+0xdb/0x110 __sys_sendto+0x257/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0xa5/0x4e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fdeeb72e993 Code: 48 8b 0d e0 74 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 0d d6 2c 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 4b cc 00 00 48 89 04 24 RSP: 002b:00007ffdb3de8a18 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055c81972b700 RCX: 00007fdeeb72e993 RDX: 0000000000000040 RSI: 000055c81972b700 RDI: 0000000000000003 RBP: 00007ffdb3dea130 R08: 000055c819728510 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 R13: 000055c81972b6c0 R14: 000055c81972969c R15: 0000000000000080 Fix this moving the check on 'nkeys' earlier in tcf_pedit_init(), so that attempts to install rules having 0 keys are always rejected with -EINVAL. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f6de5cf5390d62a563509873e41415061de1bcd Author: Dan Carpenter Date: Wed Nov 20 15:34:38 2019 +0300 net: rtnetlink: prevent underflows in do_setvfinfo() [ Upstream commit d658c8f56ec7b3de8051a24afb25da9ba3c388c5 ] The "ivm->vf" variable is a u32, but the problem is that a number of drivers cast it to an int and then forget to check for negatives. An example of this is in the cxgb4 driver. drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 2890 static int cxgb4_mgmt_get_vf_config(struct net_device *dev, 2891 int vf, struct ifla_vf_info *ivi) ^^^^^^ 2892 { 2893 struct port_info *pi = netdev_priv(dev); 2894 struct adapter *adap = pi->adapter; 2895 struct vf_info *vfinfo; 2896 2897 if (vf >= adap->num_vfs) ^^^^^^^^^^^^^^^^^^^ 2898 return -EINVAL; 2899 vfinfo = &adap->vfinfo[vf]; ^^^^^^^^^^^^^^^^^^^^^^^^^^ There are 48 functions affected. drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:8435 hclge_set_vf_vlan_filter() warn: can 'vfid' underflow 's32min-2147483646' drivers/net/ethernet/freescale/enetc/enetc_pf.c:377 enetc_pf_set_vf_mac() warn: can 'vf' underflow 's32min-2147483646' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2899 cxgb4_mgmt_get_vf_config() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2960 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3019 cxgb4_mgmt_set_vf_rate() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3038 cxgb4_mgmt_set_vf_vlan() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:3086 cxgb4_mgmt_set_vf_link_state() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/chelsio/cxgb/cxgb2.c:791 get_eeprom() warn: can 'i' underflow 's32min-(-4),0,4-s32max' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:82 bnxt_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:164 bnxt_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:186 bnxt_get_vf_config() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:228 bnxt_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:264 bnxt_set_vf_vlan() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:293 bnxt_set_vf_bw() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c:333 bnxt_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2595 bnx2x_vf_op_prep() warn: can 'vfidx' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2281 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2285 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2286 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2292 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c:2297 bnx2x_post_vf_bulletin() warn: can 'vf' underflow 's32min-63' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1832 qlcnic_sriov_set_vf_mac() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1864 qlcnic_sriov_set_vf_tx_rate() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:1937 qlcnic_sriov_set_vf_vlan() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2005 qlcnic_sriov_get_vf_config() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c:2036 qlcnic_sriov_set_vf_spoofchk() warn: can 'vf' underflow 's32min-254' drivers/net/ethernet/emulex/benet/be_main.c:1914 be_get_vf_config() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:1915 be_get_vf_config() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:1922 be_set_vf_tvt() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:1951 be_clear_vf_tvt() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:2063 be_set_vf_tx_rate() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/emulex/benet/be_main.c:2091 be_set_vf_link_state() warn: can 'vf' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:2609 ice_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3050 ice_get_vf_cfg() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3103 ice_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3181 ice_set_vf_mac() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3237 ice_set_vf_trust() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c:3286 ice_set_vf_link_state() warn: can 'vf_id' underflow 's32min-65534' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3919 i40e_validate_vf() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:3957 i40e_ndo_set_vf_mac() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4104 i40e_ndo_set_vf_port_vlan() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4263 i40e_ndo_set_vf_bw() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4309 i40e_ndo_get_vf_config() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4371 i40e_ndo_set_vf_link_state() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4441 i40e_ndo_set_vf_spoofchk() warn: can 'vf_id' underflow 's32min-2147483646' drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:4504 i40e_ndo_set_vf_trust() warn: can 'vf_id' underflow 's32min-2147483646' Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ebcb0840a76b19c5cdf4fc58d71f02e771cafd1c Author: Tariq Toukan Date: Mon Nov 18 11:41:04 2019 +0200 net/mlx4_en: Fix wrong limitation for number of TX rings [ Upstream commit 2744bf42680f64ebf2ee8a00354897857c073331 ] XDP_TX rings should not be limited by max_num_tx_rings_p_up. To make sure total number of TX rings never exceed MAX_TX_RINGS, add similar check in mlx4_en_alloc_tx_queue_per_tc(), where a new value is assigned for num_up. Fixes: 7e1dc5e926d5 ("net/mlx4_en: Limit the number of TX rings") Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5408138df1dbe85f3986b2756ca998bcdd94d3a7 Author: Luigi Rizzo Date: Fri Nov 15 12:12:25 2019 -0800 net/mlx4_en: fix mlx4 ethtool -N insertion [ Upstream commit 34e59836565e36fade1464e054a3551c1a0364be ] ethtool expects ETHTOOL_GRXCLSRLALL to set ethtool_rxnfc->data with the total number of entries in the rx classifier table. Surprisingly, mlx4 is missing this part (in principle ethtool could still move forward and try the insert). Tested: compiled and run command: phh13:~# ethtool -N eth1 flow-type udp4 queue 4 Added rule with ID 255 Signed-off-by: Luigi Rizzo Reviewed-by: Tariq Toukan Signed-off-by: Greg Kroah-Hartman commit baa888ca02db84bdca59177fb0ebe33b3041ff80 Author: Petr Machata Date: Mon Nov 18 09:18:42 2019 +0200 mlxsw: spectrum_router: Fix determining underlay for a GRE tunnel [ Upstream commit 1fc1657775dc1b19e9ac1d46b4054ed8ae5d99ab ] The helper mlxsw_sp_ipip_dev_ul_tb_id() determines the underlay VRF of a GRE tunnel. For a tunnel without a bound device, it uses the same VRF that the tunnel is in. However in Linux, a GRE tunnel without a bound device uses the main VRF as the underlay. Fix the function accordingly. mlxsw further assumed that moving a tunnel to a different VRF could cause conflict in local tunnel endpoint address, which cannot be offloaded. However, the only way that an underlay could be changed by moving the tunnel device itself is if the tunnel device does not have a bound device. But in that case the underlay is always the main VRF, so there is no opportunity to introduce a conflict by moving such device. Thus this check constitutes a dead code, and can be removed, which do. Fixes: 6ddb7426a7d4 ("mlxsw: spectrum_router: Introduce loopback RIFs") Signed-off-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman