commit f11e30d6c8d6cf6c05b8a5ad54c34ad7136e98d6 Author: Alexandre Frade Date: Wed Apr 29 15:11:50 2020 -0300 Linux 5.4.36-xanmod1 Signed-off-by: Alexandre Frade commit 6f39ed74e2107e2d67730e329d472648483ce5f1 Merge: deb90c9a3f42 aa73bcc37686 Author: Alexandre Frade Date: Wed Apr 29 14:22:31 2020 -0300 Merge tag 'v5.4.36' into 5.4 This is the 5.4.36 stable release commit aa73bcc376865c23e61dcebd467697b527901be8 Author: Greg Kroah-Hartman Date: Wed Apr 29 16:33:25 2020 +0200 Linux 5.4.36 commit 44d9eb0ebe8fd04f46b18d10a18b2c543b379a0c Author: Christian Borntraeger Date: Wed Apr 15 15:21:01 2020 +0200 s390/mm: fix page table upgrade vs 2ndary address mode accesses commit 316ec154810960052d4586b634156c54d0778f74 upstream. A page table upgrade in a kernel section that uses secondary address mode will mess up the kernel instructions as follows: Consider the following scenario: two threads are sharing memory. On CPU1 thread 1 does e.g. strnlen_user(). That gets to old_fs = enable_sacf_uaccess(); len = strnlen_user_srst(src, size); and " la %2,0(%1)\n" " la %3,0(%0,%1)\n" " slgr %0,%0\n" " sacf 256\n" "0: srst %3,%2\n" in strnlen_user_srst(). At that point we are in secondary space mode, control register 1 points to kernel page table and instruction fetching happens via c1, rather than usual c13. Interrupts are not disabled, for obvious reasons. On CPU2 thread 2 does MAP_FIXED mmap(), forcing the upgrade of page table from 3-level to e.g. 4-level one. We'd allocated new top-level table, set it up and now we hit this: notify = 1; spin_unlock_bh(&mm->page_table_lock); } if (notify) on_each_cpu(__crst_table_upgrade, mm, 0); OK, we need to actually change over to use of new page table and we need that to happen in all threads that are currently running. Which happens to include the thread 1. IPI is delivered and we have static void __crst_table_upgrade(void *arg) { struct mm_struct *mm = arg; if (current->active_mm == mm) set_user_asce(mm); __tlb_flush_local(); } run on CPU1. That does static inline void set_user_asce(struct mm_struct *mm) { S390_lowcore.user_asce = mm->context.asce; OK, user page table address updated... __ctl_load(S390_lowcore.user_asce, 1, 1); ... and control register 1 set to it. clear_cpu_flag(CIF_ASCE_PRIMARY); } IPI is run in home space mode, so it's fine - insns are fetched using c13, which always points to kernel page table. But as soon as we return from the interrupt, previous PSW is restored, putting CPU1 back into secondary space mode, at which point we no longer get the kernel instructions from the kernel mapping. The fix is to only fixup the control registers that are currently in use for user processes during the page table update. We must also disable interrupts in enable_sacf_uaccess to synchronize the cr and thread.mm_segment updates against the on_each-cpu. Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode") Cc: stable@vger.kernel.org # 4.15+ Reported-by: Al Viro Reviewed-by: Gerald Schaefer References: CVE-2020-11884 Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 58b243cf27869c0dbe873ad6e36f0c3951801afc Author: Arnd Bergmann Date: Mon Dec 9 16:16:20 2019 +0100 compat: ARM64: always include asm-generic/compat.h commit 556d687a4ccd54ab50a721ddde42c820545effd9 upstream. In order to use compat_* type defininitions in device drivers outside of CONFIG_COMPAT, move the inclusion of asm-generic/compat.h ahead of the #ifdef. All other architectures already do this. Acked-by: Will Deacon Reviewed-by: Ben Hutchings Signed-off-by: Arnd Bergmann Cc: Naresh Kamboju Signed-off-by: Greg Kroah-Hartman commit 3160e84abaf737de27b6935843db958c23dd2af9 Author: Christophe Leroy Date: Fri Apr 17 11:58:36 2020 +0000 powerpc/mm: Fix CONFIG_PPC_KUAP_DEBUG on PPC32 commit feb8e960d780e170e992a70491eec9dd68f4dbf2 upstream. CONFIG_PPC_KUAP_DEBUG is not selectable because it depends on PPC_32 which doesn't exists. Fixing it leads to a deadlock due to a vital register getting clobbered in _switch(). Change dependency to PPC32 and use r0 instead of r4 in _switch() Fixes: e2fb9f544431 ("powerpc/32: Prepare for Kernel Userspace Access Protection") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/540242f7d4573f7cdf1b3bf46bb35f743b2cd68f.1587124651.git.christophe.leroy@c-s.fr Signed-off-by: Greg Kroah-Hartman commit b48331b52a28a52d83c503e6b6cc584b824bf072 Author: Michael Ellerman Date: Sun Mar 1 22:17:38 2020 +1100 powerpc/kuap: PPC_KUAP_DEBUG should depend on PPC_KUAP commit 61da50b76b62fd815aa82d853bf82bf4f69568f5 upstream. Currently you can enable PPC_KUAP_DEBUG when PPC_KUAP is disabled, even though the former has not effect without the latter. Fix it so that PPC_KUAP_DEBUG can only be enabled when PPC_KUAP is enabled, not when the platform could support KUAP (PPC_HAVE_KUAP). Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200301111738.22497-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit c4606876164c66469cd784d98898ee2928b10583 Author: Michal Simek Date: Fri Apr 3 11:24:36 2020 +0200 Revert "serial: uartps: Register own uart console and driver structures" commit 18cc7ac8a28e28cd005c2475f52576cfe10cabfb upstream. This reverts commit 024ca329bfb9a948f76eaff3243e21b7e70182f2. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/1ee35667e36a8efddee381df5fe495ad65f4d15c.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit 02d32033b397364ec42431cf282fbd51ea16d2dc Author: Michal Simek Date: Fri Apr 3 11:24:35 2020 +0200 Revert "serial: uartps: Move Port ID to device data structure" commit 492cc08bc16c44e2e587362ada3f6269dee2be22 upstream. This reverts commit bed25ac0e2b6ab8f9aed2d20bc9c3a2037311800. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/eb0ec98fecdca9b79c1a3ac0c30c668b6973b193.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit bbc0423c89689da1907b5d49e381bfa5c4892dc0 Author: Michal Simek Date: Fri Apr 3 11:24:34 2020 +0200 Revert "serial: uartps: Change uart ID port allocation" commit 72d68197281e2ad313960504d10b0c41ff87fd55 upstream. This reverts commit ae1cca3fa3478be92948dbbcd722390272032ade. With setting up NR_PORTS to 16 to be able to use serial2 and higher aliases and don't loose functionality which was intended by these changes. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/a94931b65ce0089f76fb1fe6b446a08731bff754.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit f7504efa6bf7594b3b92819eaec92f4a6fb9c9ab Author: Michal Simek Date: Fri Apr 3 11:24:33 2020 +0200 Revert "serial: uartps: Do not allow use aliases >= MAX_UART_INSTANCES" commit 91c9dfa25c7f95b543c280e0edf1fd8de6e90985 upstream. This reverts commit 2088cfd882d0403609bdf426e9b24372fe1b8337. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/dac3898e3e32d963f357fb436ac9a7ac3cbcf933.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit 3e64d4db7b105ce53b7d2d9cd8cca021b120348e Author: Michal Simek Date: Fri Apr 3 11:24:32 2020 +0200 Revert "serial: uartps: Fix error path when alloc failed" commit b6fd2dbbd649b89a3998528994665ded1e3fbf7f upstream. This reverts commit 32cf21ac4edd6c0d5b9614368a83bcdc68acb031. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/46cd7f039db847c08baa6508edd7854f7c8ff80f.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit 6fcbf58b115c577eedafbd5c30e7d55404b52cae Author: Michal Simek Date: Fri Apr 3 11:24:31 2020 +0200 Revert "serial: uartps: Use the same dynamic major number for all ports" commit 8da1a3940da4b0e82848ec29b835486890bc9232 upstream. This reverts commit ab262666018de6f4e206b021386b93ed0c164316. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/14a565fc1e14a5ec6cc6a6710deb878ae8305f22.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit 1bb43b4d8c32c6d2ffc005206a83b8df04314f42 Author: Michal Simek Date: Fri Apr 3 11:24:30 2020 +0200 Revert "serial: uartps: Fix uartps_major handling" commit 2e01911b7cf7aa07a304a809eca1b11a4bd35859 upstream. This reverts commit 5e9bd2d70ae7c00a95a22994abf1eef728649e64. As Johan says, this driver needs a lot more work and these changes are only going in the wrong direction: https://lkml.kernel.org/r/20190523091839.GC568@localhost Reported-by: Johan Hovold Signed-off-by: Michal Simek Cc: stable Link: https://lore.kernel.org/r/310999ab5342f788a7bc1b0e68294d4f052cad07.1585905873.git.michal.simek@xilinx.com Signed-off-by: Greg Kroah-Hartman commit 3af0614df15c1c1fbfafed4888f12d76a7b044e1 Author: Kazuhiro Fujita Date: Fri Mar 27 18:17:28 2020 +0000 serial: sh-sci: Make sure status register SCxSR is read in correct sequence commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream. For SCIF and HSCIF interfaces the SCxSR register holds the status of data that is to be read next from SCxRDR register, But where as for SCIFA and SCIFB interfaces SCxSR register holds status of data that is previously read from SCxRDR register. This patch makes sure the status register is read depending on the port types so that errors are caught accordingly. Cc: Signed-off-by: Kazuhiro Fujita Signed-off-by: Hao Bui Signed-off-by: KAZUMI HARADA Signed-off-by: Lad Prabhakar Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com Signed-off-by: Greg Kroah-Hartman commit fceab238c534eca02253c01f3bd5db391acd47b0 Author: Mathias Nyman Date: Tue Apr 21 17:08:22 2020 +0300 xhci: Don't clear hub TT buffer on ep0 protocol stall commit 8f97250c21f0cf36434bf5b7ddf4377406534cd1 upstream. The default control endpoint ep0 can return a STALL indicating the device does not support the control transfer requests. This is called a protocol stall and does not halt the endpoint. xHC behaves a bit different. Its internal endpoint state will always be halted on any stall, even if the device side of the endpiont is not halted. So we do need to issue the reset endpoint command to clear the xHC host intenal endpoint halt state, but should not request the HS hub to clear the TT buffer unless device side of endpoint is halted. Clearing the hub TT buffer at protocol stall caused ep0 to become unresponsive for some FS/LS devices behind HS hubs, and class drivers failed to set the interface due to timeout: usb 1-2.1: 1:1: usb_set_interface failed (-110) Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") Cc: # v5.3 Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200421140822.28233-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 54470b0bd16aabc05c1d5fe2037e7fadf7869c16 Author: Mathias Nyman Date: Tue Apr 21 17:08:21 2020 +0300 xhci: prevent bus suspend if a roothub port detected a over-current condition commit e9fb08d617bfae5471d902112667d0eeb9dee3c4 upstream. Suspending the bus and host controller while a port is in a over-current condition may halt the host. Also keep the roothub running if over-current is active. Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200421140822.28233-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f385e765ac93a8e264caccdda16e7611f3d06183 Author: Mathias Nyman Date: Tue Apr 21 17:08:20 2020 +0300 xhci: Fix handling halted endpoint even if endpoint ring appears empty commit 93ceaa808e8defc67ebca1396e2f42f812a2efc0 upstream. If a class driver cancels its only URB then the endpoint ring buffer will appear empty to the xhci driver. xHC hardware may still process cached TRBs, and complete with a STALL, halting the endpoint. This halted endpoint was not handled correctly by xhci driver as events on empty rings were all assumed to be spurious events. xhci driver refused to restart the ring with EP_HALTED flag set, so class driver was never informed the endpoint halted even if it queued new URBs. The host side of the endpoint needs to be reset, and dequeue pointer should be moved in order to clear the cached TRBs and resetart the endpoint. Small adjustments in finding the new dequeue pointer are needed to support the case of stall on an empty ring and unknown current TD. Cc: cc: Jeremy Compostella Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200421140822.28233-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8dbfb11452c0200260eed4227f658c1db66fa97f Author: Naoki Kiryu Date: Wed Apr 22 16:43:45 2020 +0200 usb: typec: altmode: Fix typec_altmode_get_partner sometimes returning an invalid pointer commit 0df9433fcae02215c8fd79690c134d535c7bb905 upstream. Before this commit, typec_altmode_get_partner would return a const struct typec_altmode * pointing to address 0x08 when to_altmode(adev)->partner was NULL. Add a check for to_altmode(adev)->partner being NULL to fix this. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1785972 Fixes: 5f54a85db5df ("usb: typec: Make sure an alt mode exist before getting its partner") Cc: stable@vger.kernel.org Signed-off-by: Naoki Kiryu Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20200422144345.43262-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman commit 740c938147830802ee567dc26e7d58e6ed34f63b Author: Badhri Jagan Sridharan Date: Thu Apr 2 14:59:47 2020 -0700 usb: typec: tcpm: Ignore CC and vbus changes in PORT_RESET change commit 901789745a053286e0ced37960d44fa60267b940 upstream. After PORT_RESET, the port is set to the appropriate default_state. Ignore processing CC changes here as this could cause the port to be switched into sink states by default. echo source > /sys/class/typec/port0/port_type Before: [ 154.528547] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [ 154.528560] CC1: 0 -> 0, CC2: 3 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 154.528564] state change PORT_RESET -> SNK_UNATTACHED After: [ 151.068814] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [ 151.072440] CC1: 3 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 151.172117] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 151.172136] pending state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED @ 870 ms [rev3 NONE_AMS] [ 152.060106] state change PORT_RESET_WAIT_OFF -> SRC_UNATTACHED [delayed 870 ms] [ 152.060118] Start toggling Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Heikki Krogerus Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20200402215947.176577-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 11c2089767cd033bf5bdbd06df875f907e32e9b2 Author: Udipto Goswami Date: Thu Apr 2 10:15:21 2020 +0530 usb: f_fs: Clear OS Extended descriptor counts to zero in ffs_data_reset() commit 1c2e54fbf1da5e5445a0ab132c862b02ccd8d230 upstream. For userspace functions using OS Descriptors, if a function also supplies Extended Property descriptors currently the counts and lengths stored in the ms_os_descs_ext_prop_{count,name_len,data_len} variables are not getting reset to 0 during an unbind or when the epfiles are closed. If the same function is re-bound and the descriptors are re-written, this results in those count/length variables to monotonically increase causing the VLA allocation in _ffs_func_bind() to grow larger and larger at each bind/unbind cycle and eventually fail to allocate. Fix this by clearing the ms_os_descs_ext_prop count & lengths to 0 in ffs_data_reset(). Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support") Cc: stable@vger.kernel.org Signed-off-by: Udipto Goswami Signed-off-by: Sriharsha Allenki Reviewed-by: Manu Gautam Link: https://lore.kernel.org/r/20200402044521.9312-1-sallenki@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit bf996950d8deaeabc84b0b6b88134a1222cce56a Author: Thinh Nguyen Date: Tue Mar 31 01:40:35 2020 -0700 usb: dwc3: gadget: Fix request completion check commit 49e0590e3a60e75b493e5df879e216e5073c7663 upstream. A request may not be completed because not all the TRBs are prepared for it. This happens when we run out of available TRBs. When some TRBs are completed, the driver needs to prepare the rest of the TRBs for the request. The check dwc3_gadget_ep_request_completed() shouldn't be checking the amount of data received but rather the number of pending TRBs. Revise this request completion check. Cc: stable@vger.kernel.org Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit a0f1f53ecd8d161d2e3d71a169b0971a1cbcefc4 Author: Xu Yilun Date: Tue Feb 25 14:07:18 2020 +0800 fpga: dfl: pci: fix return value of cci_pci_sriov_configure commit 3c2760b78f90db874401d97e3c17829e2e36f400 upstream. pci_driver.sriov_configure should return negative value on error and number of enabled VFs on success. But now the driver returns 0 on success. The sriov configure still works but will cause a warning message: XX VFs requested; only 0 enabled This patch changes the return value accordingly. Cc: stable@vger.kernel.org Signed-off-by: Xu Yilun Signed-off-by: Wu Hao Signed-off-by: Moritz Fischer Signed-off-by: Greg Kroah-Hartman commit 22432bcf066c1017a08a4c05883f4008b04ba03d Author: Oliver Neukum Date: Wed Apr 15 16:17:50 2020 +0200 UAS: fix deadlock in error handling and PM flushing work commit f6cc6093a729ede1ff5658b493237c42b82ba107 upstream. A SCSI error handler and block runtime PM must not allocate memory with GFP_KERNEL. Furthermore they must not wait for tasks allocating memory with GFP_KERNEL. That means that they cannot share a workqueue with arbitrary tasks. Fix this for UAS using a private workqueue. Signed-off-by: Oliver Neukum Fixes: f9dc024a2da1f ("uas: pre_reset and suspend: Fix a few races") Cc: stable Link: https://lore.kernel.org/r/20200415141750.811-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit e1b656677f7d0c759e50f6db2af9c5a3bd2db89e Author: Oliver Neukum Date: Wed Apr 15 16:17:49 2020 +0200 UAS: no use logging any details in case of ENODEV commit 5963dec98dc52d52476390485f07a29c30c6a582 upstream. Once a device is gone, the internal state does not matter anymore. There is no need to spam the logs. Signed-off-by: Oliver Neukum Cc: stable Fixes: 326349f824619 ("uas: add dead request list") Link: https://lore.kernel.org/r/20200415141750.811-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit f4d1cf2ef83caeab212e842fd238cb8353f59fa2 Author: Oliver Neukum Date: Wed Apr 15 17:13:58 2020 +0200 cdc-acm: introduce a cool down commit a4e7279cd1d19f48f0af2a10ed020febaa9ac092 upstream. Immediate submission in case of a babbling device can lead to a busy loop. Introducing a delayed work. Signed-off-by: Oliver Neukum Cc: stable Tested-by: Jonas Karlsson Link: https://lore.kernel.org/r/20200415151358.32664-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 892de572ea71a29c54f137d8c0488f2fab72b9b5 Author: Oliver Neukum Date: Wed Apr 15 17:13:57 2020 +0200 cdc-acm: close race betrween suspend() and acm_softint commit 0afccd7601514c4b83d8cc58c740089cc447051d upstream. Suspend increments a counter, then kills the URBs, then kills the scheduled work. The scheduled work, however, may reschedule the URBs. Fix this by having the work check the counter. Signed-off-by: Oliver Neukum Cc: stable Tested-by: Jonas Karlsson Link: https://lore.kernel.org/r/20200415151358.32664-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit 23d44059bc4462e0126ca8f41b26df42caf78a36 Author: Malcolm Priestley Date: Tue Apr 14 11:39:23 2020 +0100 staging: vt6656: Power save stop wake_up_count wrap around. commit ea81c3486442f4643fc9825a2bb1b430b829bccd upstream. conf.listen_interval can sometimes be zero causing wake_up_count to wrap around up to many beacons too late causing CTRL-EVENT-BEACON-LOSS as in. wpa_supplicant[795]: message repeated 45 times: [..CTRL-EVENT-BEACON-LOSS ] Fixes: 43c93d9bf5e2 ("staging: vt6656: implement power saving code.") Cc: stable Signed-off-by: Malcolm Priestley Link: https://lore.kernel.org/r/fce47bb5-7ca6-7671-5094-5c6107302f2b@gmail.com Signed-off-by: Greg Kroah-Hartman commit 9f1a23cbef73a953620150b5eb1bcb9929e02b0c Author: Malcolm Priestley Date: Sat Apr 18 22:01:49 2020 +0100 staging: vt6656: Fix pairwise key entry save. commit 0b59f10b1d8fe8d50944f21f5d403df9303095a8 upstream. The problem is that the group key was saved as VNT_KEY_DEFAULTKEY was over written by the VNT_KEY_GROUP_ADDRESS index. mac80211 could not clear the mac_addr in the default key. The VNT_KEY_DEFAULTKEY is not necesscary so remove it and set as VNT_KEY_GROUP_ADDRESS. mac80211 can clear any key using vnt_mac_disable_keyentry. Fixes: f9ef05ce13e4 ("staging: vt6656: Fix pairwise key for non station modes") Cc: stable Signed-off-by: Malcolm Priestley Link: https://lore.kernel.org/r/da2f7e7f-1658-1320-6eee-0f55770ca391@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0bcc6585717e67914c9a710246faaec7f523b7e0 Author: Malcolm Priestley Date: Sat Apr 18 17:43:24 2020 +0100 staging: vt6656: Fix drivers TBTT timing counter. commit 09057742af98a39ebffa27fac4f889dc873132de upstream. The drivers TBTT counter is not synchronized with mac80211 timestamp. Reorder the functions and use vnt_update_next_tbtt to do the final synchronize. Fixes: c15158797df6 ("staging: vt6656: implement TSF counter") Cc: stable Signed-off-by: Malcolm Priestley Link: https://lore.kernel.org/r/375d0b25-e8bc-c8f7-9b10-6cc705d486ee@gmail.com Signed-off-by: Greg Kroah-Hartman commit 74bbe9d990400007b959a186cce744b4877cb99a Author: Malcolm Priestley Date: Sat Apr 18 18:37:18 2020 +0100 staging: vt6656: Fix calling conditions of vnt_set_bss_mode commit 664ba5180234593b4b8517530e8198bf2f7359e2 upstream. vnt_set_bss_mode needs to be called on all changes to BSS_CHANGED_BASIC_RATES, BSS_CHANGED_ERP_PREAMBLE and BSS_CHANGED_ERP_SLOT Remove all other calls and vnt_update_ifs which is called in vnt_set_bss_mode. Fixes an issue that preamble mode is not being updated correctly. Fixes: c12603576e06 ("staging: vt6656: Only call vnt_set_bss_mode on basic rates change.") Cc: stable Signed-off-by: Malcolm Priestley Link: https://lore.kernel.org/r/44110801-6234-50d8-c583-9388f04b486c@gmail.com Signed-off-by: Greg Kroah-Hartman commit ec5ad5e1958c6a48e0bd1fb5323adc6b8deffb6a Author: Malcolm Priestley Date: Sat Apr 18 17:24:50 2020 +0100 staging: vt6656: Don't set RCR_MULTICAST or RCR_BROADCAST by default. commit 0f8240bfc070033a4823b19883efd3d38c7735cc upstream. mac80211/users control whether multicast is on or off don't enable it by default. Fixes an issue when multicast/broadcast is always on allowing other beacons through in power save. Fixes: db8f37fa3355 ("staging: vt6656: mac80211 conversion: main_usb add functions...") Cc: stable Signed-off-by: Malcolm Priestley Link: https://lore.kernel.org/r/2c24c33d-68c4-f343-bd62-105422418eac@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 64882aa0c531f3c372b7e5c595fabf7c42e806df Author: Nicolas Pitre Date: Sat Mar 28 22:25:11 2020 -0400 vt: don't use kmalloc() for the unicode screen buffer commit 9a98e7a80f95378c9ee0c644705e3b5aa54745f1 upstream. Even if the actual screen size is bounded in vc_do_resize(), the unicode buffer is still a little more than twice the size of the glyph buffer and may exceed MAX_ORDER down the kmalloc() path. This can be triggered from user space. Since there is no point having a physically contiguous buffer here, let's avoid the above issue as well as reducing pressure on high order allocations by using vmalloc() instead. Signed-off-by: Nicolas Pitre Cc: Acked-by: Sam Ravnborg Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.2003282214210.2671@knanqh.ubzr Signed-off-by: Greg Kroah-Hartman commit b027b30d1428eb5a3d117da5f6f266215836177d Author: Nicolas Pitre Date: Sat Mar 28 17:32:42 2020 -0400 vt: don't hardcode the mem allocation upper bound commit 2717769e204e83e65b8819c5e2ef3e5b6639b270 upstream. The code in vc_do_resize() bounds the memory allocation size to avoid exceeding MAX_ORDER down the kzalloc() call chain and generating a runtime warning triggerable from user space. However, not only is it unwise to use a literal value here, but MAX_ORDER may also be configurable based on CONFIG_FORCE_MAX_ZONEORDER. Let's use KMALLOC_MAX_SIZE instead. Note that prior commit bb1107f7c605 ("mm, slab: make sure that KMALLOC_MAX_SIZE will fit into MAX_ORDER") the KMALLOC_MAX_SIZE value could not be relied upon. Signed-off-by: Nicolas Pitre Cc: # v4.10+ Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.2003281702410.2671@knanqh.ubzr Signed-off-by: Greg Kroah-Hartman commit 8f8d7f07d9514574624f0b96adf610d421f952a7 Author: Xiyu Yang Date: Mon Apr 20 13:44:16 2020 +0800 staging: comedi: Fix comedi_device refcnt leak in comedi_open commit 332e0e17ad49e084b7db670ef43b5eb59abd9e34 upstream. comedi_open() invokes comedi_dev_get_from_minor(), which returns a reference of the COMEDI device to "dev" with increased refcount. When comedi_open() returns, "dev" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of comedi_open(). When "cfp" allocation is failed, the refcnt increased by comedi_dev_get_from_minor() is not decreased, causing a refcnt leak. Fix this issue by calling comedi_dev_put() on this error path when "cfp" allocation is failed. Fixes: 20f083c07565 ("staging: comedi: prepare support for per-file read and write subdevices") Signed-off-by: Xiyu Yang Cc: stable Signed-off-by: Xin Tan Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/1587361459-83622-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 279dd75cec55c0c98a9af85b452fa73f5ac2da19 Author: Ian Abbott Date: Mon Apr 6 15:20:15 2020 +0100 staging: comedi: dt2815: fix writing hi byte of analog output commit ed87d33ddbcd9a1c3b5ae87995da34e6f51a862c upstream. The DT2815 analog output command is 16 bits wide, consisting of the 12-bit sample value in bits 15 to 4, the channel number in bits 3 to 1, and a voltage or current selector in bit 0. Both bytes of the 16-bit command need to be written in turn to a single 8-bit data register. However, the driver currently only writes the low 8-bits. It is broken and appears to have always been broken. Electronic copies of the DT2815 User's Manual seem impossible to find online, but looking at the source code, a best guess for the sequence the driver intended to use to write the analog output command is as follows: 1. Wait for the status register to read 0x00. 2. Write the low byte of the command to the data register. 3. Wait for the status register to read 0x80. 4. Write the high byte of the command to the data register. Step 4 is missing from the driver. Add step 4 to (hopefully) fix the driver. Also add a "FIXME" comment about setting bit 0 of the low byte of the command. Supposedly, it is used to choose between voltage output and current output, but the current driver always sets it to 1. Signed-off-by: Ian Abbott Cc: stable Link: https://lore.kernel.org/r/20200406142015.126982-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit dba6465408b8bf58d29beb3ac74a2c9fe93c2737 Author: Chris Packham Date: Fri Apr 17 10:19:08 2020 +1200 powerpc/setup_64: Set cache-line-size based on cache-block-size commit 94c0b013c98583614e1ad911e8795ca36da34a85 upstream. If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, use the block-size value for both. Per the devicetree spec cache-line-size is only needed if it differs from the block size. Originally the code would fallback from block size to line size. An error message was printed if both properties were missing. Later the code was refactored to use clearer names and logic but it inadvertently made line size a required property, meaning on systems without a line size property we fall back to the default from the cputable. On powernv (OPAL) platforms, since the introduction of device tree CPU features (5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")), that has led to the wrong value being used, as the fallback value is incorrect for Power8/Power9 CPUs. The incorrect values flow through to the VDSO and also to the sysconf values, SC_LEVEL1_ICACHE_LINESIZE etc. Fixes: bd067f83b084 ("powerpc/64: Fix naming of cache block vs. cache line") Cc: stable@vger.kernel.org # v4.11+ Signed-off-by: Chris Packham Reported-by: Qian Cai [mpe: Add even more detail to change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200416221908.7886-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Greg Kroah-Hartman commit 921b7b175605f04d3ca9acfdd110505cbcbd0b14 Author: Ahmad Fatoum Date: Mon Mar 23 09:19:33 2020 +0100 ARM: imx: provide v7_cpu_resume() only on ARM_CPU_SUSPEND=y commit f1baca8896ae18e12c45552a4c4ae2086aa7e02c upstream. 512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally") introduced an unintended linker error for i.MX6 configurations that have ARM_CPU_SUSPEND=n which can happen if neither CONFIG_PM, CONFIG_CPU_IDLE, nor ARM_PSCI_FW are selected. Fix this by having v7_cpu_resume() compiled only when cpu_resume() it calls is available as well. The C declaration for the function remains unguarded to avoid future code inadvertently using a stub and introducing a regression to the bug the original commit fixed. Cc: Fixes: 512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally") Reported-by: Clemens Gruber Signed-off-by: Ahmad Fatoum Tested-by: Roland Hieber Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit eabc107d20dad03d63d1e79ad16e20d77a6bcf86 Author: Paulo Alcantara Date: Mon Apr 20 23:44:24 2020 -0300 cifs: fix uninitialised lease_key in open_shroot() commit 0fe0781f29dd8ab618999e6bda33c782ebbdb109 upstream. SMB2_open_init() expects a pre-initialised lease_key when opening a file with a lease, so set pfid->lease_key prior to calling it in open_shroot(). This issue was observed when performing some DFS failover tests and the lease key was never randomly generated. Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg Reviewed-by: Aurelien Aptel CC: Stable Signed-off-by: Greg Kroah-Hartman commit 562489ba1078785c069c4047068a33d53e9f02df Author: Johannes Berg Date: Fri Apr 17 10:08:14 2020 +0300 iwlwifi: mvm: fix inactive TID removal return value usage commit e6d419f943318e2b903e380dfd52a8dda6db3021 upstream. The function iwl_mvm_remove_inactive_tids() returns bool, so we should just check "if (ret)", not "if (ret >= 0)" (which would do nothing useful here). We obviously therefore cannot use the return value of the function for the free_queue, we need to use the queue (i) we're currently dealing with instead. Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20200417100405.9d862ed72535.I9e27ccc3ee3c8855fc13682592b571581925dfbd@changeid Signed-off-by: Greg Kroah-Hartman commit f1926b14bd8f383da8fc976161d72a7e4f089c8f Author: Ilan Peer Date: Fri Apr 17 10:08:13 2020 +0300 iwlwifi: mvm: Do not declare support for ACK Enabled Aggregation commit 38af8d5a90a8c3b41ff0484855e24bd55b43ce9d upstream. As this was not supposed to be enabled to begin with. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20200417100405.53dbc3c6c36b.Idfe118546b92cc31548b2211472a5303c7de5909@changeid Signed-off-by: Greg Kroah-Hartman commit c93fb506bfaf8f3e42238bc221f1c33dee299490 Author: Johannes Berg Date: Fri Apr 17 10:08:12 2020 +0300 iwlwifi: mvm: limit maximum queue appropriately commit e5b72e3bc4763152e24bf4b8333bae21cc526c56 upstream. Due to some hardware issues, queue 31 isn't usable on devices that have 32 queues (7000, 8000, 9000 families), which is correctly reflected in the configuration and TX queue initialization. However, the firmware API and queue allocation code assumes that there are 32 queues, and if something actually attempts to use #31 this leads to a NULL-pointer dereference since it's not allocated. Fix this by limiting to 31 in the IWL_MVM_DQA_MAX_DATA_QUEUE, and also add some code to catch this earlier in the future, if the configuration changes perhaps. Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20200417100405.98a79be2db6a.I3a4af6b03b87a6bc18db9b1ff9a812f397bee1fc@changeid Signed-off-by: Greg Kroah-Hartman commit 4025ac3d7fb7c87bca0b862612c4a658093ea8c9 Author: Mordechay Goodstein Date: Fri Apr 17 10:08:10 2020 +0300 iwlwifi: mvm: beacon statistics shouldn't go backwards commit 290d5e4951832e39d10f4184610dbf09038f8483 upstream. We reset statistics also in case that we didn't reassoc so in this cases keep last beacon counter. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20200417100405.1f9142751fbc.Ifbfd0f928a0a761110b8f4f2ca5483a61fb21131@changeid Signed-off-by: Greg Kroah-Hartman commit 222722be70de6b3da66938943dfe18af2e72cf86 Author: Johannes Berg Date: Fri Apr 17 10:08:09 2020 +0300 iwlwifi: pcie: actually release queue memory in TVQM commit b98b33d5560a2d940f3b80f6768a6177bf3dfbc0 upstream. The iwl_trans_pcie_dyn_txq_free() function only releases the frames that may be left on the queue by calling iwl_pcie_gen2_txq_unmap(), but doesn't actually free the DMA ring or byte-count tables for the queue. This leads to pretty large memory leaks (at least before my queue size improvements), in particular in monitor/sniffer mode on channel hopping since this happens on every channel change. This was also now more evident after the move to a DMA pool for the byte count tables, showing messages such as BUG iwlwifi:bc (...): Objects remaining in iwlwifi:bc on __kmem_cache_shutdown() This fixes https://bugzilla.kernel.org/show_bug.cgi?id=206811. Signed-off-by: Johannes Berg Fixes: 6b35ff91572f ("iwlwifi: pcie: introduce a000 TX queues management") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20200417100405.f5f4c4193ec1.Id5feebc9b4318041913a9c89fc1378bb5454292c@changeid Signed-off-by: Greg Kroah-Hartman commit 7e69c9e6bbf304835b8ea0566c1e046b7dc4b3a7 Author: Chuck Lever Date: Fri Apr 17 12:40:31 2020 -0400 SUNRPC: Fix backchannel RPC soft lockups commit 6221f1d9b63fed6260273e59a2b89ab30537a811 upstream. Currently, after the forward channel connection goes away, backchannel operations are causing soft lockups on the server because call_transmit_status's SOFTCONN logic ignores ENOTCONN. Such backchannel Calls are aggressively retried until the client reconnects. Backchannel Calls should use RPC_TASK_NOCONNECT rather than RPC_TASK_SOFTCONN. If there is no forward connection, the server is not capable of establishing a connection back to the client, thus that backchannel request should fail before the server attempts to send it. Commit 58255a4e3ce5 ("NFSD: NFSv4 callback client should use RPC_TASK_SOFTCONN") was merged several years before RPC_TASK_NOCONNECT was available. Because setup_callback_client() explicitly sets NOPING, the NFSv4.0 callback connection depends on the first callback RPC to initiate a connection to the client. Thus NFSv4.0 needs to continue to use RPC_TASK_SOFTCONN. Suggested-by: Trond Myklebust Signed-off-by: Chuck Lever Cc: # v4.20+ Signed-off-by: Greg Kroah-Hartman commit d62d85260ac4b914c804690b38d09e03517f8241 Author: Johannes Berg Date: Thu Apr 23 11:13:49 2020 +0200 mac80211: populate debugfs only after cfg80211 init commit 6cb5f3ea4654faf8c28b901266e960b1a4787b26 upstream. When fixing the initialization race, we neglected to account for the fact that debugfs is initialized in wiphy_register(), and some debugfs things went missing (or rather were rerooted to the global debugfs root). Fix this by adding debugfs entries only after wiphy_register(). This requires some changes in the rate control code since it currently adds debugfs at alloc time, which can no longer be done after the reordering. Reported-by: Jouni Malinen Reported-by: kernel test robot Reported-by: Hauke Mehrtens Reported-by: Felix Fietkau Cc: stable@vger.kernel.org Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()") Signed-off-by: Johannes Berg Acked-by: Sumit Garg Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f67f3317ceb3fb36b30b856b152c148fdb5f6b90 Author: Gyeongtaek Lee Date: Sat Apr 18 13:13:20 2020 +0900 ASoC: dapm: fixup dapm kcontrol widget commit ebf1474745b4373fdde0fcf32d9d1f369b50b212 upstream. snd_soc_dapm_kcontrol widget which is created by autodisable control should contain correct on_val, mask and shift because it is set when the widget is powered and changed value is applied on registers by following code in dapm_seq_run_coalesced(). mask |= w->mask << w->shift; if (w->power) value |= w->on_val << w->shift; else value |= w->off_val << w->shift; Shift on the mask in dapm_kcontrol_data_alloc() is removed to prevent double shift. And, on_val in dapm_kcontrol_set_value() is modified to get correct value in the dapm_seq_run_coalesced(). Signed-off-by: Gyeongtaek Lee Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/000001d61537$b212f620$1638e260$@samsung.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 83f82fd5552c91f4f01921428c871dc8d82abccf Author: Paul Moore Date: Mon Apr 20 16:24:34 2020 -0400 audit: check the length of userspace generated audit records commit 763dafc520add02a1f4639b500c509acc0ea8e5b upstream. Commit 756125289285 ("audit: always check the netlink payload length in audit_receive_msg()") fixed a number of missing message length checks, but forgot to check the length of userspace generated audit records. The good news is that you need CAP_AUDIT_WRITE to submit userspace audit records, which is generally only given to trusted processes, so the impact should be limited. Cc: stable@vger.kernel.org Fixes: 756125289285 ("audit: always check the netlink payload length in audit_receive_msg()") Reported-by: syzbot+49e69b4d71a420ceda3e@syzkaller.appspotmail.com Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 20821047aca466571b81e04cc24e2944564ecc86 Author: Eric W. Biederman Date: Mon Apr 20 11:41:50 2020 -0500 signal: Avoid corrupting si_pid and si_uid in do_notify_parent commit 61e713bdca3678e84815f2427f7a063fc353a1fc upstream. Christof Meerwald writes: > Hi, > > this is probably related to commit > 7a0cf094944e2540758b7f957eb6846d5126f535 (signal: Correct namespace > fixups of si_pid and si_uid). > > With a 5.6.5 kernel I am seeing SIGCHLD signals that don't include a > properly set si_pid field - this seems to happen for multi-threaded > child processes. > > A simple test program (based on the sample from the signalfd man page): > > #include > #include > #include > #include > #include > #include > > #define handle_error(msg) \ > do { perror(msg); exit(EXIT_FAILURE); } while (0) > > int main(int argc, char *argv[]) > { > sigset_t mask; > int sfd; > struct signalfd_siginfo fdsi; > ssize_t s; > > sigemptyset(&mask); > sigaddset(&mask, SIGCHLD); > > if (sigprocmask(SIG_BLOCK, &mask, NULL) == -1) > handle_error("sigprocmask"); > > pid_t chldpid; > char *chldargv[] = { "./sfdclient", NULL }; > posix_spawn(&chldpid, "./sfdclient", NULL, NULL, chldargv, NULL); > > sfd = signalfd(-1, &mask, 0); > if (sfd == -1) > handle_error("signalfd"); > > for (;;) { > s = read(sfd, &fdsi, sizeof(struct signalfd_siginfo)); > if (s != sizeof(struct signalfd_siginfo)) > handle_error("read"); > > if (fdsi.ssi_signo == SIGCHLD) { > printf("Got SIGCHLD %d %d %d %d\n", > fdsi.ssi_status, fdsi.ssi_code, > fdsi.ssi_uid, fdsi.ssi_pid); > return 0; > } else { > printf("Read unexpected signal\n"); > } > } > } > > > and a multi-threaded client to test with: > > #include > #include > > void *f(void *arg) > { > sleep(100); > } > > int main() > { > pthread_t t[8]; > > for (int i = 0; i != 8; ++i) > { > pthread_create(&t[i], NULL, f, NULL); > } > } > > I tried to do a bit of debugging and what seems to be happening is > that > > /* From an ancestor pid namespace? */ > if (!task_pid_nr_ns(current, task_active_pid_ns(t))) { > > fails inside task_pid_nr_ns because the check for "pid_alive" fails. > > This code seems to be called from do_notify_parent and there we > actually have "tsk != current" (I am assuming both are threads of the > current process?) I instrumented the code with a warning and received the following backtrace: > WARNING: CPU: 0 PID: 777 at kernel/pid.c:501 __task_pid_nr_ns.cold.6+0xc/0x15 > Modules linked in: > CPU: 0 PID: 777 Comm: sfdclient Not tainted 5.7.0-rc1userns+ #2924 > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > RIP: 0010:__task_pid_nr_ns.cold.6+0xc/0x15 > Code: ff 66 90 48 83 ec 08 89 7c 24 04 48 8d 7e 08 48 8d 74 24 04 e8 9a b6 44 00 48 83 c4 08 c3 48 c7 c7 59 9f ac 82 e8 c2 c4 04 00 <0f> 0b e9 3fd > RSP: 0018:ffffc9000042fbf8 EFLAGS: 00010046 > RAX: 000000000000000c RBX: 0000000000000000 RCX: ffffc9000042faf4 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81193d29 > RBP: ffffc9000042fc18 R08: 0000000000000000 R09: 0000000000000001 > R10: 000000100f938416 R11: 0000000000000309 R12: ffff8880b941c140 > R13: 0000000000000000 R14: 0000000000000000 R15: ffff8880b941c140 > FS: 0000000000000000(0000) GS:ffff8880bca00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f2e8c0a32e0 CR3: 0000000002e10000 CR4: 00000000000006f0 > Call Trace: > send_signal+0x1c8/0x310 > do_notify_parent+0x50f/0x550 > release_task.part.21+0x4fd/0x620 > do_exit+0x6f6/0xaf0 > do_group_exit+0x42/0xb0 > get_signal+0x13b/0xbb0 > do_signal+0x2b/0x670 > ? __audit_syscall_exit+0x24d/0x2b0 > ? rcu_read_lock_sched_held+0x4d/0x60 > ? kfree+0x24c/0x2b0 > do_syscall_64+0x176/0x640 > ? trace_hardirqs_off_thunk+0x1a/0x1c > entry_SYSCALL_64_after_hwframe+0x49/0xb3 The immediate problem is as Christof noticed that "pid_alive(current) == false". This happens because do_notify_parent is called from the last thread to exit in a process after that thread has been reaped. The bigger issue is that do_notify_parent can be called from any process that manages to wait on a thread of a multi-threaded process from wait_task_zombie. So any logic based upon current for do_notify_parent is just nonsense, as current can be pretty much anything. So change do_notify_parent to call __send_signal directly. Inspecting the code it appears this problem has existed since the pid namespace support started handling this case in 2.6.30. This fix only backports to 7a0cf094944e ("signal: Correct namespace fixups of si_pid and si_uid") where the problem logic was moved out of __send_signal and into send_signal. Cc: stable@vger.kernel.org Fixes: 6588c1e3ff01 ("signals: SI_USER: Masquerade si_pid when crossing pid ns boundary") Ref: 921cf9f63089 ("signals: protect cinit from unblocked SIG_DFL signals") Link: https://lore.kernel.org/lkml/20200419201336.GI22017@edge.cmeerw.net/ Reported-by: Christof Meerwald Acked-by: Oleg Nesterov Acked-by: Christian Brauner Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 1b4e23a945bd539f2daad48796605908947bfa29 Author: Alan Stern Date: Wed Apr 22 16:14:57 2020 -0400 usb-storage: Add unusual_devs entry for JMicron JMS566 commit 94f9c8c3c404ee1f7aaff81ad4f24aec4e34a78b upstream. Cyril Roelandt reports that his JMicron JMS566 USB-SATA bridge fails to handle WRITE commands with the FUA bit set, even though it claims to support FUA. (Oddly enough, a later version of the same bridge, version 2.03 as opposed to 1.14, doesn't claim to support FUA. Also oddly, the bridge _does_ support FUA when using the UAS transport instead of the Bulk-Only transport -- but this device was blacklisted for uas in commit bc3bdb12bbb3 ("usb-storage: Disable UAS on JMicron SATA enclosure") for apparently unrelated reasons.) This patch adds a usb-storage unusual_devs entry with the BROKEN_FUA flag. This allows the bridge to work properly with usb-storage. Reported-and-tested-by: Cyril Roelandt Signed-off-by: Alan Stern CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221613110.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman commit 9de9003b255ee132f391080febed1f1785540e41 Author: Jiri Slaby Date: Fri Apr 17 12:59:59 2020 +0200 tty: rocket, avoid OOB access commit 7127d24372bf23675a36edc64d092dc7fd92ebe8 upstream. init_r_port can access pc104 array out of bounds. pc104 is a 2D array defined to have 4 members. Each member has 8 submembers. * we can have more than 4 (PCI) boards, i.e. [board] can be OOB * line is not modulo-ed by anything, so the first line on the second board can be 4, on the 3rd 12 or alike (depending on previously registered boards). It's zero only on the first line of the first board. So even [line] can be OOB, quite soon (with the 2nd registered board already). This code is broken for ages, so just avoid the OOB accesses and don't try to fix it as we would need to find out the correct line number. Use the default: RS232, if we are out. Generally, if anyone needs to set the interface types, a module parameter is past the last thing that should be used for this purpose. The parameters' description says it's for ISA cards anyway. Signed-off-by: Jiri Slaby Cc: stable Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/20200417105959.15201-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f1c0d3243dbe18b2225723c3068eef992098186b Author: Andrew Melnychenko Date: Tue Apr 14 22:15:03 2020 +0300 tty: hvc: fix buffer overflow during hvc_alloc(). commit 9a9fc42b86c06120744555fea43fdcabe297c656 upstream. If there is a lot(more then 16) of virtio-console devices or virtio_console module is reloaded - buffers 'vtermnos' and 'cons_ops' are overflowed. In older kernels it overruns spinlock which leads to kernel freezing: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 To reproduce the issue, you can try simple script that loads/unloads module. Something like this: while [ 1 ] do modprobe virtio_console sleep 2 modprobe -r virtio_console sleep 2 done Description of problem: Guest get 'Call Trace' when loading module "virtio_console" and unloading it frequently - clearly reproduced on kernel-4.18.0: [ 81.498208] ------------[ cut here ]------------ [ 81.499263] pvqspinlock: lock 0xffffffff92080020 has corrupted value 0xc0774ca0! [ 81.501000] WARNING: CPU: 0 PID: 785 at kernel/locking/qspinlock_paravirt.h:500 __pv_queued_spin_unlock_slowpath+0xc0/0xd0 [ 81.503173] Modules linked in: virtio_console fuse xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nft_counter nf_nat_tftp nft_objref nf_conntrack_tftp tun bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 nft_chain_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nft_chain_route_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink sunrpc bochs_drm drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm i2c_piix4 pcspkr crct10dif_pclmul crc32_pclmul joydev ghash_clmulni_intel ip_tables xfs libcrc32c sd_mod sg ata_generic ata_piix virtio_net libata crc32c_intel net_failover failover serio_raw virtio_scsi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: virtio_console] [ 81.517019] CPU: 0 PID: 785 Comm: kworker/0:2 Kdump: loaded Not tainted 4.18.0-167.el8.x86_64 #1 [ 81.518639] Hardware name: Red Hat KVM, BIOS 1.12.0-5.scrmod+el8.2.0+5159+d8aa4d83 04/01/2014 [ 81.520205] Workqueue: events control_work_handler [virtio_console] [ 81.521354] RIP: 0010:__pv_queued_spin_unlock_slowpath+0xc0/0xd0 [ 81.522450] Code: 07 00 48 63 7a 10 e8 bf 64 f5 ff 66 90 c3 8b 05 e6 cf d6 01 85 c0 74 01 c3 8b 17 48 89 fe 48 c7 c7 38 4b 29 91 e8 3a 6c fa ff <0f> 0b c3 0f 0b 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 [ 81.525830] RSP: 0018:ffffb51a01ffbd70 EFLAGS: 00010282 [ 81.526798] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000 [ 81.528110] RDX: ffff9e66f1826480 RSI: ffff9e66f1816a08 RDI: ffff9e66f1816a08 [ 81.529437] RBP: ffffffff9153ff10 R08: 000000000000026c R09: 0000000000000053 [ 81.530732] R10: 0000000000000000 R11: ffffb51a01ffbc18 R12: ffff9e66cd682200 [ 81.532133] R13: ffffffff9153ff10 R14: ffff9e6685569500 R15: ffff9e66cd682000 [ 81.533442] FS: 0000000000000000(0000) GS:ffff9e66f1800000(0000) knlGS:0000000000000000 [ 81.534914] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 81.535971] CR2: 00005624c55b14d0 CR3: 00000003a023c000 CR4: 00000000003406f0 [ 81.537283] Call Trace: [ 81.537763] __raw_callee_save___pv_queued_spin_unlock_slowpath+0x11/0x20 [ 81.539011] .slowpath+0x9/0xe [ 81.539585] hvc_alloc+0x25e/0x300 [ 81.540237] init_port_console+0x28/0x100 [virtio_console] [ 81.541251] handle_control_message.constprop.27+0x1c4/0x310 [virtio_console] [ 81.542546] control_work_handler+0x70/0x10c [virtio_console] [ 81.543601] process_one_work+0x1a7/0x3b0 [ 81.544356] worker_thread+0x30/0x390 [ 81.545025] ? create_worker+0x1a0/0x1a0 [ 81.545749] kthread+0x112/0x130 [ 81.546358] ? kthread_flush_work_fn+0x10/0x10 [ 81.547183] ret_from_fork+0x22/0x40 [ 81.547842] ---[ end trace aa97649bd16c8655 ]--- [ 83.546539] general protection fault: 0000 [#1] SMP NOPTI [ 83.547422] CPU: 5 PID: 3225 Comm: modprobe Kdump: loaded Tainted: G W --------- - - 4.18.0-167.el8.x86_64 #1 [ 83.549191] Hardware name: Red Hat KVM, BIOS 1.12.0-5.scrmod+el8.2.0+5159+d8aa4d83 04/01/2014 [ 83.550544] RIP: 0010:__pv_queued_spin_lock_slowpath+0x19a/0x2a0 [ 83.551504] Code: c4 c1 ea 12 41 be 01 00 00 00 4c 8d 6d 14 41 83 e4 03 8d 42 ff 49 c1 e4 05 48 98 49 81 c4 40 a5 02 00 4c 03 24 c5 60 48 34 91 <49> 89 2c 24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54 24 14 84 [ 83.554449] RSP: 0018:ffffb51a0323fdb0 EFLAGS: 00010202 [ 83.555290] RAX: 000000000000301c RBX: ffffffff92080020 RCX: 0000000000000001 [ 83.556426] RDX: 000000000000301d RSI: 0000000000000000 RDI: 0000000000000000 [ 83.557556] RBP: ffff9e66f196a540 R08: 000000000000028a R09: ffff9e66d2757788 [ 83.558688] R10: 0000000000000000 R11: 0000000000000000 R12: 646e61725f770b07 [ 83.559821] R13: ffff9e66f196a554 R14: 0000000000000001 R15: 0000000000180000 [ 83.560958] FS: 00007fd5032e8740(0000) GS:ffff9e66f1940000(0000) knlGS:0000000000000000 [ 83.562233] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 83.563149] CR2: 00007fd5022b0da0 CR3: 000000038c334000 CR4: 00000000003406e0 Signed-off-by: Andrew Melnychenko Cc: stable Link: https://lore.kernel.org/r/20200414191503.3471783-1-andrew@daynix.com Signed-off-by: Greg Kroah-Hartman commit 52ca311e5f82dc4b75bcdd5a32dca6a1fbf7dfa5 Author: Uros Bizjak Date: Tue Apr 14 09:14:14 2020 +0200 KVM: VMX: Enable machine check support for 32bit targets commit fb56baae5ea509e63c2a068d66a4d8ea91969fca upstream. There is no reason to limit the use of do_machine_check to 64bit targets. MCE handling works for both target familes. Cc: Paolo Bonzini Cc: Sean Christopherson Cc: stable@vger.kernel.org Fixes: a0861c02a981 ("KVM: Add VT-x machine check support") Signed-off-by: Uros Bizjak Message-Id: <20200414071414.45636-1-ubizjak@gmail.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 878127ac8b7013d7d7fad9d160654da5b6195902 Author: Sean Christopherson Date: Tue Apr 7 23:40:58 2020 -0700 KVM: Check validity of resolved slot when searching memslots commit b6467ab142b708dd076f6186ca274f14af379c72 upstream. Check that the resolved slot (somewhat confusingly named 'start') is a valid/allocated slot before doing the final comparison to see if the specified gfn resides in the associated slot. The resolved slot can be invalid if the binary search loop terminated because the search index was incremented beyond the number of used slots. This bug has existed since the binary search algorithm was introduced, but went unnoticed because KVM statically allocated memory for the max number of slots, i.e. the access would only be truly out-of-bounds if all possible slots were allocated and the specified gfn was less than the base of the lowest memslot. Commit 36947254e5f98 ("KVM: Dynamically size memslot array based on number of used slots") eliminated the "all possible slots allocated" condition and made the bug embarrasingly easy to hit. Fixes: 9c1a5d38780e6 ("kvm: optimize GFN to memslot lookup with large slots amount") Reported-by: syzbot+d889b59b2bb87d4047a2@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20200408064059.8957-2-sean.j.christopherson@intel.com> Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 347125705f023fed57702693dd09503f482679c9 Author: Sean Christopherson Date: Tue Apr 7 23:40:59 2020 -0700 KVM: s390: Return last valid slot if approx index is out-of-bounds commit 97daa028f3f621adff2c4f7b15fe0874e5b5bd6c upstream. Return the index of the last valid slot from gfn_to_memslot_approx() if its binary search loop yielded an out-of-bounds index. The index can be out-of-bounds if the specified gfn is less than the base of the lowest memslot (which is also the last valid memslot). Note, the sole caller, kvm_s390_get_cmma(), ensures used_slots is non-zero. Fixes: afdad61615cc3 ("KVM: s390: Fix storage attributes migration with memory slots") Cc: stable@vger.kernel.org # 4.19.x: 0774a964ef56: KVM: Fix out of range accesses to memslots Cc: stable@vger.kernel.org # 4.19.x Signed-off-by: Sean Christopherson Message-Id: <20200408064059.8957-3-sean.j.christopherson@intel.com> Reviewed-by: Cornelia Huck Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3fc644fd6100ad6afa1a1a0a17f2a7ebb3412148 Author: George Wilson Date: Thu Mar 19 23:27:58 2020 -0400 tpm: ibmvtpm: retry on H_CLOSED in tpm_ibmvtpm_send() commit eba5cf3dcb844c82f54d4a857e124824e252206d upstream. tpm_ibmvtpm_send() can fail during PowerVM Live Partition Mobility resume with an H_CLOSED return from ibmvtpm_send_crq(). The PAPR says, 'The "partner partition suspended" transport event disables the associated CRQ such that any H_SEND_CRQ hcall() to the associated CRQ returns H_Closed until the CRQ has been explicitly enabled using the H_ENABLE_CRQ hcall.' This patch adds a check in tpm_ibmvtpm_send() for an H_CLOSED return from ibmvtpm_send_crq() and in that case calls tpm_ibmvtpm_resume() and retries the ibmvtpm_send_crq() once. Cc: stable@vger.kernel.org # 3.7.x Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Reported-by: Linh Pham Reviewed-by: Stefan Berger Signed-off-by: George Wilson Tested-by: Linh Pham Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 16244edc3bbe6ef692bf07fac1bd2744cd29d6d4 Author: Tianjia Zhang Date: Tue Apr 14 19:42:26 2020 +0800 tpm: fix wrong return value in tpm_pcr_extend commit 29cb79795e324a8b65e7891d76f8f6ca911ba440 upstream. For the algorithm that does not match the bank, a positive value EINVAL is returned here. I think this is a typo error. It is necessary to return an error value. Cc: stable@vger.kernel.org # 5.4.x Fixes: 9f75c8224631 ("KEYS: trusted: correctly initialize digests and fix locking issue") Signed-off-by: Tianjia Zhang Reviewed-by: Roberto Sassu Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 86f1c523d42255923ff2aa3c61760b1a1f7325a0 Author: Jarkko Sakkinen Date: Sun Apr 12 20:04:12 2020 +0300 tpm/tpm_tis: Free IRQ if probing fails commit b160c94be5d2816b62c8ac338605668304242959 upstream. Call disable_interrupts() if we have to revert to polling in order not to unnecessarily reserve the IRQ for the life-cycle of the driver. Cc: stable@vger.kernel.org # 4.5.x Reported-by: Hans de Goede Fixes: e3837e74a06d ("tpm_tis: Refactor the interrupt setup") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 387039b25077f15c53520028437ab7358a7278fc Author: Alexander Tsoy Date: Sat Apr 18 20:58:15 2020 +0300 ALSA: usb-audio: Filter out unsupported sample rates on Focusrite devices commit 1c826792586f526a5a5cd21d55aad388f5bb0b23 upstream. Many Focusrite devices supports a limited set of sample rates per altsetting. These includes audio interfaces with ADAT ports: - Scarlett 18i6, 18i8 1st gen, 18i20 1st gen; - Scarlett 18i8 2nd gen, 18i20 2nd gen; - Scarlett 18i8 3rd gen, 18i20 3rd gen; - Clarett 2Pre USB, 4Pre USB, 8Pre USB. Maximum rate is exposed in the last 4 bytes of Format Type descriptor which has a non-standard bLength = 10. Tested-by: Alexey Skobkin Signed-off-by: Alexander Tsoy Cc: Link: https://lore.kernel.org/r/20200418175815.12211-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d5cd821536294d69506dbfb9529ac48105ee9a63 Author: Xiyu Yang Date: Thu Apr 23 12:54:19 2020 +0800 ALSA: usb-audio: Fix usb audio refcnt leak when getting spdif commit 59e1947ca09ebd1cae147c08c7c41f3141233c84 upstream. snd_microii_spdif_default_get() invokes snd_usb_lock_shutdown(), which increases the refcount of the snd_usb_audio object "chip". When snd_microii_spdif_default_get() returns, local variable "chip" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in several exception handling paths of snd_microii_spdif_default_get(). When those error scenarios occur such as usb_ifnum_to_if() returns NULL, the function forgets to decrease the refcnt increased by snd_usb_lock_shutdown(), causing a refcnt leak. Fix this issue by jumping to "end" label when those error scenarios occur. Fixes: 447d6275f0c2 ("ALSA: usb-audio: Add sanity checks for endpoint accesses") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Cc: Link: https://lore.kernel.org/r/1587617711-13200-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dbb11f1d6d331e521bd512f349f5c069dcc55efe Author: Takashi Iwai Date: Wed Apr 15 18:25:23 2020 +0200 ALSA: hda/hdmi: Add module option to disable audio component binding commit b392350ec3f229ad9603d3816f753479e441d99a upstream. As the recent regression showed, we want sometimes to turn off the audio component binding just for debugging. This patch adds the module option to control it easily without compilation. Fixes: ade49db337a9 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223 Cc: Link: https://lore.kernel.org/r/20200415162523.27499-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1e1f9d36280f14135b83263c8ee5b35bf58cfdb8 Author: Kailang Yang Date: Thu Apr 23 14:18:31 2020 +0800 ALSA: hda/realtek - Add new codec supported for ALC245 commit 7fbdcd8301a84c09cebfa64f1317a6dafeec9188 upstream. Enable new codec supported for ALC245. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/8c0804738b2c42439f59c39c8437817f@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0939d06af06fb0f70dba2d4e1435a049d3a09add Author: Takashi Iwai Date: Sat Apr 18 21:06:39 2020 +0200 ALSA: hda/realtek - Fix unexpected init_amp override commit 67791202c5e069cf2ba51db0718d56c634709e78 upstream. The commit 1c76aa5fb48d ("ALSA: hda/realtek - Allow skipping spec->init_amp detection") changed the way to assign spec->init_amp field that specifies the way to initialize the amp. Along with the change, the commit also replaced a few fixups that set spec->init_amp in HDA_FIXUP_ACT_PROBE with HDA_FIXUP_ACT_PRE_PROBE. This was rather aligning to the other fixups, and not supposed to change the actual behavior. However, this change turned out to cause a regression on FSC S7020, which hit exactly the above. The reason was that there is still one place that overrides spec->init_amp after HDA_FIXUP_ACT_PRE_PROBE call, namely in alc_ssid_check(). This patch fixes the regression by adding the proper spec->init_amp override check, i.e. verifying whether it's still ALC_INIT_UNDEFINED. Fixes: 1c76aa5fb48d ("ALSA: hda/realtek - Allow skipping spec->init_amp detection") Cc: BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207329 Link: https://lore.kernel.org/r/20200418190639.10082-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 16e373fe61cb74da7f7a5081dae5c168b2c82f7c Author: Takashi Iwai Date: Mon Apr 20 09:55:29 2020 +0200 ALSA: usx2y: Fix potential NULL dereference commit 7686e3485253635c529cdd5f416fc640abaf076f upstream. The error handling code in usX2Y_rate_set() may hit a potential NULL dereference when an error occurs before allocating all us->urb[]. Add a proper NULL check for fixing the corner case. Reported-by: Lin Yi Cc: Link: https://lore.kernel.org/r/20200420075529.27203-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 000515184f6f2579f1931a8538f84dacda2d0be5 Author: Lucas Stach Date: Mon Apr 20 18:14:23 2020 -0700 tools/vm: fix cross-compile build commit cf01699ee220c38099eb3e43ce3d10690c8b7060 upstream. Commit 7ed1c1901fe5 ("tools: fix cross-compile var clobbering") moved the setup of the CC variable to tools/scripts/Makefile.include to make the behavior consistent across all the tools Makefiles. As the vm tools missed the include we end up with the wrong CC in a cross-compiling evironment. Fixes: 7ed1c1901fe5 (tools: fix cross-compile var clobbering) Signed-off-by: Lucas Stach Signed-off-by: Andrew Morton Cc: Martin Kelly Cc: Link: http://lkml.kernel.org/r/20200416104748.25243-1-l.stach@pengutronix.de Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5126bdeaf980b1dab8dba400001c234787a20afc Author: Muchun Song Date: Mon Apr 20 18:14:04 2020 -0700 mm/ksm: fix NULL pointer dereference when KSM zero page is enabled commit 56df70a63ed5d989c1d36deee94cae14342be6e9 upstream. find_mergeable_vma() can return NULL. In this case, it leads to a crash when we access vm_mm(its offset is 0x40) later in write_protect_page. And this case did happen on our server. The following call trace is captured in kernel 4.19 with the following patch applied and KSM zero page enabled on our server. commit e86c59b1b12d ("mm/ksm: improve deduplication of zero pages with colouring") So add a vma check to fix it. BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 Oops: 0000 [#1] SMP NOPTI CPU: 9 PID: 510 Comm: ksmd Kdump: loaded Tainted: G OE 4.19.36.bsk.9-amd64 #4.19.36.bsk.9 RIP: try_to_merge_one_page+0xc7/0x760 Code: 24 58 65 48 33 34 25 28 00 00 00 89 e8 0f 85 a3 06 00 00 48 83 c4 60 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 46 08 a8 01 75 b8 <49> 8b 44 24 40 4c 8d 7c 24 20 b9 07 00 00 00 4c 89 e6 4c 89 ff 48 RSP: 0018:ffffadbdd9fffdb0 EFLAGS: 00010246 RAX: ffffda83ffd4be08 RBX: ffffda83ffd4be40 RCX: 0000002c6e800000 RDX: 0000000000000000 RSI: ffffda83ffd4be40 RDI: 0000000000000000 RBP: ffffa11939f02ec0 R08: 0000000094e1a447 R09: 00000000abe76577 R10: 0000000000000962 R11: 0000000000004e6a R12: 0000000000000000 R13: ffffda83b1e06380 R14: ffffa18f31f072c0 R15: ffffda83ffd4be40 FS: 0000000000000000(0000) GS:ffffa0da43b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000040 CR3: 0000002c77c0a003 CR4: 00000000007626e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ksm_scan_thread+0x115e/0x1960 kthread+0xf5/0x130 ret_from_fork+0x1f/0x30 [songmuchun@bytedance.com: if the vma is out of date, just exit] Link: http://lkml.kernel.org/r/20200416025034.29780-1-songmuchun@bytedance.com [akpm@linux-foundation.org: add the conventional braces, replace /** with /*] Fixes: e86c59b1b12d ("mm/ksm: improve deduplication of zero pages with colouring") Co-developed-by: Xiongchun Duan Signed-off-by: Muchun Song Signed-off-by: Andrew Morton Reviewed-by: David Hildenbrand Reviewed-by: Kirill Tkhai Cc: Hugh Dickins Cc: Yang Shi Cc: Claudio Imbrenda Cc: Markus Elfring Cc: Link: http://lkml.kernel.org/r/20200416025034.29780-1-songmuchun@bytedance.com Link: http://lkml.kernel.org/r/20200414132905.83819-1-songmuchun@bytedance.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3c88e95cd167c57b27fe473ad3c4edd4dcadf660 Author: Longpeng Date: Mon Apr 20 18:13:51 2020 -0700 mm/hugetlb: fix a addressing exception caused by huge_pte_offset commit 3c1d7e6ccb644d517a12f73a7ff200870926f865 upstream. Our machine encountered a panic(addressing exception) after run for a long time and the calltrace is: RIP: hugetlb_fault+0x307/0xbe0 RSP: 0018:ffff9567fc27f808 EFLAGS: 00010286 RAX: e800c03ff1258d48 RBX: ffffd3bb003b69c0 RCX: e800c03ff1258d48 RDX: 17ff3fc00eda72b7 RSI: 00003ffffffff000 RDI: e800c03ff1258d48 RBP: ffff9567fc27f8c8 R08: e800c03ff1258d48 R09: 0000000000000080 R10: ffffaba0704c22a8 R11: 0000000000000001 R12: ffff95c87b4b60d8 R13: 00005fff00000000 R14: 0000000000000000 R15: ffff9567face8074 FS: 00007fe2d9ffb700(0000) GS:ffff956900e40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffd3bb003b69c0 CR3: 000000be67374000 CR4: 00000000003627e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: follow_hugetlb_page+0x175/0x540 __get_user_pages+0x2a0/0x7e0 __get_user_pages_unlocked+0x15d/0x210 __gfn_to_pfn_memslot+0x3c5/0x460 [kvm] try_async_pf+0x6e/0x2a0 [kvm] tdp_page_fault+0x151/0x2d0 [kvm] ... kvm_arch_vcpu_ioctl_run+0x330/0x490 [kvm] kvm_vcpu_ioctl+0x309/0x6d0 [kvm] do_vfs_ioctl+0x3f0/0x540 SyS_ioctl+0xa1/0xc0 system_call_fastpath+0x22/0x27 For 1G hugepages, huge_pte_offset() wants to return NULL or pudp, but it may return a wrong 'pmdp' if there is a race. Please look at the following code snippet: ... pud = pud_offset(p4d, addr); if (sz != PUD_SIZE && pud_none(*pud)) return NULL; /* hugepage or swap? */ if (pud_huge(*pud) || !pud_present(*pud)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); if (sz != PMD_SIZE && pmd_none(*pmd)) return NULL; /* hugepage or swap? */ if (pmd_huge(*pmd) || !pmd_present(*pmd)) return (pte_t *)pmd; ... The following sequence would trigger this bug: - CPU0: sz = PUD_SIZE and *pud = 0 , continue - CPU0: "pud_huge(*pud)" is false - CPU1: calling hugetlb_no_page and set *pud to xxxx8e7(PRESENT) - CPU0: "!pud_present(*pud)" is false, continue - CPU0: pmd = pmd_offset(pud, addr) and maybe return a wrong pmdp However, we want CPU0 to return NULL or pudp in this case. We must make sure there is exactly one dereference of pud and pmd. Signed-off-by: Longpeng Signed-off-by: Andrew Morton Reviewed-by: Mike Kravetz Reviewed-by: Jason Gunthorpe Cc: Matthew Wilcox Cc: Sean Christopherson Cc: Link: http://lkml.kernel.org/r/20200413010342.771-1-longpeng2@huawei.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a77daafc2e37267befb06b74224d65d0afa26be0 Author: Sudip Mukherjee Date: Mon Apr 20 18:14:20 2020 -0700 coredump: fix null pointer dereference on coredump commit db973a7289dad24e6c017dcedc6aee886579dc3a upstream. If the core_pattern is set to "|" and any process segfaults then we get a null pointer derefernce while trying to coredump. The call stack shows: RIP: do_coredump+0x628/0x11c0 When the core_pattern has only "|" there is no use of trying the coredump and we can check that while formating the corename and exit with an error. After this change I get: format_corename failed Aborting core Fixes: 315c69261dd3 ("coredump: split pipe command whitespace before expanding template") Reported-by: Matthew Ruffell Signed-off-by: Sudip Mukherjee Signed-off-by: Andrew Morton Cc: Paul Wise Cc: Alexander Viro Cc: Neil Horman Cc: Link: http://lkml.kernel.org/r/20200416194612.21418-1-sudipm.mukherjee@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fcfd63da5d8285df02f1332adc98c10ba4551011 Author: Luis Mendes Date: Fri Apr 3 16:15:34 2020 +0100 staging: gasket: Fix incongruency in handling of sysfs entries creation commit 9195d762042b0e5e4ded63606b4b30a93cba4400 upstream. Fix incongruency in handling of sysfs entries creation. This issue could cause invalid memory accesses, by not properly detecting the end of the sysfs attributes array. Fixes: 84c45d5f3bf1 ("staging: gasket: Replace macro __ATTR with __ATTR_NULL") Signed-off-by: Luis Mendes Cc: stable Link: https://lore.kernel.org/r/20200403151534.20753-1-luis.p.mendes@gmail.com Signed-off-by: Greg Kroah-Hartman commit f4f235309b5cc8e6217774279ae2b263345f5f6a Author: Jann Horn Date: Mon Apr 20 18:14:11 2020 -0700 vmalloc: fix remap_vmalloc_range() bounds checks commit bdebd6a2831b6fab69eb85cee74a8ba77f1a1cc2 upstream. remap_vmalloc_range() has had various issues with the bounds checks it promises to perform ("This function checks that addr is a valid vmalloc'ed area, and that it is big enough to cover the vma") over time, e.g.: - not detecting pgoff< Signed-off-by: Andrew Morton Cc: stable@vger.kernel.org Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Andrii Nakryiko Cc: John Fastabend Cc: KP Singh Link: http://lkml.kernel.org/r/20200415222312.236431-1-jannh@google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3d15344e23c554b6c25f8a5ded3a3657a31e9779 Author: Amit Singh Tomar Date: Fri Apr 17 01:41:57 2020 +0530 tty: serial: owl: add "much needed" clk_prepare_enable() commit abf42d2f333b21bf8d33b2fbb8a85fa62037ac01 upstream. commit 8ba92cf59335 ("arm64: dts: actions: s700: Add Clock Management Unit") breaks the UART on Cubieboard7-lite (based on S700 SoC), This is due to the fact that generic clk routine clk_disable_unused() disables the gate clks, and that in turns disables OWL UART (but UART driver never enables it). To prove this theory, Andre suggested to use "clk_ignore_unused" in kernel commnd line and it worked (Kernel happily lands into RAMFS world :)). This commit fix this up by adding clk_prepare_enable(). Fixes: 8ba92cf59335 ("arm64: dts: actions: s700: Add Clock Management Unit") Signed-off-by: Amit Singh Tomar Cc: stable Link: https://lore.kernel.org/r/1587067917-1400-1-git-send-email-amittomer25@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4fbf19bbba6a2f5a5aedcf9d98784fb3b5e8318b Author: Alan Stern Date: Wed Apr 22 16:13:08 2020 -0400 USB: hub: Revert commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") commit 3155f4f40811c5d7e3c686215051acf504e05565 upstream. Commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") changed the way the hub driver enumerates high-speed devices. Instead of using the "new" enumeration scheme first and switching to the "old" scheme if that doesn't work, we start with the "old" scheme. In theory this is better because the "old" scheme is slightly faster -- it involves resetting the device only once instead of twice. However, for a long time Windows used only the "new" scheme. Zeng Tao said that Windows 8 and later use the "old" scheme for high-speed devices, but apparently there are some devices that don't like it. William Bader reports that the Ricoh webcam built into his Sony Vaio laptop not only doesn't enumerate under the "old" scheme, it gets hung up so badly that it won't then enumerate under the "new" scheme! Only a cold reset will fix it. Therefore we will revert the commit and go back to trying the "new" scheme first for high-speed devices. Reported-and-tested-by: William Bader Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207219 Signed-off-by: Alan Stern Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") CC: Zeng Tao CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221611230.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman commit 50ad463e20bf419a9b3d058ae792b920f363b9e3 Author: Alan Stern Date: Wed Apr 22 16:09:51 2020 -0400 USB: hub: Fix handling of connect changes during sleep commit 9f952e26295d977dbfc6fedeaf8c4f112c818d37 upstream. Commit 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") wasn't very well conceived. The problem it tried to fix was that if a connect-change event occurred while the system was asleep (such as a device disconnecting itself from the bus when it is suspended and then reconnecting when it resumes) requiring a reset-resume during the system wakeup transition, the hub port's change_bit entry would remain set afterward. This would cause the hub driver to believe another connect-change event had occurred after the reset-resume, which was wrong and would lead the driver to send unnecessary requests to the device (which could interfere with a firmware update). The commit tried to fix this by not setting the change_bit during the wakeup. But this was the wrong thing to do; it means that when a device is unplugged while the system is asleep, the hub driver doesn't realize anything has happened: The change_bit flag which would tell it to handle the disconnect event is clear. The commit needs to be reverted and the problem fixed in a different way. Fortunately an alternative solution was noted in the commit's Changelog: We can continue to set the change_bit entry in hub_activate() but then clear it when a reset-resume occurs. That way the the hub driver will see the change_bit when a device is disconnected but won't see it when the device is still present. That's what this patch does. Reported-and-tested-by: Peter Chen Signed-off-by: Alan Stern Fixes: 8099f58f1ecd ("USB: hub: Don't record a connect-change event during reset-resume") Tested-by: Paul Zimmerman CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221602480.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman commit b48193a7c303272d357b27dd7d72cbf89f7b2d35 Author: Alan Stern Date: Sat Mar 28 16:18:11 2020 -0400 USB: core: Fix free-while-in-use bug in the USB S-Glibrary commit 056ad39ee9253873522f6469c3364964a322912b upstream. FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug in the USB scatter-gather library: BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: scsi_tmf_2 scmd_eh_abort_handler Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x153/0x1cb mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:95 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657 usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602 usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937 This bug occurs when cancellation of the S-G transfer races with transfer completion. When that happens, usb_sg_cancel() may continue to access the transfer's URBs after usb_sg_wait() has freed them. The bug is caused by the fact that usb_sg_cancel() does not take any sort of reference to the transfer, and so there is nothing to prevent the URBs from being deallocated while the routine is trying to use them. The fix is to take such a reference by incrementing the transfer's io->count field while the cancellation is in progres and decrementing it afterward. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. Signed-off-by: Alan Stern Reported-and-tested-by: Kyungtae Kim CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2003281615140.14837-100000@netrider.rowland.org Signed-off-by: Greg Kroah-Hartman commit 1d53402d89d7871a968b185e719e2c184dea1a70 Author: Jann Horn Date: Wed Apr 1 09:46:19 2020 +0200 USB: early: Handle AMD's spec-compliant identifiers, too commit 7dbdb53d72a51cea9b921d9dbba54be00752212a upstream. This fixes a bug that causes the USB3 early console to freeze after printing a single line on AMD machines because it can't parse the Transfer TRB properly. The spec at https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf says in section "4.5.1 Device Context Index" that the Context Index, also known as Endpoint ID according to section "1.6 Terms and Abbreviations", is normally computed as `DCI = (Endpoint Number * 2) + Direction`, which matches the current definitions of XDBC_EPID_OUT and XDBC_EPID_IN. However, the numbering in a Debug Capability Context data structure is supposed to be different: Section "7.6.3.2 Endpoint Contexts and Transfer Rings" explains that a Debug Capability Context data structure has the endpoints mapped to indices 0 and 1. Change XDBC_EPID_OUT/XDBC_EPID_IN to the spec-compliant values, add XDBC_EPID_OUT_INTEL/XDBC_EPID_IN_INTEL with Intel's incorrect values, and let xdbc_handle_tx_event() handle both. I have verified that with this patch applied, the USB3 early console works on both an Intel and an AMD machine. Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20200401074619.8024-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit 8409f83e3e817ac10f981d07bca785a4f81ff330 Author: Jonathan Cox Date: Fri Apr 10 14:24:27 2020 -0700 USB: Add USB_QUIRK_DELAY_CTRL_MSG and USB_QUIRK_DELAY_INIT for Corsair K70 RGB RAPIDFIRE commit be34a5854b4606bd7a160ad3cb43415d623596c7 upstream. The Corsair K70 RGB RAPIDFIRE needs the USB_QUIRK_DELAY_INIT and USB_QUIRK_DELAY_CTRL_MSG to function or it will randomly not respond on boot, just like other Corsair keyboards Signed-off-by: Jonathan Cox Cc: stable Link: https://lore.kernel.org/r/20200410212427.2886-1-jonathan@jdcox.net Signed-off-by: Greg Kroah-Hartman commit b7758cd38b94e95f85bbb69b99c6453e64436976 Author: Changming Liu Date: Mon Apr 20 23:41:25 2020 -0400 USB: sisusbvga: Change port variable from signed to unsigned commit 2df7405f79ce1674d73c2786fe1a8727c905d65b upstream. Change a bunch of arguments of wrapper functions which pass signed integer to an unsigned integer which might cause undefined behaviors when sign integer overflow. Signed-off-by: Changming Liu Cc: stable Link: https://lore.kernel.org/r/BL0PR06MB45482D71EA822D75A0E60A2EE5D50@BL0PR06MB4548.namprd06.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 557f3f5492176bef7f07a84043d58dcbd2249438 Author: Lars-Peter Clausen Date: Fri Apr 3 15:27:16 2020 +0200 iio: xilinx-xadc: Make sure not exceed maximum samplerate commit 3b7f9dbb827ce8680b98490215e698b6079a9ec5 upstream. The XADC supports a samplerate of up to 1MSPS. Unfortunately the hardware does not have a FIFO, which means it generates an interrupt for each conversion sequence. At one 1MSPS this creates an interrupt storm that causes the system to soft-lock. For this reason the driver limits the maximum samplerate to 150kSPS. Currently this check is only done when setting a new samplerate. But it is also possible that the initial samplerate configured in the FPGA bitstream exceeds the limit. In this case when starting to capture data without first changing the samplerate the system can overload. To prevent this check the currently configured samplerate in the probe function and reduce it to the maximum if necessary. Signed-off-by: Lars-Peter Clausen Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b3e365a070167e2970034d461a319b2d58b05368 Author: Lars-Peter Clausen Date: Fri Apr 3 15:27:15 2020 +0200 iio: xilinx-xadc: Fix sequencer configuration for aux channels in simultaneous mode commit 8bef455c8b1694547ee59e8b1939205ed9d901a6 upstream. The XADC has two internal ADCs. Depending on the mode it is operating in either one or both of them are used. The device manual calls this continuous (one ADC) and simultaneous (both ADCs) mode. The meaning of the sequencing register for the aux channels changes depending on the mode. In continuous mode each bit corresponds to one of the 16 aux channels. And the single ADC will convert them one by one in order. In simultaneous mode the aux channels are split into two groups the first 8 channels are assigned to the first ADC and the other 8 channels to the second ADC. The upper 8 bits of the sequencing register are unused and the lower 8 bits control both ADCs. This means a bit needs to be set if either the corresponding channel from the first group or the second group (or both) are set. Currently the driver does not have the special handling required for simultaneous mode. Add it. Signed-off-by: Lars-Peter Clausen Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit cf2849c9ef46d78a5c800a2ddb3caca5c7b36ee4 Author: Lars-Peter Clausen Date: Fri Apr 3 15:27:14 2020 +0200 iio: xilinx-xadc: Fix clearing interrupt when enabling trigger commit f954b098fbac4d183219ce5b42d76d6df2aed50a upstream. When enabling the trigger and unmasking the end-of-sequence (EOS) interrupt the EOS interrupt should be cleared from the status register. Otherwise it is possible that it was still set from a previous capture. If that is the case the interrupt would fire immediately even though no conversion has been done yet and stale data is being read from the device. The old code only clears the interrupt if the interrupt was previously unmasked. Which does not make much sense since the interrupt is always masked at this point and in addition masking the interrupt does not clear the interrupt from the status register. So the clearing needs to be done unconditionally. Signed-off-by: Lars-Peter Clausen Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6a956eb2e1a70ad0e9097c8b3f7084e7532c17e1 Author: Lars-Peter Clausen Date: Fri Apr 3 15:27:13 2020 +0200 iio: xilinx-xadc: Fix ADC-B powerdown commit e44ec7794d88f918805d700240211a9ec05ed89d upstream. The check for shutting down the second ADC is inverted. This causes it to be powered down when it should be enabled. As a result channels that are supposed to be handled by the second ADC return invalid conversion results. Signed-off-by: Lars-Peter Clausen Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f83a969fcb0b5d4cfb7c22ac5d4a04b8ceb514f4 Author: Alexandre Belloni Date: Thu Apr 16 22:54:27 2020 +0200 iio: adc: ti-ads8344: properly byte swap value commit dd7de4c0023e7564cabe39d64b2822a522890792 upstream. The first received byte is the MSB, followed by the LSB so the value needs to be byte swapped. Also, the ADC actually has a delay of one clock on the SPI bus. Read three bytes to get the last bit. Fixes: 8dd2d7c0fed7 ("iio: adc: Add driver for the TI ADS8344 A/DC chips") Signed-off-by: Alexandre Belloni Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit db168069b0d661f005e053fad94af1d5eac1dead Author: Olivier Moysan Date: Mon Mar 9 11:02:12 2020 +0100 iio: adc: stm32-adc: fix sleep in atomic context commit e2042d2936dfc84e9c600fe9b9d0039ca0e54b7d upstream. This commit fixes the following error: "BUG: sleeping function called from invalid context at kernel/irq/chip.c" In DMA mode suppress the trigger irq handler, and make the buffer transfers directly in DMA callback, instead. Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support") Signed-off-by: Olivier Moysan Acked-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 02311bc133440a0b333c6bb51dc669be3d72972c Author: Lary Gibaud Date: Sat Apr 11 17:16:06 2020 +0200 iio: st_sensors: rely on odr mask to know if odr can be set commit e450e07c14abae563ad13b064cbce9fdccc6bc8d upstream. Indeed, relying on addr being not 0 cannot work because some device have their register to set odr at address 0. As a matter of fact, if the odr can be set, then there is a mask. Sensors with ODR register at address 0 are: lsm303dlh, lsm303dlhc, lsm303dlm Fixes: 7d245172675a ("iio: common: st_sensors: check odr address value in st_sensors_set_odr()") Signed-off-by: Lary Gibaud Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 14952589c9d8061a6592f025e40ea542c89e29cc Author: Lars Engebretsen Date: Wed Apr 15 12:10:43 2020 +0200 iio: core: remove extra semi-colon from devm_iio_device_register() macro commit a07479147be03d2450376ebaff9ea1a0682f25d6 upstream. This change removes the semi-colon from the devm_iio_device_register() macro which seems to have been added by accident. Fixes: 63b19547cc3d9 ("iio: Use macro magic to avoid manual assign of driver_module") Signed-off-by: Lars Engebretsen Cc: Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 12c02c473e86ece6600e3b65794c2e10d27a192b Author: Takashi Iwai Date: Wed Apr 22 13:33:20 2020 +0200 ALSA: usb-audio: Add connector notifier delegation [ Upstream commit fef66ae73a611e84c8b4b74ff6f805ec5f113477 ] It turned out that ALC1220-VB USB-audio device gives the interrupt event to some PCM terminals while those don't allow the connector state request but only the actual I/O terminals return the request. The recent commit 7dc3c5a0172e ("ALSA: usb-audio: Don't create jack controls for PCM terminals") excluded those phantom terminals, so those events are ignored, too. My first thought was that this could be easily deduced from the associated terminals, but some of them have even no associate terminal ID, hence it's not too trivial to figure out. Since the number of such terminals are small and limited, this patch implements another quirk table for the simple mapping of the connectors. It's not really scalable, but let's hope that there will be not many such funky devices in future. Fixes: 7dc3c5a0172e ("ALSA: usb-audio: Don't create jack controls for PCM terminals") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Link: https://lore.kernel.org/r/20200422113320.26664-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6ec99b94a3a035ba18114f858d41cbbdd0d4109b Author: Takashi Iwai Date: Mon Apr 20 08:20:36 2020 +0200 ALSA: usb-audio: Add static mapping table for ALC1220-VB-based mobos [ Upstream commit a43c1c41bc5145971d06edc42a6b1e8faa0e2bc3 ] TRX40 mobos from MSI and others with ALC1220-VB USB-audio device need yet more quirks for the proper control names. This patch provides the mapping table for those boards, correcting the FU names for volume and mute controls as well as the terminal names for jack controls. It also improves build_connector_control() not to add the directional suffix blindly if the string is given from the mapping table. With this patch applied, the new UCM profiles will be effective. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Link: https://lore.kernel.org/r/20200420062036.28567-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 23abb5f2faeaf436705b960cded5748f263cb1b7 Author: Takashi Iwai Date: Sun Apr 19 09:19:26 2020 +0200 ALSA: hda: Remove ASUS ROG Zenith from the blacklist [ Upstream commit a8cf44f085ac12c0b5b8750ebb3b436c7f455419 ] The commit 3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") added a new blacklist for the devices that are known to have empty codecs, and one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f). However, it turned out that the very same PCI SSID is used for the previous model that does have the valid HD-audio codecs and the change broke the sound on it. This patch reverts the corresponding entry as a temporary solution. Although Zenith II and co will see get the empty HD-audio bus again, it'd be merely resource wastes and won't affect the functionality, so it's no end of the world. We'll need to address this later, e.g. by either switching to DMI string matching or using PCI ID & SSID pairs. Fixes: 3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") Reported-by: Johnathan Smithinovic Cc: Link: https://lore.kernel.org/r/20200419071926.22683-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 419d8fb1630cbb04883fc73e08f37400a1e8ce86 Author: Waiman Long Date: Sat Mar 21 21:11:25 2020 -0400 KEYS: Avoid false positive ENOMEM error on key read [ Upstream commit 4f0882491a148059a52480e753b7f07fc550e188 ] By allocating a kernel buffer with a user-supplied buffer length, it is possible that a false positive ENOMEM error may be returned because the user-supplied length is just too large even if the system do have enough memory to hold the actual key data. Moreover, if the buffer length is larger than the maximum amount of memory that can be returned by kmalloc() (2^(MAX_ORDER-1) number of pages), a warning message will also be printed. To reduce this possibility, we set a threshold (PAGE_SIZE) over which we do check the actual key length first before allocating a buffer of the right size to hold it. The threshold is arbitrary, it is just used to trigger a buffer length check. It does not limit the actual key length as long as there is enough memory to satisfy the memory request. To further avoid large buffer allocation failure due to page fragmentation, kvmalloc() is used to allocate the buffer so that vmapped pages can be used when there is not a large enough contiguous set of pages available for allocation. In the extremely unlikely scenario that the key keeps on being changed and made longer (still <= buflen) in between 2 __keyctl_read_key() calls, the __keyctl_read_key() calling loop in keyctl_read_key() may have to be iterated a large number of times, but definitely not infinite. Signed-off-by: Waiman Long Signed-off-by: David Howells Signed-off-by: Sasha Levin commit b1bcb485dd6b3644d9c5323e8cf93300cb98a28a Author: David Ahern Date: Mon Apr 20 17:13:52 2020 -0600 vrf: Check skb for XFRM_TRANSFORMED flag [ Upstream commit 16b9db1ce34ff00d6c18e82825125cfef0cdfb13 ] To avoid a loop with qdiscs and xfrms, check if the skb has already gone through the qdisc attached to the VRF device and then to the xfrm layer. If so, no need for a second redirect. Fixes: 193125dbd8eb ("net: Introduce VRF device driver") Reported-by: Trev Larock Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dfbbb4557af4db25fc04ae1f2f2fc624493c507e Author: David Ahern Date: Mon Apr 20 17:13:51 2020 -0600 xfrm: Always set XFRM_TRANSFORMED in xfrm{4,6}_output_finish [ Upstream commit 0c922a4850eba2e668f73a3f1153196e09abb251 ] IPSKB_XFRM_TRANSFORMED and IP6SKB_XFRM_TRANSFORMED are skb flags set by xfrm code to tell other skb handlers that the packet has been passed through the xfrm output functions. Simplify the code and just always set them rather than conditionally based on netfilter enabled thus making the flag available for other users. Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ace87b487a5f107dfaff54ba9f3e146bca107b64 Author: Sabrina Dubroca Date: Wed Apr 22 17:29:51 2020 +0200 geneve: use the correct nlattr array in NL_SET_ERR_MSG_ATTR [ Upstream commit 9a7b5b50de8a764671ba1800fe4c52d3b7013901 ] IFLA_GENEVE_* attributes are in the data array, which is correctly used when fetching the value, but not when setting the extended ack. Because IFLA_GENEVE_MAX < IFLA_MAX, we avoid out of bounds array accesses, but we don't provide a pointer to the invalid attribute to userspace. Fixes: a025fb5f49ad ("geneve: Allow configuration of DF behaviour") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b977fe1c9e80abd302eef1dc44f8b114a4b61382 Author: Sabrina Dubroca Date: Wed Apr 22 17:29:50 2020 +0200 vxlan: use the correct nlattr array in NL_SET_ERR_MSG_ATTR [ Upstream commit cc8e7c69db4dcc565ed3020f97ddd6debab6cbe8 ] IFLA_VXLAN_* attributes are in the data array, which is correctly used when fetching the value, but not when setting the extended ack. Because IFLA_VXLAN_MAX < IFLA_MAX, we avoid out of bounds array accesses, but we don't provide a pointer to the invalid attribute to userspace. Fixes: 653ef6a3e4af ("vxlan: change vxlan_[config_]validate() to use netlink_ext_ack for error reporting") Fixes: b4d3069783bc ("vxlan: Allow configuration of DF behaviour") Signed-off-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 51c935f6c6ef25f2a24c7d7e98a9cdc5b36b410b Author: Florian Fainelli Date: Mon Apr 20 20:26:55 2020 -0700 net: dsa: b53: b53_arl_rw_op() needs to select IVL or SVL [ Upstream commit 64fec9493f7dc9bdd7233bcfe98985c45bd0e3c1 ] Flip the IVL_SVL_SELECT bit correctly based on the VLAN enable status, the default is to perform Shared VLAN learning instead of Individual learning. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cb1a18a7d328732f72b3e69e525b99389a0b4496 Author: Florian Fainelli Date: Mon Apr 20 20:26:54 2020 -0700 net: dsa: b53: Rework ARL bin logic [ Upstream commit 6344dbde6a27d10d16246d734b968f84887841e2 ] When asking the ARL to read a MAC address, we will get a number of bins returned in a single read. Out of those bins, there can essentially be 3 states: - all bins are full, we have no space left, and we can either replace an existing address or return that full condition - the MAC address was found, then we need to return its bin index and modify that one, and only that one - the MAC address was not found and we have a least one bin free, we use that bin index location then The code would unfortunately fail on all counts. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2cc27f102dcdbc218700feb56b5e3182c0efcae9 Author: Florian Fainelli Date: Mon Apr 20 20:26:53 2020 -0700 net: dsa: b53: Fix ARL register definitions [ Upstream commit c2e77a18a7ed65eb48f6e389b6a59a0fd753646a ] The ARL {MAC,VID} tuple and the forward entry were off by 0x10 bytes, which means that when we read/wrote from/to ARL bin index 0, we were actually accessing the ARLA_RWCTRL register. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Reviewed-by: Andrew Lunn Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1fae6eb0fc91d3ecb539e03f9e4dcd1c53ada553 Author: Florian Fainelli Date: Mon Apr 20 20:26:52 2020 -0700 net: dsa: b53: Fix valid setting for MDB entries [ Upstream commit eab167f4851a19c514469dfa81147f77e17b5b20 ] When support for the MDB entries was added, the valid bit was correctly changed to be assigned depending on the remaining port bitmask, that is, if there were no more ports added to the entry's port bitmask, the entry now becomes invalid. There was another assignment a few lines below that would override this which would invalidate entries even when there were still multiple ports left in the MDB entry. Fixes: 5d65b64a3d97 ("net: dsa: b53: Add support for MDB") Reviewed-by: Andrew Lunn Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2537dc9e2c0333838929a775fcdd6ca143738cc0 Author: Florian Fainelli Date: Mon Apr 20 20:26:51 2020 -0700 net: dsa: b53: Lookup VID in ARL searches when VLAN is enabled [ Upstream commit 2e97b0cd1651a270f3a3fcf42115c51f3284c049 ] When VLAN is enabled, and an ARL search is issued, we also need to compare the full {MAC,VID} tuple before returning a successful search result. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Reviewed-by: Andrew Lunn Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 07856b2108cfe82e3bce1e64e3f2dfc1d567eeb1 Author: David Ahern Date: Tue Apr 21 17:48:27 2020 -0600 vrf: Fix IPv6 with qdisc and xfrm [ Upstream commit a53c102872ad6e34e1518e25899dc9498c27f8b1 ] When a qdisc is attached to the VRF device, the packet goes down the ndo xmit function which is setup to send the packet back to the VRF driver which does a lookup to send the packet out. The lookup in the VRF driver is not considering xfrm policies. Change it to use ip6_dst_lookup_flow rather than ip6_route_output. Fixes: 35402e313663 ("net: Add IPv6 support to VRF device") Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 755425c1b004e9297e048b664b2882e27680094a Author: Taehee Yoo Date: Mon Apr 20 15:01:33 2020 +0000 team: fix hang in team_mode_get() [ Upstream commit 1c30fbc76b8f0c07c92a8ca4cd7c456612e17eb5 ] When team mode is changed or set, the team_mode_get() is called to check whether the mode module is inserted or not. If the mode module is not inserted, it calls the request_module(). In the request_module(), it creates a child process, which is the "modprobe" process and waits for the done of the child process. At this point, the following locks were used. down_read(&cb_lock()); by genl_rcv() genl_lock(); by genl_rcv_msc() rtnl_lock(); by team_nl_cmd_options_set() mutex_lock(&team->lock); by team_nl_team_get() Concurrently, the team module could be removed by rmmod or "modprobe -r" The __exit function of team module is team_module_exit(), which calls team_nl_fini() and it tries to acquire following locks. down_write(&cb_lock); genl_lock(); Because of the genl_lock() and cb_lock, this process can't be finished earlier than request_module() routine. The problem secenario. CPU0 CPU1 team_mode_get request_module() modprobe -r team_mode_roundrobin team <--(B) modprobe team <--(A) team_mode_roundrobin By request_module(), the "modprobe team_mode_roundrobin" command will be executed. At this point, the modprobe process will decide that the team module should be inserted before team_mode_roundrobin. Because the team module is being removed. By the module infrastructure, the same module insert/remove operations can't be executed concurrently. So, (A) waits for (B) but (B) also waits for (A) because of locks. So that the hang occurs at this point. Test commands: while : do teamd -d & killall teamd & modprobe -rv team_mode_roundrobin & done The approach of this patch is to hold the reference count of the team module if the team module is compiled as a module. If the reference count of the team module is not zero while request_module() is being called, the team module will not be removed at that moment. So that the above scenario could not occur. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Taehee Yoo Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f642d785a516e51d03462732d34f047cf858be8 Author: Eric Dumazet Date: Fri Apr 17 07:10:23 2020 -0700 tcp: cache line align MAX_TCP_HEADER [ Upstream commit 9bacd256f1354883d3c1402655153367982bba49 ] TCP stack is dumb in how it cooks its output packets. Depending on MAX_HEADER value, we might chose a bad ending point for the headers. If we align the end of TCP headers to cache line boundary, we make sure to always use the smallest number of cache lines, which always help. Signed-off-by: Eric Dumazet Cc: Soheil Hassas Yeganeh Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8a60fad4495d19edf1c4fbf0d46b1a5d539e51b9 Author: David Ahern Date: Tue Apr 21 08:47:24 2020 -0600 selftests: Fix suppress test in fib_tests.sh [ Upstream commit 2c1dd4c110627c2a4f006643f074119205cfcff4 ] fib_tests is spewing errors: ... Cannot open network namespace "ns1": No such file or directory Cannot open network namespace "ns1": No such file or directory Cannot open network namespace "ns1": No such file or directory Cannot open network namespace "ns1": No such file or directory ping: connect: Network is unreachable Cannot open network namespace "ns1": No such file or directory Cannot open network namespace "ns1": No such file or directory ... Each test entry in fib_tests is supposed to do its own setup and cleanup. Right now the $IP commands in fib_suppress_test are failing because there is no ns1. Add the setup/cleanup and logging expected for each test. Fixes: ca7a03c41753 ("ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule") Signed-off-by: David Ahern Cc: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a3afaa5033f4bade05c3b30475b73ece93a9ffa4 Author: Eric Dumazet Date: Tue Apr 21 10:00:28 2020 -0700 sched: etf: do not assume all sockets are full blown [ Upstream commit a1211bf9a7774706722ba3b18c6157d980319f79 ] skb->sk does not always point to a full blown socket, we need to use sk_fullsock() before accessing fields which only make sense on full socket. BUG: KASAN: use-after-free in report_sock_error+0x286/0x300 net/sched/sch_etf.c:141 Read of size 1 at addr ffff88805eb9b245 by task syz-executor.5/9630 CPU: 1 PID: 9630 Comm: syz-executor.5 Not tainted 5.7.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd3/0x315 mm/kasan/report.c:382 __kasan_report.cold+0x35/0x4d mm/kasan/report.c:511 kasan_report+0x33/0x50 mm/kasan/common.c:625 report_sock_error+0x286/0x300 net/sched/sch_etf.c:141 etf_enqueue_timesortedlist+0x389/0x740 net/sched/sch_etf.c:170 __dev_xmit_skb net/core/dev.c:3710 [inline] __dev_queue_xmit+0x154a/0x30a0 net/core/dev.c:4021 neigh_hh_output include/net/neighbour.h:499 [inline] neigh_output include/net/neighbour.h:508 [inline] ip6_finish_output2+0xfb5/0x25b0 net/ipv6/ip6_output.c:117 __ip6_finish_output+0x442/0xab0 net/ipv6/ip6_output.c:143 ip6_finish_output+0x34/0x1f0 net/ipv6/ip6_output.c:153 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip6_output+0x239/0x810 net/ipv6/ip6_output.c:176 dst_output include/net/dst.h:435 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_xmit+0xe1a/0x2090 net/ipv6/ip6_output.c:280 tcp_v6_send_synack+0x4e7/0x960 net/ipv6/tcp_ipv6.c:521 tcp_rtx_synack+0x10d/0x1a0 net/ipv4/tcp_output.c:3916 inet_rtx_syn_ack net/ipv4/inet_connection_sock.c:669 [inline] reqsk_timer_handler+0x4c2/0xb40 net/ipv4/inet_connection_sock.c:763 call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1405 expire_timers kernel/time/timer.c:1450 [inline] __run_timers kernel/time/timer.c:1774 [inline] __run_timers kernel/time/timer.c:1741 [inline] run_timer_softirq+0x623/0x1600 kernel/time/timer.c:1787 __do_softirq+0x26c/0x9f7 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x192/0x1d0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1140 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 RIP: 0010:des_encrypt+0x157/0x9c0 lib/crypto/des.c:792 Code: 85 22 06 00 00 41 31 dc 41 8b 4d 04 44 89 e2 41 83 e4 3f 4a 8d 3c a5 60 72 72 88 81 e2 3f 3f 3f 3f 48 89 f8 48 c1 e8 03 31 d9 <0f> b6 34 28 48 89 f8 c1 c9 04 83 e0 07 83 c0 03 40 38 f0 7c 09 40 RSP: 0018:ffffc90003b5f6c0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13 RAX: 1ffffffff10e4e55 RBX: 00000000d2f846d0 RCX: 00000000d2f846d0 RDX: 0000000012380612 RSI: ffffffff839863ca RDI: ffffffff887272a8 RBP: dffffc0000000000 R08: ffff888091d0a380 R09: 0000000000800081 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000012 R13: ffff8880a8ae8078 R14: 00000000c545c93e R15: 0000000000000006 cipher_crypt_one crypto/cipher.c:75 [inline] crypto_cipher_encrypt_one+0x124/0x210 crypto/cipher.c:82 crypto_cbcmac_digest_update+0x1b5/0x250 crypto/ccm.c:830 crypto_shash_update+0xc4/0x120 crypto/shash.c:119 shash_ahash_update+0xa3/0x110 crypto/shash.c:246 crypto_ahash_update include/crypto/hash.h:547 [inline] hash_sendmsg+0x518/0xad0 crypto/algif_hash.c:102 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x308/0x7e0 net/socket.c:2362 ___sys_sendmsg+0x100/0x170 net/socket.c:2416 __sys_sendmmsg+0x195/0x480 net/socket.c:2506 __do_sys_sendmmsg net/socket.c:2535 [inline] __se_sys_sendmmsg net/socket.c:2532 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2532 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45c829 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f6d9528ec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00000000004fc080 RCX: 000000000045c829 RDX: 0000000000000001 RSI: 0000000020002640 RDI: 0000000000000004 RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000008d7 R14: 00000000004cb7aa R15: 00007f6d9528f6d4 Fixes: 4b15c7075352 ("net/sched: Make etf report drops on error_queue") Fixes: 25db26a91364 ("net/sched: Introduce the ETF Qdisc") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Vinicius Costa Gomes Reviewed-by: Vinicius Costa Gomes Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5a2ddf8e5a5d280fe9399d928db612bf1e4d3b03 Author: Xiyu Yang Date: Thu Apr 23 13:13:03 2020 +0800 net/x25: Fix x25_neigh refcnt leak when receiving frame [ Upstream commit f35d12971b4d814cdb2f659d76b42f0c545270b6 ] x25_lapb_receive_frame() invokes x25_get_neigh(), which returns a reference of the specified x25_neigh object to "nb" with increased refcnt. When x25_lapb_receive_frame() returns, local variable "nb" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one path of x25_lapb_receive_frame(). When pskb_may_pull() returns false, the function forgets to decrease the refcnt increased by x25_get_neigh(), causing a refcnt leak. Fix this issue by calling x25_neigh_put() when pskb_may_pull() returns false. Fixes: cb101ed2c3c7 ("x25: Handle undersized/fragmented skbs") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6885d58eb4392b779d2de0616cfde6aa2e81d552 Author: Marc Zyngier Date: Sat Apr 18 19:14:57 2020 +0100 net: stmmac: dwmac-meson8b: Add missing boundary to RGMII TX clock array [ Upstream commit f0212a5ebfa6cd789ab47666b9cc169e6e688732 ] Running with KASAN on a VIM3L systems leads to the following splat when probing the Ethernet device: ================================================================== BUG: KASAN: global-out-of-bounds in _get_maxdiv+0x74/0xd8 Read of size 4 at addr ffffa000090615f4 by task systemd-udevd/139 CPU: 1 PID: 139 Comm: systemd-udevd Tainted: G E 5.7.0-rc1-00101-g8624b7577b9c #781 Hardware name: amlogic w400/w400, BIOS 2020.01-rc5 03/12/2020 Call trace: dump_backtrace+0x0/0x2a0 show_stack+0x20/0x30 dump_stack+0xec/0x148 print_address_description.isra.12+0x70/0x35c __kasan_report+0xfc/0x1d4 kasan_report+0x4c/0x68 __asan_load4+0x9c/0xd8 _get_maxdiv+0x74/0xd8 clk_divider_bestdiv+0x74/0x5e0 clk_divider_round_rate+0x80/0x1a8 clk_core_determine_round_nolock.part.9+0x9c/0xd0 clk_core_round_rate_nolock+0xf0/0x108 clk_hw_round_rate+0xac/0xf0 clk_factor_round_rate+0xb8/0xd0 clk_core_determine_round_nolock.part.9+0x9c/0xd0 clk_core_round_rate_nolock+0xf0/0x108 clk_core_round_rate_nolock+0xbc/0x108 clk_core_set_rate_nolock+0xc4/0x2e8 clk_set_rate+0x58/0xe0 meson8b_dwmac_probe+0x588/0x72c [dwmac_meson8b] platform_drv_probe+0x78/0xd8 really_probe+0x158/0x610 driver_probe_device+0x140/0x1b0 device_driver_attach+0xa4/0xb0 __driver_attach+0xcc/0x1c8 bus_for_each_dev+0xf4/0x168 driver_attach+0x3c/0x50 bus_add_driver+0x238/0x2e8 driver_register+0xc8/0x1e8 __platform_driver_register+0x88/0x98 meson8b_dwmac_driver_init+0x28/0x1000 [dwmac_meson8b] do_one_initcall+0xa8/0x328 do_init_module+0xe8/0x368 load_module+0x3300/0x36b0 __do_sys_finit_module+0x120/0x1a8 __arm64_sys_finit_module+0x4c/0x60 el0_svc_common.constprop.2+0xe4/0x268 do_el0_svc+0x98/0xa8 el0_svc+0x24/0x68 el0_sync_handler+0x12c/0x318 el0_sync+0x158/0x180 The buggy address belongs to the variable: div_table.63646+0x34/0xfffffffffffffa40 [dwmac_meson8b] Memory state around the buggy address: ffffa00009061480: fa fa fa fa 00 00 00 01 fa fa fa fa 00 00 00 00 ffffa00009061500: 05 fa fa fa fa fa fa fa 00 04 fa fa fa fa fa fa >ffffa00009061580: 00 03 fa fa fa fa fa fa 00 00 00 00 00 00 fa fa ^ ffffa00009061600: fa fa fa fa 00 01 fa fa fa fa fa fa 01 fa fa fa ffffa00009061680: fa fa fa fa 00 01 fa fa fa fa fa fa 04 fa fa fa ================================================================== Digging into this indeed shows that the clock divider array is lacking a final fence, and that the clock subsystems goes in the weeds. Oh well. Let's add the empty structure that indicates the end of the array. Fixes: bd6f48546b9c ("net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs") Signed-off-by: Marc Zyngier Cc: Martin Blumenstingl Reviewed-by: Martin Blumenstingl Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4acc0b18f7af8d98755d30662940f3565f12875a Author: Tonghao Zhang Date: Fri Apr 17 02:57:31 2020 +0800 net: openvswitch: ovs_ct_exit to be done under ovs_lock [ Upstream commit 27de77cec985233bdf6546437b9761853265c505 ] syzbot wrote: | ============================= | WARNING: suspicious RCU usage | 5.7.0-rc1+ #45 Not tainted | ----------------------------- | net/openvswitch/conntrack.c:1898 RCU-list traversed in non-reader section!! | | other info that might help us debug this: | rcu_scheduler_active = 2, debug_locks = 1 | ... | | stack backtrace: | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Workqueue: netns cleanup_net | Call Trace: | ... | ovs_ct_exit | ovs_exit_net | ops_exit_list.isra.7 | cleanup_net | process_one_work | worker_thread To avoid that warning, invoke the ovs_ct_exit under ovs_lock and add lockdep_ovsl_is_held as optional lockdep expression. Link: https://lore.kernel.org/lkml/000000000000e642a905a0cbee6e@google.com Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit") Cc: Pravin B Shelar Cc: Yi-Hung Wei Reported-by: syzbot+7ef50afd3a211f879112@syzkaller.appspotmail.com Signed-off-by: Tonghao Zhang Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 21b1a767eba6568148b226894c06268034f2ea01 Author: Xiyu Yang Date: Wed Apr 15 16:36:19 2020 +0800 net: netrom: Fix potential nr_neigh refcnt leak in nr_add_node [ Upstream commit d03f228470a8c0a22b774d1f8d47071e0de4f6dd ] nr_add_node() invokes nr_neigh_get_dev(), which returns a local reference of the nr_neigh object to "nr_neigh" with increased refcnt. When nr_add_node() returns, "nr_neigh" becomes invalid, so the refcount should be decreased to keep refcount balanced. The issue happens in one normal path of nr_add_node(), which forgets to decrease the refcnt increased by nr_neigh_get_dev() and causes a refcnt leak. It should decrease the refcnt before the function returns like other normal paths do. Fix this issue by calling nr_neigh_put() before the nr_add_node() returns. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit befd63a980cc88677de7b0f13918e7a18fd52ddc Author: Eric Dumazet Date: Wed Apr 15 09:46:52 2020 -0700 net/mlx4_en: avoid indirect call in TX completion [ Upstream commit 310660a14b74c380b0ef5c12b66933d6a3d1b59f ] Commit 9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support") brought another indirect call in fast path. Use INDIRECT_CALL_2() helper to avoid the cost of the indirect call when/if CONFIG_RETPOLINE=y Signed-off-by: Eric Dumazet Cc: Tariq Toukan Cc: Willem de Bruijn Reviewed-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 49bbf322316c6de36c8231ddc3864344a91b1b47 Author: Doug Berger Date: Thu Apr 23 15:44:17 2020 -0700 net: bcmgenet: correct per TX/RX ring statistics [ Upstream commit a6d0b83f25073bdf08b8547aeff961a62c6ab229 ] The change to track net_device_stats per ring to better support SMP missed updating the rx_dropped member. The ndo_get_stats method is also needed to combine the results for ethtool statistics (-S) before filling in the ethtool structure. Fixes: 37a30b435b92 ("net: bcmgenet: Track per TX/RX rings statistics") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit aa6a14bc4102730f20ca706e2d9ccf0e54884138 Author: Dan Carpenter Date: Wed Apr 22 12:36:41 2020 +0300 mlxsw: Fix some IS_ERR() vs NULL bugs [ Upstream commit c391eb8366ae052d571bb2841f1ccb4d39f3ceb8 ] The mlxsw_sp_acl_rulei_create() function is supposed to return an error pointer from mlxsw_afa_block_create(). The problem is that these functions both return NULL instead of error pointers. Half the callers expect NULL and half expect error pointers so it could lead to a NULL dereference on failure. This patch changes both of them to return error pointers and changes all the callers which checked for NULL to check for IS_ERR() instead. Fixes: 4cda7d8d7098 ("mlxsw: core: Introduce flexible actions support") Signed-off-by: Dan Carpenter Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d5ba4c22928f3393352dc5e4b483b51dcad8ddc7 Author: Taehee Yoo Date: Mon Apr 20 13:29:40 2020 +0000 macvlan: fix null dereference in macvlan_device_event() [ Upstream commit 4dee15b4fd0d61ec6bbd179238191e959d34cf7a ] In the macvlan_device_event(), the list_first_entry_or_null() is used. This function could return null pointer if there is no node. But, the macvlan module doesn't check the null pointer. So, null-ptr-deref would occur. bond0 | +----+-----+ | | macvlan0 macvlan1 | | dummy0 dummy1 The problem scenario. If dummy1 is removed, 1. ->dellink() of dummy1 is called. 2. NETDEV_UNREGISTER of dummy1 notification is sent to macvlan module. 3. ->dellink() of macvlan1 is called. 4. NETDEV_UNREGISTER of macvlan1 notification is sent to bond module. 5. __bond_release_one() is called and it internally calls dev_set_mac_address(). 6. dev_set_mac_address() calls the ->ndo_set_mac_address() of macvlan1, which is macvlan_set_mac_address(). 7. macvlan_set_mac_address() calls the dev_set_mac_address() with dummy1. 8. NETDEV_CHANGEADDR of dummy1 is sent to macvlan module. 9. In the macvlan_device_event(), it calls list_first_entry_or_null(). At this point, dummy1 and macvlan1 were removed. So, list_first_entry_or_null() will return NULL. Test commands: ip netns add nst ip netns exec nst ip link add bond0 type bond for i in {0..10} do ip netns exec nst ip link add dummy$i type dummy ip netns exec nst ip link add macvlan$i link dummy$i \ type macvlan mode passthru ip netns exec nst ip link set macvlan$i master bond0 done ip netns del nst Splat looks like: [ 40.585687][ T146] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEI [ 40.587249][ T146] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 40.588342][ T146] CPU: 1 PID: 146 Comm: kworker/u8:2 Not tainted 5.7.0-rc1+ #532 [ 40.589299][ T146] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 40.590469][ T146] Workqueue: netns cleanup_net [ 40.591045][ T146] RIP: 0010:macvlan_device_event+0x4e2/0x900 [macvlan] [ 40.591905][ T146] Code: 00 00 00 00 00 fc ff df 80 3c 06 00 0f 85 45 02 00 00 48 89 da 48 b8 00 00 00 00 00 fc ff d2 [ 40.594126][ T146] RSP: 0018:ffff88806116f4a0 EFLAGS: 00010246 [ 40.594783][ T146] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 40.595653][ T146] RDX: 0000000000000000 RSI: ffff88806547ddd8 RDI: ffff8880540f1360 [ 40.596495][ T146] RBP: ffff88804011a808 R08: fffffbfff4fb8421 R09: fffffbfff4fb8421 [ 40.597377][ T146] R10: ffffffffa7dc2107 R11: 0000000000000000 R12: 0000000000000008 [ 40.598186][ T146] R13: ffff88804011a000 R14: ffff8880540f1000 R15: 1ffff1100c22de9a [ 40.599012][ T146] FS: 0000000000000000(0000) GS:ffff888067800000(0000) knlGS:0000000000000000 [ 40.600004][ T146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 40.600665][ T146] CR2: 00005572d3a807b8 CR3: 000000005fcf4003 CR4: 00000000000606e0 [ 40.601485][ T146] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 40.602461][ T146] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 40.603443][ T146] Call Trace: [ 40.603871][ T146] ? nf_tables_dump_setelem+0xa0/0xa0 [nf_tables] [ 40.604587][ T146] ? macvlan_uninit+0x100/0x100 [macvlan] [ 40.605212][ T146] ? __module_text_address+0x13/0x140 [ 40.605842][ T146] notifier_call_chain+0x90/0x160 [ 40.606477][ T146] dev_set_mac_address+0x28e/0x3f0 [ 40.607117][ T146] ? netdev_notify_peers+0xc0/0xc0 [ 40.607762][ T146] ? __module_text_address+0x13/0x140 [ 40.608440][ T146] ? notifier_call_chain+0x90/0x160 [ 40.609097][ T146] ? dev_set_mac_address+0x1f0/0x3f0 [ 40.609758][ T146] dev_set_mac_address+0x1f0/0x3f0 [ 40.610402][ T146] ? __local_bh_enable_ip+0xe9/0x1b0 [ 40.611071][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding] [ 40.611823][ T146] ? netdev_notify_peers+0xc0/0xc0 [ 40.612461][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding] [ 40.613213][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding] [ 40.613963][ T146] ? __local_bh_enable_ip+0xe9/0x1b0 [ 40.614631][ T146] ? bond_time_in_interval.isra.31+0x90/0x90 [bonding] [ 40.615484][ T146] ? __bond_release_one+0x9f0/0x12c0 [bonding] [ 40.616230][ T146] __bond_release_one+0x9f0/0x12c0 [bonding] [ 40.616949][ T146] ? bond_enslave+0x47c0/0x47c0 [bonding] [ 40.617642][ T146] ? lock_downgrade+0x730/0x730 [ 40.618218][ T146] ? check_flags.part.42+0x450/0x450 [ 40.618850][ T146] ? __mutex_unlock_slowpath+0xd0/0x670 [ 40.619519][ T146] ? trace_hardirqs_on+0x30/0x180 [ 40.620117][ T146] ? wait_for_completion+0x250/0x250 [ 40.620754][ T146] bond_netdev_event+0x822/0x970 [bonding] [ 40.621460][ T146] ? __module_text_address+0x13/0x140 [ 40.622097][ T146] notifier_call_chain+0x90/0x160 [ 40.622806][ T146] rollback_registered_many+0x660/0xcf0 [ 40.623522][ T146] ? netif_set_real_num_tx_queues+0x780/0x780 [ 40.624290][ T146] ? notifier_call_chain+0x90/0x160 [ 40.624957][ T146] ? netdev_upper_dev_unlink+0x114/0x180 [ 40.625686][ T146] ? __netdev_adjacent_dev_unlink_neighbour+0x30/0x30 [ 40.626421][ T146] ? mutex_is_locked+0x13/0x50 [ 40.627016][ T146] ? unregister_netdevice_queue+0xf2/0x240 [ 40.627663][ T146] unregister_netdevice_many.part.134+0x13/0x1b0 [ 40.628362][ T146] default_device_exit_batch+0x2d9/0x390 [ 40.628987][ T146] ? unregister_netdevice_many+0x40/0x40 [ 40.629615][ T146] ? dev_change_net_namespace+0xcb0/0xcb0 [ 40.630279][ T146] ? prepare_to_wait_exclusive+0x2e0/0x2e0 [ 40.630943][ T146] ? ops_exit_list.isra.9+0x97/0x140 [ 40.631554][ T146] cleanup_net+0x441/0x890 [ ... ] Fixes: e289fd28176b ("macvlan: fix the problem when mac address changes for passthru mode") Reported-by: syzbot+5035b1f9dc7ea4558d5a@syzkaller.appspotmail.com Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 70a37b9816f364225059a35b3edf906e64e247d8 Author: Taehee Yoo Date: Thu Apr 23 13:40:47 2020 +0000 macsec: avoid to set wrong mtu [ Upstream commit 7f327080364abccf923fa5a5b24e038eb0ba1407 ] When a macsec interface is created, the mtu is calculated with the lower interface's mtu value. If the mtu of lower interface is lower than the length, which is needed by macsec interface, macsec's mtu value will be overflowed. So, if the lower interface's mtu is too low, macsec interface's mtu should be set to 0. Test commands: ip link add dummy0 mtu 10 type dummy ip link add macsec0 link dummy0 type macsec ip link show macsec0 Before: 11: macsec0@dummy0: mtu 4294967274 After: 11: macsec0@dummy0: mtu 0 Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2d197d8e1aa409e86aa5f6f7a00b3616dde2add2 Author: John Haxby Date: Sat Apr 18 16:30:49 2020 +0100 ipv6: fix restrict IPV6_ADDRFORM operation [ Upstream commit 82c9ae440857840c56e05d4fb1427ee032531346 ] Commit b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation") fixed a problem found by syzbot an unfortunate logic error meant that it also broke IPV6_ADDRFORM. Rearrange the checks so that the earlier test is just one of the series of checks made before moving the socket from IPv6 to IPv4. Fixes: b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation") Signed-off-by: John Haxby Cc: stable@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 382f57b996aa90dcfb13b02fcadeeb3c264cb996 Author: David Ahern Date: Wed Apr 22 15:40:20 2020 -0600 ipv4: Update fib_select_default to handle nexthop objects [ Upstream commit 7c74b0bec918c1e0ca0b4208038c156eacf8f13f ] A user reported [0] hitting the WARN_ON in fib_info_nh: [ 8633.839816] ------------[ cut here ]------------ [ 8633.839819] WARNING: CPU: 0 PID: 1719 at include/net/nexthop.h:251 fib_select_path+0x303/0x381 ... [ 8633.839846] RIP: 0010:fib_select_path+0x303/0x381 ... [ 8633.839848] RSP: 0018:ffffb04d407f7d00 EFLAGS: 00010286 [ 8633.839850] RAX: 0000000000000000 RBX: ffff9460b9897ee8 RCX: 00000000000000fe [ 8633.839851] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000000000000000 [ 8633.839852] RBP: ffff946076049850 R08: 0000000059263a83 R09: ffff9460840e4000 [ 8633.839853] R10: 0000000000000014 R11: 0000000000000000 R12: ffffb04d407f7dc0 [ 8633.839854] R13: ffffffffa4ce3240 R14: 0000000000000000 R15: ffff9460b7681f60 [ 8633.839857] FS: 00007fcac2e02700(0000) GS:ffff9460bdc00000(0000) knlGS:0000000000000000 [ 8633.839858] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8633.839859] CR2: 00007f27beb77e28 CR3: 0000000077734000 CR4: 00000000000006f0 [ 8633.839867] Call Trace: [ 8633.839871] ip_route_output_key_hash_rcu+0x421/0x890 [ 8633.839873] ip_route_output_key_hash+0x5e/0x80 [ 8633.839876] ip_route_output_flow+0x1a/0x50 [ 8633.839878] __ip4_datagram_connect+0x154/0x310 [ 8633.839880] ip4_datagram_connect+0x28/0x40 [ 8633.839882] __sys_connect+0xd6/0x100 ... The WARN_ON is triggered in fib_select_default which is invoked when there are multiple default routes. Update the function to use fib_info_nhc and convert the nexthop checks to use fib_nh_common. Add test case that covers the affected code path. [0] https://github.com/FRRouting/frr/issues/6089 Fixes: 493ced1ac47c ("ipv4: Allow routes to use nexthop objects") Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3b759befd7f2fa65c9f02c6e4f2d5faf00c33fe9 Author: Rahul Lakkireddy Date: Mon Apr 20 15:26:54 2020 +0530 cxgb4: fix large delays in PTP synchronization [ Upstream commit bd019427bf3623ee3c7d2845cf921bbf4c14846c ] Fetching PTP sync information from mailbox is slow and can take up to 10 milliseconds. Reduce this unnecessary delay by directly reading the information from the corresponding registers. Fixes: 9c33e4208bce ("cxgb4: Add PTP Hardware Clock (PHC) support") Signed-off-by: Manoj Malviya Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d02f4242650dc84843f5e636d463e291bf21d840 Author: Vishal Kulkarni Date: Wed Apr 22 21:20:07 2020 +0530 cxgb4: fix adapter crash due to wrong MC size [ Upstream commit ce222748078592afb51b810dc154531aeba4f512 ] In the absence of MC1, the size calculation function cudbg_mem_region_size() was returing wrong MC size and resulted in adapter crash. This patch adds new argument to cudbg_mem_region_size() which will have actual size and returns error to caller in the absence of MC1. Fixes: a1c69520f785 ("cxgb4: collect MC memory dump") Signed-off-by: Vishal Kulkarni " Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 91097eba10d3ea2b1b0a74af5ff299a49156fbf2 Author: Mika Westerberg Date: Tue Nov 26 16:51:50 2019 +0800 PCI/PM: Add missing link delays required by the PCIe spec [ Upstream commit ad9001f2f41198784b0423646450ba2cb24793a3 ] Currently Linux does not follow PCIe spec regarding the required delays after reset. A concrete example is a Thunderbolt add-in-card that consists of a PCIe switch and two PCIe endpoints: +-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller +-01.0-[04-36]-- DS hotplug port +-02.0-[37]----00.0 xHCI controller \-04.0-[38-6b]-- DS hotplug port The root port (1b.0) and the PCIe switch downstream ports are all PCIe Gen3 so they support 8GT/s link speeds. We wait for the PCIe hierarchy to enter D3cold (runtime): pcieport 0000:00:1b.0: power state changed by ACPI to D3cold When it wakes up from D3cold, according to the PCIe 5.0 section 5.8 the PCIe switch is put to reset and its power is re-applied. This means that we must follow the rules in PCIe 5.0 section 6.6.1. For the PCIe Gen3 ports we are dealing with here, the following applies: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Translating this into the above topology we would need to do this (DLLLA stands for Data Link Layer Link Active): 0000:00:1b.0: wait for 100 ms after DLLLA is set before access to 0000:01:00.0 0000:02:00.0: wait for 100 ms after DLLLA is set before access to 0000:03:00.0 0000:02:02.0: wait for 100 ms after DLLLA is set before access to 0000:37:00.0 I've instrumented the kernel with some additional logging so we can see the actual delays performed: pcieport 0000:00:1b.0: power state changed by ACPI to D0 pcieport 0000:00:1b.0: waiting for D3cold delay of 100 ms pcieport 0000:00:1b.0: waiting for D3hot delay of 10 ms pcieport 0000:02:01.0: waiting for D3hot delay of 10 ms pcieport 0000:02:04.0: waiting for D3hot delay of 10 ms For the switch upstream port (01:00.0 reachable through 00:1b.0 root port) we wait for 100 ms but not taking into account the DLLLA requirement. We then wait 10 ms for D3hot -> D0 transition of the root port and the two downstream hotplug ports. This means that we deviate from what the spec requires. Performing the same check for system sleep (s2idle) transitions it turns out to be even worse. None of the mandatory delays are performed. If this would be S3 instead of s2idle then according to PCI FW spec 3.2 section 4.6.8. there is a specific _DSM that allows the OS to skip the delays but this platform does not provide the _DSM and does not go to S3 anyway so no firmware is involved that could already handle these delays. On this particular platform these delays are not actually needed because there is an additional delay as part of the ACPI power resource that is used to turn on power to the hierarchy but since that additional delay is not required by any of standards (PCIe, ACPI) it is not present in the Intel Ice Lake, for example where missing the mandatory delays causes pciehp to start tearing down the stack too early (links are not yet trained). Below is an example how it looks like when this happens: pcieport 0000:83:04.0: pciehp: Slot(4): Card not present pcieport 0000:87:04.0: PME# disabled pcieport 0000:83:04.0: pciehp: pciehp_unconfigure_device: domain:bus:dev = 0000:86:00 pcieport 0000:86:00.0: Refused to change power state, currently in D3 pcieport 0000:86:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x201ff) pcieport 0000:86:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0) ... There is also one reported case (see the bugzilla link below) where the missing delay causes xHCI on a Titan Ridge controller fail to runtime resume when USB-C dock is plugged. This does not involve pciehp but instead the PCI core fails to runtime resume the xHCI device: pcieport 0000:04:02.0: restoring config space at offset 0xc (was 0x10000, writing 0x10020) pcieport 0000:04:02.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100406) xhci_hcd 0000:39:00.0: Refused to change power state, currently in D3 xhci_hcd 0000:39:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x1ff) xhci_hcd 0000:39:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0) ... Add a new function pci_bridge_wait_for_secondary_bus() that is called on PCI core resume and runtime resume paths accordingly if the bridge entered D3cold (and thus went through reset). This is second attempt to add the missing delays. The previous solution in c2bf1fc212f7 ("PCI: Add missing link delays required by the PCIe spec") was reverted because of two issues it caused: 1. One system become unresponsive after S3 resume due to PME service spinning in pcie_pme_work_fn(). The root port in question reports that the xHCI sent PME but the xHCI device itself does not have PME status set. The PME status bit is never cleared in the root port resulting the indefinite loop in pcie_pme_work_fn(). 2. Slows down resume if the root/downstream port does not support Data Link Layer Active Reporting because pcie_wait_for_link_delay() waits 1100 ms in that case. This version should avoid the above issues because we restrict the delay to happen only if the port went into D3cold. Link: https://lore.kernel.org/linux-pci/SL2P216MB01878BBCD75F21D882AEEA2880C60@SL2P216MB0187.KORP216.PROD.OUTLOOK.COM/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=203885 Link: https://lore.kernel.org/r/20191112091617.70282-3-mika.westerberg@linux.intel.com Reported-by: Kai-Heng Feng Tested-by: Kai-Heng Feng Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 7720fd9c679ec839448480ad5cc548570a97bbf7 Author: Heiner Kallweit Date: Sat Oct 5 14:03:57 2019 +0200 PCI/ASPM: Allow re-enabling Clock PM [ Upstream commit 35efea32b26f9aacc99bf07e0d2cdfba2028b099 ] Previously Clock PM could not be re-enabled after being disabled by pci_disable_link_state() because clkpm_capable was reset. Change this by adding a clkpm_disable field similar to aspm_disable. Link: https://lore.kernel.org/r/4e8a66db-7d53-4a66-c26c-f0037ffaa705@gmail.com Signed-off-by: Heiner Kallweit Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 3340d011cff4948daef09ae85c71f9a966f60d7f Author: Kevin Barnett Date: Mon Oct 7 17:31:58 2019 -0500 scsi: smartpqi: fix problem with unique ID for physical device [ Upstream commit 5b083b305b49f65269b888885455b8c0cf1a52e4 ] Obtain the unique IDs from the RLL and RPL instead of VPD page 83h. Link: https://lore.kernel.org/r/157048751833.11757.11996314786914610803.stgit@brunhilda Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Signed-off-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d867f2757173189abdd902b5ad62fdc9e0737b21 Author: Murthy Bhat Date: Mon Oct 7 17:31:28 2019 -0500 scsi: smartpqi: fix call trace in device discovery [ Upstream commit b969261134c1b990b96ea98fe5e0fcf8ec937c04 ] Use sas_phy_delete rather than sas_phy_free which, according to comments, should not be called for PHYs that have been set up successfully. Link: https://lore.kernel.org/r/157048748876.11757.17773443136670011786.stgit@brunhilda Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Kevin Barnett Signed-off-by: Murthy Bhat Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8a20fb1c9a4982ab030009eb81c5880b67a33814 Author: Kevin Barnett Date: Mon Oct 7 17:31:23 2019 -0500 scsi: smartpqi: fix controller lockup observed during force reboot [ Upstream commit 0530736e40a0695b1ee2762e2684d00549699da4 ] Link: https://lore.kernel.org/r/157048748297.11757.3872221216800537383.stgit@brunhilda Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Signed-off-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3edd55247295f6ee7453e759502972caa39c66a4 Author: Halil Pasic Date: Thu Feb 13 13:37:28 2020 +0100 virtio-blk: improve virtqueue error to BLK_STS [ Upstream commit 3d973b2e9a625996ee997c7303cd793b9d197c65 ] Let's change the mapping between virtqueue_add errors to BLK_STS statuses, so that -ENOSPC, which indicates virtqueue full is still mapped to BLK_STS_DEV_RESOURCE, but -ENOMEM which indicates non-device specific resource outage is mapped to BLK_STS_RESOURCE. Signed-off-by: Halil Pasic Link: https://lore.kernel.org/r/20200213123728.61216-3-pasic@linux.ibm.com Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefan Hajnoczi Signed-off-by: Sasha Levin commit 2390698b9dbdd8971397d6d19d90229bb973c669 Author: Steven Rostedt (VMware) Date: Wed Nov 13 11:48:39 2019 -0500 tracing/selftests: Turn off timeout setting [ Upstream commit b43e78f65b1d35fd3e13c7b23f9b64ea83c9ad3a ] As the ftrace selftests can run for a long period of time, disable the timeout that the general selftests have. If a selftest hangs, then it probably means the machine will hang too. Link: https://lore.kernel.org/r/alpine.LSU.2.21.1911131604170.18679@pobox.suse.cz Suggested-by: Miroslav Benes Tested-by: Miroslav Benes Reviewed-by: Miroslav Benes Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit ca958fe8af205e900cab8d2793c54fabc04c0f94 Author: Kai Vehmanen Date: Fri Jan 24 15:36:22 2020 -0600 ASoC: SOF: trace: fix unconditional free in trace release [ Upstream commit e6110114d18d330c05fd6de9f31283fd086a5a3a ] Check if DMA pages were successfully allocated in initialization before calling free. For many types of memory (like sgbufs) the extra free is harmless, but not all backends track allocation state, so add an explicit check. Signed-off-by: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200124213625.30186-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 01fad934f1bdca50a952b3347f4e234a3e1e4ff8 Author: Mika Westerberg Date: Tue Oct 29 20:00:22 2019 +0300 PCI: pciehp: Prevent deadlock on disconnect [ Upstream commit 87d0f2a5536fdf5053a6d341880f96135549a644 ] This addresses deadlocks in these common cases in hierarchies containing two switches: - All involved ports are runtime suspended and they are unplugged. This can happen easily if the drivers involved automatically enable runtime PM (xHCI for example does that). - System is suspended (e.g., closing the lid on a laptop) with a dock + something else connected, and the dock is unplugged while suspended. These cases lead to the following deadlock: INFO: task irq/126-pciehp:198 blocked for more than 120 seconds. irq/126-pciehp D 0 198 2 0x80000000 Call Trace: schedule+0x2c/0x80 schedule_timeout+0x246/0x350 wait_for_completion+0xb7/0x140 kthread_stop+0x49/0x110 free_irq+0x32/0x70 pcie_shutdown_notification+0x2f/0x50 pciehp_remove+0x27/0x50 pcie_port_remove_service+0x36/0x50 device_release_driver+0x12/0x20 bus_remove_device+0xec/0x160 device_del+0x13b/0x350 device_unregister+0x1a/0x60 remove_iter+0x1e/0x30 device_for_each_child+0x56/0x90 pcie_port_device_remove+0x22/0x40 pcie_portdrv_remove+0x20/0x60 pci_device_remove+0x3e/0xc0 device_release_driver_internal+0x18c/0x250 device_release_driver+0x12/0x20 pci_stop_bus_device+0x6f/0x90 pci_stop_bus_device+0x31/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pciehp_unconfigure_device+0x88/0x140 pciehp_disable_slot+0x6a/0x110 pciehp_handle_presence_or_link_change+0x263/0x400 pciehp_ist+0x1c9/0x1d0 irq_thread_fn+0x24/0x60 irq_thread+0xeb/0x190 kthread+0x120/0x140 INFO: task irq/190-pciehp:2288 blocked for more than 120 seconds. irq/190-pciehp D 0 2288 2 0x80000000 Call Trace: __schedule+0x2a2/0x880 schedule+0x2c/0x80 schedule_preempt_disabled+0xe/0x10 mutex_lock+0x2c/0x30 pci_lock_rescan_remove+0x15/0x20 pciehp_unconfigure_device+0x4d/0x140 pciehp_disable_slot+0x6a/0x110 pciehp_handle_presence_or_link_change+0x263/0x400 pciehp_ist+0x1c9/0x1d0 irq_thread_fn+0x24/0x60 irq_thread+0xeb/0x190 kthread+0x120/0x140 What happens here is that the whole hierarchy is runtime resumed and the parent PCIe downstream port, which got the hot-remove event, starts removing devices below it, taking pci_lock_rescan_remove() lock. When the child PCIe port is runtime resumed it calls pciehp_check_presence() which ends up calling pciehp_card_present() and pciehp_check_link_active(). Both of these use pcie_capability_read_word(), which notices that the underlying device is already gone and returns PCIBIOS_DEVICE_NOT_FOUND with the capability value set to 0. When pciehp gets this value it thinks that its child device is also hot-removed and schedules its IRQ thread to handle the event. The deadlock happens when the child's IRQ thread runs and tries to acquire pci_lock_rescan_remove() which is already taken by the parent and the parent waits for the child's IRQ thread to finish. Prevent this from happening by checking the return value of pcie_capability_read_word() and if it is PCIBIOS_DEVICE_NOT_FOUND stop performing any hot-removal activities. [bhelgaas: add common scenarios to commit log] Link: https://lore.kernel.org/r/20191029170022.57528-2-mika.westerberg@linux.intel.com Tested-by: Kai-Heng Feng Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 39b9a0b3d24daba1090019d1ba1a18454bf4aab1 Author: Aurelien Jarno Date: Sun Dec 1 20:57:28 2019 +0100 libbpf: Fix readelf output parsing on powerpc with recent binutils [ Upstream commit 3464afdf11f9a1e031e7858a05351ceca1792fea ] On powerpc with recent versions of binutils, readelf outputs an extra field when dumping the symbols of an object file. For example: 35: 0000000000000838 96 FUNC LOCAL DEFAULT [: 8] 1 btf_is_struct The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to be computed correctly and causes the check_abi target to fail. Fix that by looking for the symbol name in the last field instead of the 8th one. This way it should also cope with future extra fields. Signed-off-by: Aurelien Jarno Signed-off-by: Daniel Borkmann Tested-by: Michael Ellerman Link: https://lore.kernel.org/bpf/20191201195728.4161537-1-aurelien@aurel32.net Signed-off-by: Sasha Levin commit b91ae599472563891689b167c77ad3a32795752a Author: Mika Westerberg Date: Tue Nov 12 12:16:16 2019 +0300 PCI/PM: Add pcie_wait_for_link_delay() [ Upstream commit 4827d63891b6a839dac49c6ab62e61c4b011c4f2 ] Add pcie_wait_for_link_delay(). Similar to pcie_wait_for_link() but allows passing custom activation delay in milliseconds. Link: https://lore.kernel.org/r/20191112091617.70282-2-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit df38cda0144a1e6d2ec7c768f53a4744ec3ff18d Author: Yongqiang Sun Date: Mon Mar 9 17:13:02 2020 -0400 drm/amd/display: Not doing optimize bandwidth if flip pending. [ Upstream commit 9941b8129030c9202aaf39114477a0e58c0d6ffc ] [Why] In some scenario like 1366x768 VSR enabled connected with a 4K monitor and playing 4K video in clone mode, underflow will be observed due to decrease dppclk when previouse surface scan isn't finished [How] In this use case, surface flip is switching between 4K and 1366x768, 1366x768 needs smaller dppclk, and when decrease the clk and previous surface scan is for 4K and scan isn't done, underflow will happen. Not doing optimize bandwidth in case of flip pending. Signed-off-by: Yongqiang Sun Reviewed-by: Tony Cheng Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2be21320076de0b23efb1f3d2103e1b3cd307b74 Author: Mathias Nyman Date: Thu Mar 12 16:45:16 2020 +0200 xhci: Finetune host initiated USB3 rootport link suspend and resume [ Upstream commit ceca49382ac20e06ce04c21279c7f2868c4ec1d4 ] Depending on the current link state the steps to resume the link to U0 varies. The normal case when a port is suspended (U3) we set the link to U0 and wait for a port event when U3exit completed and port moved to U0. If the port is in U1/U2, then no event is issued, just set link to U0 If port is in Resume or Recovery state then the device has already initiated resume, and this host initiated resume is racing against it. Port event handler for device initiated resume will set link to U0, just wait for the port to reach U0 before returning. Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200312144517.1593-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ea6f7011c42db70b6380480d0561d8f9402d6f76 Author: Kai-Heng Feng Date: Thu Mar 12 16:45:15 2020 +0200 xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0 [ Upstream commit 0200b9f790b0fc9e9a42f685f5ad54b23fe959f4 ] Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition time. The 20ms is not enough for some devices. Intead of polling PLS or PLC, we can facilitate the port change event to know that the link transits to U0 is completed. While at it, also separate U0 and U3 case to make the code cleaner. [variable rename to u3exit, and skip completion for usb2 ports -Mathias ] Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200312144517.1593-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e650a264df6f72701874f6eab11fdb28a861515e Author: Kai-Heng Feng Date: Thu Mar 12 16:45:14 2020 +0200 xhci: Ensure link state is U3 after setting USB_SS_PORT_LS_U3 [ Upstream commit eb002726fac7cefb98ff39ddb89e150a1c24fe85 ] The xHCI spec doesn't specify the upper bound of U3 transition time. For some devices 20ms is not enough, so we need to make sure the link state is in U3 before further actions. I've tried to use U3 Entry Capability by setting U3 Entry Enable in config register, however the port change event for U3 transition interrupts the system suspend process. For now let's use the less ideal method by polling PLS. [use usleep_range(), and shorten the delay time while polling -Mathias] Signed-off-by: Kai-Heng Feng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20200312144517.1593-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bdb61374da1b13b565912d35d339ae2699e45e6c Author: František Kučera Date: Wed Apr 1 11:59:07 2020 +0200 ALSA: usb-audio: Add Pioneer DJ DJM-250MK2 quirk [ Upstream commit 73d8c94084341e2895169a0462dbc18167f01683 ] Pioneer DJ DJM-250MK2 is a mixer that acts like a USB sound card. The MIDI controller part is standard but the PCM part is "vendor specific". Output is enabled by this quirk: 8 channels, 48 000 Hz, S24_3LE. Input is not working. Signed-off-by: František Kučera Link: https://lore.kernel.org/r/20200401095907.3387-1-konference@frantovo.cz Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 578aa47612f2d721fc2afbdab1e796af80f78d72 Author: Hans de Goede Date: Sun Apr 5 15:37:26 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for MPMAN MPWIN895CL tablet [ Upstream commit c8b78f24c1247b7bd0882885c672d9dec5800bc6 ] The MPMAN MPWIN895CL tablet almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost. Add a quirk for this model using the default settings + MONO_SPEAKER. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200405133726.24154-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 632d9736d215805bf1482e57e9db2e4c30237dd9 Author: Nicholas Kazlauskas Date: Sun Apr 5 16:40:57 2020 -0400 drm/amd/display: Calculate scaling ratios on every medium/full update [ Upstream commit 3bae20137cae6c03f58f96c0bc9f3d46f0bc17d4 ] [Why] If a plane isn't being actively enabled or disabled then DC won't always recalculate scaling rects and ratios for the primary plane. This results in only a partial or corrupted rect being displayed on the screen instead of scaling to fit the screen. [How] Add back the logic to recalculate the scaling rects into dc_commit_updates_for_stream since this is the expected place to do it in DC. This was previously removed a few years ago to fix an underscan issue but underscan is still functional now with this change - and it should be, since this is only updating to the latest plane state getting passed in. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Aric Cyr Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 16c370534d6c483978e18ef7ca02ae7b22d480f4 Author: Jiri Olsa Date: Tue Apr 7 16:14:27 2020 +0200 perf/core: Disable page faults when getting phys address [ Upstream commit d3296fb372bf7497b0e5d0478c4e7a677ec6f6e9 ] We hit following warning when running tests on kernel compiled with CONFIG_DEBUG_ATOMIC_SLEEP=y: WARNING: CPU: 19 PID: 4472 at mm/gup.c:2381 __get_user_pages_fast+0x1a4/0x200 CPU: 19 PID: 4472 Comm: dummy Not tainted 5.6.0-rc6+ #3 RIP: 0010:__get_user_pages_fast+0x1a4/0x200 ... Call Trace: perf_prepare_sample+0xff1/0x1d90 perf_event_output_forward+0xe8/0x210 __perf_event_overflow+0x11a/0x310 __intel_pmu_pebs_event+0x657/0x850 intel_pmu_drain_pebs_nhm+0x7de/0x11d0 handle_pmi_common+0x1b2/0x650 intel_pmu_handle_irq+0x17b/0x370 perf_event_nmi_handler+0x40/0x60 nmi_handle+0x192/0x590 default_do_nmi+0x6d/0x150 do_nmi+0x2f9/0x3c0 nmi+0x8e/0xd7 While __get_user_pages_fast() is IRQ-safe, it calls access_ok(), which warns on: WARN_ON_ONCE(!in_task() && !pagefault_disabled()) Peter suggested disabling page faults around __get_user_pages_fast(), which gets rid of the warning in access_ok() call. Suggested-by: Peter Zijlstra Signed-off-by: Jiri Olsa Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20200407141427.3184722-1-jolsa@kernel.org Signed-off-by: Sasha Levin commit 41a3e446bc5676da04925cdd457b5ec49d69634d Author: Florian Fainelli Date: Mon Feb 3 13:35:35 2020 -0800 pwm: bcm2835: Dynamically allocate base [ Upstream commit 2c25b07e5ec119cab609e41407a1fb3fa61442f5 ] The newer 2711 and 7211 chips have two PWM controllers and failure to dynamically allocate the PWM base would prevent the second PWM controller instance being probed for succeeding with an -EEXIST error from alloc_pwms(). Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver") Signed-off-by: Florian Fainelli Acked-by: Uwe Kleine-König Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 53cdc935c912fc8474c5613c0f182ac39d05c5d7 Author: Geert Uytterhoeven Date: Mon Mar 16 11:32:15 2020 +0100 pwm: renesas-tpu: Fix late Runtime PM enablement [ Upstream commit d5a3c7a4536e1329a758e14340efd0e65252bd3d ] Runtime PM should be enabled before calling pwmchip_add(), as PWM users can appear immediately after the PWM chip has been added. Likewise, Runtime PM should always be disabled after the removal of the PWM chip, even if the latter failed. Fixes: 99b82abb0a35b073 ("pwm: Add Renesas TPU PWM driver") Signed-off-by: Geert Uytterhoeven Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 1bfb6423c6fc58cedadceaf5ce8e17a20890e826 Author: Nick Bowler Date: Sat Mar 28 01:09:09 2020 -0400 nvme: fix compat address handling in several ioctls [ Upstream commit c95b708d5fa65b4e51f088ee077d127fd5a57b70 ] On a 32-bit kernel, the upper bits of userspace addresses passed via various ioctls are silently ignored by the nvme driver. However on a 64-bit kernel running a compat task, these upper bits are not ignored and are in fact required to be zero for the ioctls to work. Unfortunately, this difference matters. 32-bit smartctl submits the NVME_IOCTL_ADMIN_CMD ioctl with garbage in these upper bits because it seems the pointer value it puts into the nvme_passthru_cmd structure is sign extended. This works fine on 32-bit kernels but fails on a 64-bit one because (at least on my setup) the addresses smartctl uses are consistently above 2G. For example: # smartctl -x /dev/nvme0n1 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.5.11] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Bad address Since changing 32-bit kernels to actually check all of the submitted address bits now would break existing userspace, this patch fixes the compat problem by explicitly zeroing the upper bits in the compat case. This enables 32-bit smartctl to work on a 64-bit kernel. Signed-off-by: Nick Bowler Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit de1263d4306e64074a9cd53ad43cee70f586f592 Author: Ganesh Goudar Date: Fri Mar 20 16:31:19 2020 +0530 powerpc/pseries: Fix MCE handling on pseries [ Upstream commit a95a0a1654f16366360399574e10efd87e867b39 ] MCE handling on pSeries platform fails as recent rework to use common code for pSeries and PowerNV in machine check error handling tries to access per-cpu variables in realmode. The per-cpu variables may be outside the RMO region on pSeries platform and needs translation to be enabled for access. Just moving these per-cpu variable into RMO region did'nt help because we queue some work to workqueues in real mode, which again tries to touch per-cpu variables. Also fwnmi_release_errinfo() cannot be called when translation is not enabled. This patch fixes this by enabling translation in the exception handler when all required real mode handling is done. This change only affects the pSeries platform. Without this fix below kernel crash is seen on injecting SLB multihit: BUG: Unable to handle kernel data access on read at 0xc00000027b205950 Faulting instruction address: 0xc00000000003b7e0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mcetest_slb(OE+) af_packet(E) xt_tcpudp(E) ip6t_rpfilter(E) ip6t_REJECT(E) ipt_REJECT(E) xt_conntrack(E) ip_set(E) nfnetlink(E) ebtable_nat(E) ebtable_broute(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) xfs(E) ibmveth(E) vmx_crypto(E) gf128mul(E) uio_pdrv_genirq(E) uio(E) crct10dif_vpmsum(E) rtc_generic(E) btrfs(E) libcrc32c(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) sr_mod(E) sd_mod(E) cdrom(E) ibmvscsi(E) scsi_transport_srp(E) crc32c_vpmsum(E) dm_mod(E) sg(E) scsi_mod(E) CPU: 34 PID: 8154 Comm: insmod Kdump: loaded Tainted: G OE 5.5.0-mahesh #1 NIP: c00000000003b7e0 LR: c0000000000f2218 CTR: 0000000000000000 REGS: c000000007dcb960 TRAP: 0300 Tainted: G OE (5.5.0-mahesh) MSR: 8000000000001003 CR: 28002428 XER: 20040000 CFAR: c0000000000f2214 DAR: c00000027b205950 DSISR: 40000000 IRQMASK: 0 GPR00: c0000000000f2218 c000000007dcbbf0 c000000001544800 c000000007dcbd70 GPR04: 0000000000000001 c000000007dcbc98 c008000000d00258 c0080000011c0000 GPR08: 0000000000000000 0000000300000003 c000000001035950 0000000003000048 GPR12: 000000027a1d0000 c000000007f9c000 0000000000000558 0000000000000000 GPR16: 0000000000000540 c008000001110000 c008000001110540 0000000000000000 GPR20: c00000000022af10 c00000025480fd70 c008000001280000 c00000004bfbb300 GPR24: c000000001442330 c00800000800000d c008000008000000 4009287a77000510 GPR28: 0000000000000000 0000000000000002 c000000001033d30 0000000000000001 NIP [c00000000003b7e0] save_mce_event+0x30/0x240 LR [c0000000000f2218] pseries_machine_check_realmode+0x2c8/0x4f0 Call Trace: Instruction dump: 3c4c0151 38429050 7c0802a6 60000000 fbc1fff0 fbe1fff8 f821ffd1 3d42ffaf 3fc2ffaf e98d0030 394a1150 3bdef530 <7d6a62aa> 1d2b0048 2f8b0063 380b0001 ---[ end trace 46fd63f36bbdd940 ]--- Fixes: 9ca766f9891d ("powerpc/64s/pseries: machine check convert to use common event code") Reviewed-by: Mahesh Salgaonkar Reviewed-by: Nicholas Piggin Signed-off-by: Ganesh Goudar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200320110119.10207-1-ganeshgr@linux.ibm.com Signed-off-by: Sasha Levin commit 107290a8f06bbfcf09b387c296c810517e08715e Author: Nicholas Piggin Date: Thu Apr 2 22:04:01 2020 +1000 Revert "powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled" [ Upstream commit abc3fce76adbdfa8f87272c784b388cd20b46049 ] This reverts commit ebb37cf3ffd39fdb6ec5b07111f8bb2f11d92c5f. That commit does not play well with soft-masked irq state manipulations in idle, interrupt replay, and possibly others due to tracing code sometimes using irq_work_queue (e.g., in trace_hardirqs_on()). That can cause PACA_IRQ_DEC to become set when it is not expected, and be ignored or cleared or cause warnings. The net result seems to be missing an irq_work until the next timer interrupt in the worst case which is usually not going to be noticed, however it could be a long time if the tick is disabled, which is against the spirit of irq_work and might cause real problems. The idea is still solid, but it would need more work. It's not really clear if it would be worth added complexity, so revert this for now (not a straight revert, but replace with a comment explaining why we might see interrupts happening, and gives git blame something to find). Fixes: ebb37cf3ffd3 ("powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200402120401.1115883-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit 1712911bfb34dc86efa079b136def17eb31ef34d Author: Evan Green Date: Fri Apr 3 16:43:04 2020 +0200 loop: Better discard support for block devices [ Upstream commit c52abf563049e787c1341cdf15c7dbe1bfbc951b ] If the backing device for a loop device is itself a block device, then mirror the "write zeroes" capabilities of the underlying block device into the loop device. Copy this capability into both max_write_zeroes_sectors and max_discard_sectors of the loop device. The reason for this is that REQ_OP_DISCARD on a loop device translates into blkdev_issue_zeroout(), rather than blkdev_issue_discard(). This presents a consistent interface for loop devices (that discarded data is zeroed), regardless of the backing device type of the loop device. There should be no behavior change for loop devices backed by regular files. This change fixes blktest block/003, and removes an extraneous error print in block/013 when testing on a loop device backed by a block device that does not support discard. Signed-off-by: Evan Green Reviewed-by: Gwendal Grignou Reviewed-by: Chaitanya Kulkarni [used updated version of Evan's comment in loop_config_discard()] [moved backingq to local scope, removed redundant braces] Signed-off-by: Andrzej Pietrasiewicz Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ed61eec49a702986463ffb31af917bc800c1c6f4 Author: Cornelia Huck Date: Fri Mar 27 13:45:02 2020 +0100 s390/cio: avoid duplicated 'ADD' uevents [ Upstream commit 05ce3e53f375295c2940390b2b429e506e07655c ] The common I/O layer delays the ADD uevent for subchannels and delegates generating this uevent to the individual subchannel drivers. The io_subchannel driver will do so when the associated ccw_device has been registered -- but unconditionally, so more ADD uevents will be generated if a subchannel has been unbound from the io_subchannel driver and later rebound. To fix this, only generate the ADD event if uevents were still suppressed for the device. Fixes: fa1a8c23eb7d ("s390: cio: Delay uevents for subchannels") Message-Id: <20200327124503.9794-2-cohuck@redhat.com> Reported-by: Boris Fiuczynski Reviewed-by: Peter Oberparleiter Reviewed-by: Boris Fiuczynski Signed-off-by: Cornelia Huck Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit ad1187668ffe6d3fbe195bdf9347e98d92e104c4 Author: Cornelia Huck Date: Fri Mar 27 13:45:03 2020 +0100 s390/cio: generate delayed uevent for vfio-ccw subchannels [ Upstream commit 2bc55eaeb88d30accfc1b6ac2708d4e4b81ca260 ] The common I/O layer delays the ADD uevent for subchannels and delegates generating this uevent to the individual subchannel drivers. The vfio-ccw I/O subchannel driver, however, did not do that, and will not generate an ADD uevent for subchannels that had not been bound to a different driver (or none at all, which also triggers the uevent). Generate the ADD uevent at the end of the probe function if uevents were still suppressed for the device. Message-Id: <20200327124503.9794-3-cohuck@redhat.com> Fixes: 63f1934d562d ("vfio: ccw: basic implementation for vfio_ccw driver") Reviewed-by: Eric Farman Signed-off-by: Cornelia Huck Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 8652254e96a6052aed8ed678466de638eba0f3ca Author: Masahiro Yamada Date: Thu Mar 26 17:00:49 2020 +0900 lib/raid6/test: fix build on distros whose /bin/sh is not bash [ Upstream commit 06bd48b6cd97ef3889b68c8e09014d81dbc463f1 ] You can build a user-space test program for the raid6 library code, like this: $ cd lib/raid6/test $ make The command in $(shell ...) function is evaluated by /bin/sh by default. (or, you can specify the shell by passing SHELL= from command line) Currently '>&/dev/null' is used to sink both stdout and stderr. Because this code is bash-ism, it only works when /bin/sh is a symbolic link to bash (this is the case on RHEL etc.) This does not work on Ubuntu where /bin/sh is a symbolic link to dash. I see lots of /bin/sh: 1: Syntax error: Bad fd number and warning "your version of binutils lacks ... support" Replace it with portable '>/dev/null 2>&1'. Fixes: 4f8c55c5ad49 ("lib/raid6: build proper files on corresponding arch") Signed-off-by: Masahiro Yamada Acked-by: H. Peter Anvin (Intel) Reviewed-by: Jason A. Donenfeld Acked-by: Ingo Molnar Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin commit e84ef75fa184fea5142bd8f8d5022bcf496d02ae Author: Mauro Carvalho Chehab Date: Thu Apr 2 11:28:03 2020 +0200 kconfig: qconf: Fix a few alignment issues [ Upstream commit 60969f02f07ae1445730c7b293c421d179da729c ] There are a few items with wrong alignments. Solve them. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit cb5d9604038c8327df021aef89c8b4e5678b44cc Author: Vasily Averin Date: Fri Apr 10 14:34:13 2020 -0700 ipc/util.c: sysvipc_find_ipc() should increase position index [ Upstream commit 89163f93c6f969da5811af5377cc10173583123b ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: Andrew Morton Acked-by: Waiman Long Cc: Davidlohr Bueso Cc: Manfred Spraul Cc: Al Viro Cc: Ingo Molnar Cc: NeilBrown Cc: Peter Oberparleiter Cc: Steven Rostedt Link: http://lkml.kernel.org/r/b7a20945-e315-8bb0-21e6-3875c14a8494@virtuozzo.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 70638a74c52a76405e5b9b8c498c67d772c06f20 Author: Eric Biggers Date: Fri Apr 10 14:33:53 2020 -0700 selftests: kmod: fix handling test numbers above 9 [ Upstream commit 6d573a07528308eb77ec072c010819c359bebf6e ] get_test_count() and get_test_enabled() were broken for test numbers above 9 due to awk interpreting a field specification like '$0010' as octal rather than decimal. Fix it by stripping the leading zeroes. Signed-off-by: Eric Biggers Signed-off-by: Andrew Morton Acked-by: Luis Chamberlain Cc: Alexei Starovoitov Cc: Greg Kroah-Hartman Cc: Jeff Vander Stoep Cc: Jessica Yu Cc: Kees Cook Cc: NeilBrown Link: http://lkml.kernel.org/r/20200318230515.171692-5-ebiggers@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 16846f6fcbcfc0de495305b588e439f08ef28899 Author: Vasily Averin Date: Fri Apr 10 14:34:10 2020 -0700 kernel/gcov/fs.c: gcov_seq_next() should increase position index [ Upstream commit f4d74ef6220c1eda0875da30457bef5c7111ab06 ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: Andrew Morton Acked-by: Peter Oberparleiter Cc: Al Viro Cc: Davidlohr Bueso Cc: Ingo Molnar Cc: Manfred Spraul Cc: NeilBrown Cc: Steven Rostedt Cc: Waiman Long Link: http://lkml.kernel.org/r/f65c6ee7-bd00-f910-2f8a-37cc67e4ff88@virtuozzo.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1edfff795d4f2117a1b95484213cb9fb4a46dc48 Author: Kishon Vijay Abraham I Date: Mon Apr 6 10:58:36 2020 +0530 dma-direct: fix data truncation in dma_direct_get_required_mask() [ Upstream commit cdcda0d1f8f4ab84efe7cd9921c98364398aefd7 ] The upper 32-bit physical address gets truncated inadvertently when dma_direct_get_required_mask() invokes phys_to_dma_direct(). This results in dma_addressing_limited() return incorrect value when used in platforms with LPAE enabled. Fix it here by explicitly type casting 'max_pfn' to phys_addr_t in order to prevent overflow of intermediate value while evaluating '(max_pfn - 1) << PAGE_SHIFT'. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8300465623bfcbafbd01b60eef04ebf037ca42db Author: Isabel Zhang Date: Sun Apr 5 16:41:01 2020 -0400 drm/amd/display: Update stream adjust in dc_stream_adjust_vmin_vmax [ Upstream commit 346d8a0a3c91888a412c2735d69daa09c00f0203 ] [Why] After v_total_min and max are updated in vrr structure, the changes are not reflected in stream adjust. When these values are read from stream adjust it does not reflect the actual state of the system. [How] Set stream adjust values equal to vrr adjust values after vrr adjust values are updated. Signed-off-by: Isabel Zhang Reviewed-by: Alvin Lee Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit da2c733a71800c284c7ce029899b2e5f46b801e8 Author: Sagi Grimberg Date: Thu Apr 2 09:34:54 2020 -0700 nvme: fix deadlock caused by ANA update wrong locking [ Upstream commit 657f1975e9d9c880fa13030e88ba6cc84964f1db ] The deadlock combines 4 flows in parallel: - ns scanning (triggered from reconnect) - request timeout - ANA update (triggered from reconnect) - I/O coming into the mpath device (1) ns scanning triggers disk revalidation -> update disk info -> freeze queue -> but blocked, due to (2) (2) timeout handler reference the g_usage_counter - > but blocks in the transport .timeout() handler, due to (3) (3) the transport timeout handler (indirectly) calls nvme_stop_queue() -> which takes the (down_read) namespaces_rwsem - > but blocks, due to (4) (4) ANA update takes the (down_write) namespaces_rwsem -> calls nvme_mpath_set_live() -> which synchronize the ns_head srcu (see commit 504db087aacc) -> but blocks, due to (5) (5) I/O came into nvme_mpath_make_request -> took srcu_read_lock -> direct_make_request > blk_queue_enter -> but blocked, due to (1) ==> the request queue is under freeze -> deadlock. The fix is making ANA update take a read lock as the namespaces list is not manipulated, it is just the ns and ns->head that are being updated (which is protected with the ns->head lock). Fixes: 0d0b660f214dc ("nvme: add ANA support") Signed-off-by: Sagi Grimberg Reviewed-by: Keith Busch Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 90a33c23aad85e66a22350cdd4988f39b0146b25 Author: Hans de Goede Date: Thu Apr 2 20:53:57 2020 +0200 ASoC: Intel: atom: Take the drv->lock mutex before calling sst_send_slot_map() [ Upstream commit 81630dc042af998b9f58cd8e2c29dab9777ea176 ] sst_send_slot_map() uses sst_fill_and_send_cmd_unlocked() because in some places it is called with the drv->lock mutex already held. So it must always be called with the mutex locked. This commit adds missing locking in the sst_set_be_modules() code-path. Fixes: 24c8d14192cc ("ASoC: Intel: mrfld: add DSP core controls") Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200402185359.3424-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1310d9655be0e11f07f2f915225bea083951d773 Author: Santosh Sivaraj Date: Tue Jan 14 11:10:51 2020 +0530 tools/test/nvdimm: Fix out of tree build [ Upstream commit 1f776799628139d0da47e710ad86eb58d987ff66 ] Out of tree build using make M=tools/test/nvdimm O=/tmp/build -C /tmp/build fails with the following error make: Entering directory '/tmp/build' CC [M] tools/testing/nvdimm/test/nfit.o linux/tools/testing/nvdimm/test/nfit.c:19:10: fatal error: nd-core.h: No such file or directory 19 | #include | ^~~~~~~~~~~ compilation terminated. That is because the kbuild file uses $(src) which points to tools/testing/nvdimm, $(srctree) correctly points to root of the linux source tree. Reported-by: Aneesh Kumar K.V Signed-off-by: Santosh Sivaraj Link: https://lore.kernel.org/r/20200114054051.4115790-1-santosh@fossix.org Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 713ad9b9d37aed92e4921ff293e8c4f334ef209f Author: Wu Bo Date: Tue Mar 24 15:58:50 2020 +0800 scsi: iscsi: Report unbind session event when the target has been removed [ Upstream commit 13e60d3ba287d96eeaf1deaadba51f71578119a3 ] If the daemon is restarted or crashes while logging out of a session, the unbind session event sent by the kernel is not processed and is lost. When the daemon starts again, the session can't be unbound because the daemon is waiting for the event message. However, the kernel has already logged out and the event will not be resent. When iscsid restart is complete, logout session reports error: Logging out of session [sid: 6, target: iqn.xxxxx, portal: xx.xx.xx.xx,3260] iscsiadm: Could not logout of [sid: 6, target: iscsiadm -m node iqn.xxxxx, portal: xx.xx.xx.xx,3260]. iscsiadm: initiator reported error (9 - internal error) iscsiadm: Could not logout of all requested sessions Make sure the unbind event is emitted. [mkp: commit desc and applied by hand since patch was mangled] Link: https://lore.kernel.org/r/4eab1771-2cb3-8e79-b31c-923652340e99@huawei.com Reviewed-by: Lee Duncan Signed-off-by: Wu Bo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f507ae6e33cbe56c4e3fe000434fc0ecc263d098 Author: Sagi Grimberg Date: Mon Mar 23 15:06:30 2020 -0700 nvme-tcp: fix possible crash in write_zeroes processing [ Upstream commit 25e5cb780e62bde432b401f312bb847edc78b432 ] We cannot look at blk_rq_payload_bytes without first checking that the request has a mappable physical segments first (e.g. blk_rq_nr_phys_segments(rq) != 0) and only then to take the request payload bytes. This caused us to send a wrong sgl to the target or even dereference a non-existing buffer in case we actually got to the data send sequence (if it was in-capsule). Reported-by: Tony Asleson Suggested-by: Chaitanya Kulkarni Signed-off-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a5f036adae0981ec1a5e711de1df00750d320755 Author: Geert Uytterhoeven Date: Mon Mar 16 11:32:14 2020 +0100 pwm: rcar: Fix late Runtime PM enablement [ Upstream commit 1451a3eed24b5fd6a604683f0b6995e0e7e16c79 ] Runtime PM should be enabled before calling pwmchip_add(), as PWM users can appear immediately after the PWM chip has been added. Likewise, Runtime PM should be disabled after the removal of the PWM chip. Fixes: ed6c1476bf7f16d5 ("pwm: Add support for R-Car PWM Timer") Signed-off-by: Geert Uytterhoeven Reviewed-by: Uwe Kleine-König Reviewed-by: Laurent Pinchart Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b71ac8086a7b4d8281e1157762b9d56e41f12865 Author: Yan, Zheng Date: Tue Mar 10 19:34:20 2020 +0800 ceph: don't skip updating wanted caps when cap is stale [ Upstream commit 0aa971b6fd3f92afef6afe24ef78d9bb14471519 ] 1. try_get_cap_refs() fails to get caps and finds that mds_wanted does not include what it wants. It returns -ESTALE. 2. ceph_get_caps() calls ceph_renew_caps(). ceph_renew_caps() finds that inode has cap, so it calls ceph_check_caps(). 3. ceph_check_caps() finds that issued caps (without checking if it's stale) already includes caps wanted by open file, so it skips updating wanted caps. Above events can cause an infinite loop inside ceph_get_caps(). Signed-off-by: "Yan, Zheng" Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit acbfccc6a3e3d87bf9bc0ee545b941bb1a5ef9f1 Author: Qiujun Huang Date: Fri Mar 6 09:34:20 2020 +0800 ceph: return ceph_mdsc_do_request() errors from __get_parent() [ Upstream commit c6d50296032f0b97473eb2e274dc7cc5d0173847 ] Return the error returned by ceph_mdsc_do_request(). Otherwise, r_target_inode ends up being NULL this ends up returning ENOENT regardless of the error. Signed-off-by: Qiujun Huang Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit fb669262fdef49ef3ef217299ebbafbb673e5633 Author: Javed Hasan Date: Thu Mar 26 23:02:07 2020 -0700 scsi: libfc: If PRLI rejected, move rport to PLOGI state [ Upstream commit 45e544bfdab2014d11c7595b8ccc3c4715a09015 ] If PRLI reject code indicates "rejected status", move rport state machine back to PLOGI state. Link: https://lore.kernel.org/r/20200327060208.17104-2-skashyap@marvell.com Signed-off-by: Javed Hasan Signed-off-by: Saurav Kashyap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8427b05a7a1f03f729fdcb6d8afa54226a546e32 Author: James Smart Date: Sun Mar 22 11:12:59 2020 -0700 scsi: lpfc: Fix crash in target side cable pulls hitting WAIT_FOR_UNREG [ Upstream commit 807e7353d8a7105ce884d22b0dbc034993c6679c ] Kernel is crashing with the following stacktrace: BUG: unable to handle kernel NULL pointer dereference at 00000000000005bc IP: lpfc_nvme_register_port+0x1a8/0x3a0 [lpfc] ... Call Trace: lpfc_nlp_state_cleanup+0x2b2/0x500 [lpfc] lpfc_nlp_set_state+0xd7/0x1a0 [lpfc] lpfc_cmpl_prli_prli_issue+0x1f7/0x450 [lpfc] lpfc_disc_state_machine+0x7a/0x1e0 [lpfc] lpfc_cmpl_els_prli+0x16f/0x1e0 [lpfc] lpfc_sli_sp_handle_rspiocb+0x5b2/0x690 [lpfc] lpfc_sli_handle_slow_ring_event_s4+0x182/0x230 [lpfc] lpfc_do_work+0x87f/0x1570 [lpfc] kthread+0x10d/0x130 ret_from_fork+0x35/0x40 During target side fault injections, it is possible to hit the NLP_WAIT_FOR_UNREG case in lpfc_nvme_remoteport_delete. A prior commit fixed a rebind and delete race condition, but called lpfc_nlp_put unconditionally. This triggered a deletion and the crash. Fix by movng nlp_put to inside the NLP_WAIT_FOR_UNREG case, where the nlp will be being unregistered/removed. Leave the reference if the flag isn't set. Link: https://lore.kernel.org/r/20200322181304.37655-8-jsmart2021@gmail.com Fixes: b15bd3e6212e ("scsi: lpfc: Fix nvme remoteport registration race conditions") Signed-off-by: James Smart Signed-off-by: Dick Kennedy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0c5733a96261f0becf02153ede03cfb15f8e03a7 Author: James Smart Date: Sun Mar 22 11:12:57 2020 -0700 scsi: lpfc: Fix crash after handling a pci error [ Upstream commit 4cd70891308dfb875ef31060c4a4aa8872630a2e ] Injecting EEH on a 32GB card is causing kernel oops The pci error handler is doing an IO flush and the offline code is also doing an IO flush. When the 1st flush is complete the hdwq is destroyed (freed), yet the second flush accesses the hdwq and crashes. Added a check in lpfc_sli4_fush_io_rings to check both the HBA_IOQ_FLUSH flag and the hdwq pointer to see if it is already set and not already freed. Link: https://lore.kernel.org/r/20200322181304.37655-6-jsmart2021@gmail.com Signed-off-by: James Smart Signed-off-by: Dick Kennedy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9d1062c4dd14517c5f22912dd56398308290dbfd Author: James Smart Date: Sun Mar 22 11:12:53 2020 -0700 scsi: lpfc: Fix kasan slab-out-of-bounds error in lpfc_unreg_login [ Upstream commit 38503943c89f0bafd9e3742f63f872301d44cbea ] The following kasan bug was called out: BUG: KASAN: slab-out-of-bounds in lpfc_unreg_login+0x7c/0xc0 [lpfc] Read of size 2 at addr ffff889fc7c50a22 by task lpfc_worker_3/6676 ... Call Trace: dump_stack+0x96/0xe0 ? lpfc_unreg_login+0x7c/0xc0 [lpfc] print_address_description.constprop.6+0x1b/0x220 ? lpfc_unreg_login+0x7c/0xc0 [lpfc] ? lpfc_unreg_login+0x7c/0xc0 [lpfc] __kasan_report.cold.9+0x37/0x7c ? lpfc_unreg_login+0x7c/0xc0 [lpfc] kasan_report+0xe/0x20 lpfc_unreg_login+0x7c/0xc0 [lpfc] lpfc_sli_def_mbox_cmpl+0x334/0x430 [lpfc] ... When processing the completion of a "Reg Rpi" login mailbox command in lpfc_sli_def_mbox_cmpl, a call may be made to lpfc_unreg_login. The vpi is extracted from the completing mailbox context and passed as an input for the next. However, the vpi stored in the mailbox command context is an absolute vpi, which for SLI4 represents both base + offset. When used with a non-zero base component, (function id > 0) this results in an out-of-range access beyond the allocated phba->vpi_ids array. Fix by subtracting the function's base value to get an accurate vpi number. Link: https://lore.kernel.org/r/20200322181304.37655-2-jsmart2021@gmail.com Signed-off-by: James Smart Signed-off-by: Dick Kennedy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 66491dadd125acd4434c0e810ad352701ebebb60 Author: Tero Kristo Date: Thu Mar 12 11:58:06 2020 +0200 watchdog: reset last_hw_keepalive time at start [ Upstream commit 982bb70517aef2225bad1d802887b733db492cc0 ] Currently the watchdog core does not initialize the last_hw_keepalive time during watchdog startup. This will cause the watchdog to be pinged immediately if enough time has passed from the system boot-up time, and some types of watchdogs like K3 RTI does not like this. To avoid the issue, setup the last_hw_keepalive time during watchdog startup. Signed-off-by: Tero Kristo Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20200302200426.6492-3-t-kristo@ti.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 7b709f1ba8008696f2c1a32c9ccef0aa84620db2 Author: Jan Kara Date: Thu Jan 23 16:47:20 2020 +0100 tools/testing/nvdimm: Fix compilation failure without CONFIG_DEV_DAX_PMEM_COMPAT [ Upstream commit c0e71d602053e4e7637e4bc7d0bc9603ea77a33f ] When a kernel is configured without CONFIG_DEV_DAX_PMEM_COMPAT, the compilation of tools/testing/nvdimm fails with: Building modules, stage 2. MODPOST 11 modules ERROR: "dax_pmem_compat_test" [tools/testing/nvdimm/test/nfit_test.ko] undefined! Fix the problem by calling dax_pmem_compat_test() only if the kernel has the required functionality. Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20200123154720.12097-1-jack@suse.cz Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 810045068bda0598d3d5f4edf29a92ad7ef704bd Author: Catalin Marinas Date: Fri Apr 24 17:38:05 2020 +0100 arm64: Silence clang warning on mismatched value/register sizes [ Upstream commit: 27a22fbdeedd6c5c451cf5f830d51782bf50c3a2 ] Clang reports a warning on the __tlbi(aside1is, 0) macro expansion since the value size does not match the register size specified in the inline asm. Construct the ASID value using the __TLBI_VADDR() macro. Fixes: 222fc0c8503d ("arm64: compat: Workaround Neoverse-N1 #1542419 for compat user-space") Reported-by: Nathan Chancellor Cc: James Morse Signed-off-by: Catalin Marinas Signed-off-by: James Morse Signed-off-by: Sasha Levin commit aa50d567ec4ae77ef17e8a523b8839a5ab671bec Author: James Morse Date: Fri Apr 24 17:38:04 2020 +0100 arm64: compat: Workaround Neoverse-N1 #1542419 for compat user-space [ Upstream commit 222fc0c8503d98cec3cb2bac2780cdd21a6e31c0 ] Compat user-space is unable to perform ICIMVAU instructions from user-space. Instead it uses a compat-syscall. Add the workaround for Neoverse-N1 #1542419 to this code path. Signed-off-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: James Morse Signed-off-by: Sasha Levin commit 6de0c621191a42c3574d261a06a35841fc9b777a Author: James Morse Date: Fri Apr 24 17:38:03 2020 +0100 arm64: Fake the IminLine size on systems affected by Neoverse-N1 #1542419 [ Upstream commit ee9d90be9ddace01b7fb126567e4b539fbe1f82f ] Systems affected by Neoverse-N1 #1542419 support DIC so do not need to perform icache maintenance once new instructions are cleaned to the PoU. For the errata workaround, the kernel hides DIC from user-space, so that the unnecessary cache maintenance can be trapped by firmware. To reduce the number of traps, produce a fake IminLine value based on PAGE_SIZE. Signed-off-by: James Morse Reviewed-by: Suzuki K Poulose Signed-off-by: Catalin Marinas Signed-off-by: James Morse Signed-off-by: Sasha Levin commit f2791551cedb5c295528b00c74d0a02d62c4bd92 Author: James Morse Date: Fri Apr 24 17:38:02 2020 +0100 arm64: errata: Hide CTR_EL0.DIC on systems affected by Neoverse-N1 #1542419 [ Upstream commit 05460849c3b51180d5ada3373d0449aea19075e4 ] Cores affected by Neoverse-N1 #1542419 could execute a stale instruction when a branch is updated to point to freshly generated instructions. To workaround this issue we need user-space to issue unnecessary icache maintenance that we can trap. Start by hiding CTR_EL0.DIC. Reviewed-by: Suzuki K Poulose Signed-off-by: James Morse Signed-off-by: Catalin Marinas Signed-off-by: James Morse Signed-off-by: Sasha Levin commit 4b823bf7c2cad42d517d736a44b36b5bd97e0430 Author: William Dauchy Date: Fri Mar 27 19:56:39 2020 +0100 net, ip_tunnel: fix interface lookup with no key commit 25629fdaff2ff509dd0b3f5ff93d70a75e79e0a1 upstream. when creating a new ipip interface with no local/remote configuration, the lookup is done with TUNNEL_NO_KEY flag, making it impossible to match the new interface (only possible match being fallback or metada case interface); e.g: `ip link add tunl1 type ipip dev eth0` To fix this case, adding a flag check before the key comparison so we permit to match an interface with no local/remote config; it also avoids breaking possible userland tools relying on TUNNEL_NO_KEY flag and uninitialised key. context being on my side, I'm creating an extra ipip interface attached to the physical one, and moving it to a dedicated namespace. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Signed-off-by: William Dauchy Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5811f24abd27a8a0791c6909c6ff803659060c84 Author: Randall Huang Date: Fri Oct 18 14:56:22 2019 +0800 f2fs: fix to avoid memory leakage in f2fs_listxattr commit 688078e7f36c293dae25b338ddc9e0a2790f6e06 upstream. In f2fs_listxattr, there is no boundary check before memcpy e_name to buffer. If the e_name_len is corrupted, unexpected memory contents may be returned to the buffer. Signed-off-by: Randall Huang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 79ad1490415267c496899f75aae5c9d91999dc89 Author: Dmitry Monakhov Date: Wed Nov 6 12:25:02 2019 +0000 ext4: fix extent_status fragmentation for plain files [ Upstream commit 4068664e3cd2312610ceac05b74c4cf1853b8325 ] Extents are cached in read_extent_tree_block(); as a result, extents are not cached for inodes with depth == 0 when we try to find the extent using ext4_find_extent(). The result of the lookup is cached in ext4_map_blocks() but is only a subset of the extent on disk. As a result, the contents of extents status cache can get very badly fragmented for certain workloads, such as a random 4k read workload. File size of /mnt/test is 33554432 (8192 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 8191: 40960.. 49151: 8192: last,eof $ perf record -e 'ext4:ext4_es_*' /root/bin/fio --name=t --direct=0 --rw=randread --bs=4k --filesize=32M --size=32M --filename=/mnt/test $ perf script | grep ext4_es_insert_extent | head -n 10 fio 131 [000] 13.975421: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [494/1) mapped 41454 status W fio 131 [000] 13.975939: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [6064/1) mapped 47024 status W fio 131 [000] 13.976467: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [6907/1) mapped 47867 status W fio 131 [000] 13.976937: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [3850/1) mapped 44810 status W fio 131 [000] 13.977440: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [3292/1) mapped 44252 status W fio 131 [000] 13.977931: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [6882/1) mapped 47842 status W fio 131 [000] 13.978376: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [3117/1) mapped 44077 status W fio 131 [000] 13.978957: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [2896/1) mapped 43856 status W fio 131 [000] 13.979474: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [7479/1) mapped 48439 status W Fix this by caching the extents for inodes with depth == 0 in ext4_find_extent(). [ Renamed ext4_es_cache_extents() to ext4_cache_extents() since this newly added function is not in extents_cache.c, and to avoid potential visual confusion with ext4_es_cache_extent(). -TYT ] Signed-off-by: Dmitry Monakhov Link: https://lore.kernel.org/r/20191106122502.19986-1-dmonakhov@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit deb90c9a3f4294bfdaa770d639fc82c43a467ea7 Author: Gabriel Krisman Bertazi Date: Thu Feb 13 18:45:25 2020 -0300 selftests: futex: Add FUTEX_WAIT_MULTIPLE wake up test Add test for wait at multiple futexes mechanism. Skip the test if it's a x32 application and the kernel returned the approtiaded error, since this ABI is not supported for this operation. Signed-off-by: Gabriel Krisman Bertazi Co-developed-by: André Almeida Signed-off-by: André Almeida Signed-off-by: Alexandre Frade commit 1ae8f507b2c532cb5a9982db72b3ff542a49a26f Author: Gabriel Krisman Bertazi Date: Thu Feb 13 18:45:24 2020 -0300 selftests: futex: Add FUTEX_WAIT_MULTIPLE wouldblock test Add test for wouldblock return when waiting for multiple futexes. Skip the test if it's a x32 application and the kernel returned the approtiaded error, since this ABI is not supported for this operation. Signed-off-by: Gabriel Krisman Bertazi Co-developed-by: André Almeida Signed-off-by: André Almeida Signed-off-by: Alexandre Frade commit 32ea871c72a6d571aee1e36380cdc0f1c01e2610 Author: Gabriel Krisman Bertazi Date: Thu Feb 13 18:45:23 2020 -0300 selftests: futex: Add FUTEX_WAIT_MULTIPLE timeout test Add test for timeout when waiting for multiple futexes. Skip the test if it's a x32 application and the kernel returned the approtiaded error, since this ABI is not supported for this operation. Signed-off-by: Gabriel Krisman Bertazi Co-developed-by: André Almeida Signed-off-by: André Almeida Signed-off-by: Alexandre Frade commit 7a7b416cbdd65c4e34464369e7d879e5912ae108 Author: Gabriel Krisman Bertazi Date: Thu Feb 13 18:45:22 2020 -0300 futex: Implement mechanism to wait on any of several futexes This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows a thread to wait on several futexes at the same time, and be awoken by any of them. In a sense, it implements one of the features that was supported by pooling on the old FUTEX_FD interface. The use case lies in the Wine implementation of the Windows NT interface WaitMultipleObjects. This Windows API function allows a thread to sleep waiting on the first of a set of event sources (mutexes, timers, signal, console input, etc) to signal. Considering this is a primitive synchronization operation for Windows applications, being able to quickly signal events on the producer side, and quickly go to sleep on the consumer side is essential for good performance of those running over Wine. Wine developers have an implementation that uses eventfd, but it suffers from FD exhaustion (there is applications that go to the order of multi-milion FDs), and higher CPU utilization than this new operation. The futex list is passed as an array of `struct futex_wait_block` (pointer, value, bitset) to the kernel, which will enqueue all of them and sleep if none was already triggered. It returns a hint of which futex caused the wake up event to userspace, but the hint doesn't guarantee that is the only futex triggered. Before calling the syscall again, userspace should traverse the list, trying to re-acquire any of the other futexes, to prevent an immediate -EWOULDBLOCK return code from the kernel. This was tested using three mechanisms: 1) By reimplementing FUTEX_WAIT in terms of FUTEX_WAIT_MULTIPLE and running the unmodified tools/testing/selftests/futex and a full linux distro on top of this kernel. 2) By an example code that exercises the FUTEX_WAIT_MULTIPLE path on a multi-threaded, event-handling setup. 3) By running the Wine fsync with Valve's Proton compatibility code implementation and executing multi-threaded applications, in particular modern games, on top of this implementation. Changes were tested for the following ABIs: x86_64, i386 and x32. Support for x32 applications is not implemented since it would take a major rework adding a new entry point and splitting the current futex 64 entry point in two and we can't change the current x32 syscall number without breaking user space compatibility. CC: Steven Rostedt Cc: Richard Yao Cc: Thomas Gleixner Cc: Peter Zijlstra Co-developed-by: Zebediah Figura Signed-off-by: Zebediah Figura Co-developed-by: Steven Noonan Signed-off-by: Steven Noonan Co-developed-by: Pierre-Loup A. Griffais Signed-off-by: Pierre-Loup A. Griffais Signed-off-by: Gabriel Krisman Bertazi [Added compatibility code] Co-developed-by: André Almeida Signed-off-by: André Almeida Signed-off-by: Alexandre Frade commit 9e90e0afe136b51b0157a20ff68fbd6e7ef8d6ca Author: Alexandre Frade Date: Tue Apr 28 15:21:05 2020 -0300 Revert "futex: Add support for multiple keys at the same time" This reverts commit 4e309d847989d1aa4cfbb0f4a8e791b75435823d. commit 0c418786cb3aa175823f0172d939679df9ab9a54 Author: Greg Kroah-Hartman Date: Thu Apr 23 10:36:46 2020 +0200 Linux 5.4.35 commit a801a05ca7145fd2b72dad35bd01977014241e55 Author: Daniel Borkmann Date: Tue Apr 21 15:01:52 2020 +0200 bpf, test_verifier: switch bpf_get_stack's 0 s> r8 test [ no upstream commit ] Switch the comparison, so that is_branch_taken() will recognize that below branch is never taken: [...] 17: [...] R1_w=inv0 [...] R8_w=inv(id=0,smin_value=-2147483648,smax_value=-1,umin_value=18446744071562067968,var_off=(0xffffffff80000000; 0x7fffffff)) [...] 17: (67) r8 <<= 32 18: [...] R8_w=inv(id=0,smax_value=-4294967296,umin_value=9223372036854775808,umax_value=18446744069414584320,var_off=(0x8000000000000000; 0x7fffffff00000000)) [...] 18: (c7) r8 s>>= 32 19: [...] R8_w=inv(id=0,smin_value=-2147483648,smax_value=-1,umin_value=18446744071562067968,var_off=(0xffffffff80000000; 0x7fffffff)) [...] 19: (6d) if r1 s> r8 goto pc+16 [...] R1_w=inv0 [...] R8_w=inv(id=0,smin_value=-2147483648,smax_value=-1,umin_value=18446744071562067968,var_off=(0xffffffff80000000; 0x7fffffff)) [...] [...] Currently we check for is_branch_taken() only if either K is source, or source is a scalar value that is const. For upstream it would be good to extend this properly to check whether dst is const and src not. For the sake of the test_verifier, it is probably not needed here: # ./test_verifier 101 #101/p bpf_get_stack return R0 within range OK Summary: 1 PASSED, 0 SKIPPED, 0 FAILED I haven't seen this issue in test_progs* though, they are passing fine: # ./test_progs-no_alu32 -t get_stack Switching to flavor 'no_alu32' subdirectory... #20 get_stack_raw_tp:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED # ./test_progs -t get_stack #20 get_stack_raw_tp:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Acked-by: John Fastabend Signed-off-by: Greg Kroah-Hartman commit 8781011a302bac86d92a930e9a8c0fdf3f1df697 Author: John Fastabend Date: Mon Mar 30 14:37:19 2020 -0700 bpf: Test_progs, add test to catch retval refine error handling commit d2db08c7a14e0b5eed6132baf258b80622e041a9 upstream. Before this series the verifier would clamp return bounds of bpf_get_stack() to [0, X] and this led the verifier to believe that a JMP_JSLT 0 would be false and so would prune that path. The result is anything hidden behind that JSLT would be unverified. Add a test to catch this case by hiding an goto pc-1 behind the check which will cause an infinite loop if not rejected. Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/158560423908.10843.11783152347709008373.stgit@john-Precision-5820-Tower Signed-off-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit 37e1cdff90c1bc448edb4d73a18d89e05e36ab55 Author: John Fastabend Date: Mon Mar 30 14:37:40 2020 -0700 bpf: Test_verifier, bpf_get_stack return value add <0 commit 9ac26e9973bac5716a2a542e32f380c84db2b88c upstream. With current ALU32 subreg handling and retval refine fix from last patches we see an expected failure in test_verifier. With verbose verifier state being printed at each step for clarity we have the following relavent lines [I omit register states that are not necessarily useful to see failure cause], #101/p bpf_get_stack return R0 within range FAIL Failed to load prog 'Success'! [..] 14: (85) call bpf_get_stack#67 R0_w=map_value(id=0,off=0,ks=8,vs=48,imm=0) R3_w=inv48 15: R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) 15: (b7) r1 = 0 16: R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) R1_w=inv0 16: (bf) r8 = r0 17: R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) R1_w=inv0 R8_w=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) 17: (67) r8 <<= 32 18: R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) R1_w=inv0 R8_w=inv(id=0,smax_value=9223372032559808512, umax_value=18446744069414584320, var_off=(0x0; 0xffffffff00000000), s32_min_value=0, s32_max_value=0, u32_max_value=0, var32_off=(0x0; 0x0)) 18: (c7) r8 s>>= 32 19 R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) R1_w=inv0 R8_w=inv(id=0,smin_value=-2147483648, smax_value=2147483647, var32_off=(0x0; 0xffffffff)) 19: (cd) if r1 s< r8 goto pc+16 R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) R1_w=inv0 R8_w=inv(id=0,smin_value=-2147483648, smax_value=0, var32_off=(0x0; 0xffffffff)) 20: R0=inv(id=0,smax_value=48,var32_off=(0x0; 0xffffffff)) R1_w=inv0 R8_w=inv(id=0,smin_value=-2147483648, smax_value=0, R9=inv48 20: (1f) r9 -= r8 21: (bf) r2 = r7 22: R2_w=map_value(id=0,off=0,ks=8,vs=48,imm=0) 22: (0f) r2 += r8 value -2147483648 makes map_value pointer be out of bounds After call bpf_get_stack() on line 14 and some moves we have at line 16 an r8 bound with max_value 48 but an unknown min value. This is to be expected bpf_get_stack call can only return a max of the input size but is free to return any negative error in the 32-bit register space. The C helper is returning an int so will use lower 32-bits. Lines 17 and 18 clear the top 32 bits with a left/right shift but use ARSH so we still have worst case min bound before line 19 of -2147483648. At this point the signed check 'r1 s< r8' meant to protect the addition on line 22 where dst reg is a map_value pointer may very well return true with a large negative number. Then the final line 22 will detect this as an invalid operation and fail the program. What we want to do is proceed only if r8 is positive non-error. So change 'r1 s< r8' to 'r1 s> r8' so that we jump if r8 is negative. Next we will throw an error because we access past the end of the map value. The map value size is 48 and sizeof(struct test_val) is 48 so we walk off the end of the map value on the second call to get bpf_get_stack(). Fix this by changing sizeof(struct test_val) to 24 by using 'sizeof(struct test_val) / 2'. After this everything passes as expected. Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/158560426019.10843.3285429543232025187.stgit@john-Precision-5820-Tower Signed-off-by: Greg Kroah-Hartman commit 3bd5bcafbbf3af6795575aab544783cda8ea3907 Author: Daniel Borkmann Date: Tue Apr 21 15:01:49 2020 +0200 bpf: fix buggy r0 retval refinement for tracing helpers [ no upstream commit ] See the glory details in 100605035e15 ("bpf: Verifier, do_refine_retval_range may clamp umin to 0 incorrectly") for why 849fa50662fb ("bpf/verifier: refine retval R0 state for bpf_get_stack helper") is buggy. The whole series however is not suitable for stable since it adds significant amount [0] of verifier complexity in order to add 32bit subreg tracking. Something simpler is needed. Unfortunately, reverting 849fa50662fb ("bpf/verifier: refine retval R0 state for bpf_get_stack helper") or just cherry-picking 100605035e15 ("bpf: Verifier, do_refine_retval_range may clamp umin to 0 incorrectly") is not an option since it will break existing tracing programs badly (at least those that are using bpf_get_stack() and bpf_probe_read_str() helpers). Not fixing it in stable is also not an option since on 4.19 kernels an error will cause a soft-lockup due to hitting dead-code sanitized branch since we don't hard-wire such branches in old kernels yet. But even then for 5.x 849fa50662fb ("bpf/verifier: refine retval R0 state for bpf_get_stack helper") would cause wrong bounds on the verifier simluation when an error is hit. In one of the earlier iterations of mentioned patch series for upstream there was the concern that just using smax_value in do_refine_retval_range() would nuke bounds by subsequent <<32 >>32 shifts before the comparison against 0 [1] which eventually led to the 32bit subreg tracking in the first place. While I initially went for implementing the idea [1] to pattern match the two shift operations, it turned out to be more complex than actually needed, meaning, we could simply treat do_refine_retval_range() similarly to how we branch off verification for conditionals or under speculation, that is, pushing a new reg state to the stack for later verification. This means, instead of verifying the current path with the ret_reg in [S32MIN, msize_max_value] interval where later bounds would get nuked, we split this into two: i) for the success case where ret_reg can be in [0, msize_max_value], and ii) for the error case with ret_reg known to be in interval [S32MIN, -1]. Latter will preserve the bounds during these shift patterns and can match reg < 0 test. test_progs also succeed with this approach. [0] https://lore.kernel.org/bpf/158507130343.15666.8018068546764556975.stgit@john-Precision-5820-Tower/ [1] https://lore.kernel.org/bpf/158015334199.28573.4940395881683556537.stgit@john-XPS-13-9370/T/#m2e0ad1d5949131014748b6daa48a3495e7f0456d Fixes: 849fa50662fb ("bpf/verifier: refine retval R0 state for bpf_get_stack helper") Reported-by: Lorenzo Fontana Reported-by: Leonardo Di Donato Reported-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Acked-by: John Fastabend Tested-by: John Fastabend Signed-off-by: Greg Kroah-Hartman commit f1afcf9488fc45765e20e2047d3b776981900e0b Author: Waiman Long Date: Sat Mar 21 21:11:24 2020 -0400 KEYS: Don't write out to userspace while holding key semaphore commit d3ec10aa95819bff18a0d936b18884c7816d0914 upstream. A lockdep circular locking dependency report was seen when running a keyutils test: [12537.027242] ====================================================== [12537.059309] WARNING: possible circular locking dependency detected [12537.088148] 4.18.0-147.7.1.el8_1.x86_64+debug #1 Tainted: G OE --------- - - [12537.125253] ------------------------------------------------------ [12537.153189] keyctl/25598 is trying to acquire lock: [12537.175087] 000000007c39f96c (&mm->mmap_sem){++++}, at: __might_fault+0xc4/0x1b0 [12537.208365] [12537.208365] but task is already holding lock: [12537.234507] 000000003de5b58d (&type->lock_class){++++}, at: keyctl_read_key+0x15a/0x220 [12537.270476] [12537.270476] which lock already depends on the new lock. [12537.270476] [12537.307209] [12537.307209] the existing dependency chain (in reverse order) is: [12537.340754] [12537.340754] -> #3 (&type->lock_class){++++}: [12537.367434] down_write+0x4d/0x110 [12537.385202] __key_link_begin+0x87/0x280 [12537.405232] request_key_and_link+0x483/0xf70 [12537.427221] request_key+0x3c/0x80 [12537.444839] dns_query+0x1db/0x5a5 [dns_resolver] [12537.468445] dns_resolve_server_name_to_ip+0x1e1/0x4d0 [cifs] [12537.496731] cifs_reconnect+0xe04/0x2500 [cifs] [12537.519418] cifs_readv_from_socket+0x461/0x690 [cifs] [12537.546263] cifs_read_from_socket+0xa0/0xe0 [cifs] [12537.573551] cifs_demultiplex_thread+0x311/0x2db0 [cifs] [12537.601045] kthread+0x30c/0x3d0 [12537.617906] ret_from_fork+0x3a/0x50 [12537.636225] [12537.636225] -> #2 (root_key_user.cons_lock){+.+.}: [12537.664525] __mutex_lock+0x105/0x11f0 [12537.683734] request_key_and_link+0x35a/0xf70 [12537.705640] request_key+0x3c/0x80 [12537.723304] dns_query+0x1db/0x5a5 [dns_resolver] [12537.746773] dns_resolve_server_name_to_ip+0x1e1/0x4d0 [cifs] [12537.775607] cifs_reconnect+0xe04/0x2500 [cifs] [12537.798322] cifs_readv_from_socket+0x461/0x690 [cifs] [12537.823369] cifs_read_from_socket+0xa0/0xe0 [cifs] [12537.847262] cifs_demultiplex_thread+0x311/0x2db0 [cifs] [12537.873477] kthread+0x30c/0x3d0 [12537.890281] ret_from_fork+0x3a/0x50 [12537.908649] [12537.908649] -> #1 (&tcp_ses->srv_mutex){+.+.}: [12537.935225] __mutex_lock+0x105/0x11f0 [12537.954450] cifs_call_async+0x102/0x7f0 [cifs] [12537.977250] smb2_async_readv+0x6c3/0xc90 [cifs] [12538.000659] cifs_readpages+0x120a/0x1e50 [cifs] [12538.023920] read_pages+0xf5/0x560 [12538.041583] __do_page_cache_readahead+0x41d/0x4b0 [12538.067047] ondemand_readahead+0x44c/0xc10 [12538.092069] filemap_fault+0xec1/0x1830 [12538.111637] __do_fault+0x82/0x260 [12538.129216] do_fault+0x419/0xfb0 [12538.146390] __handle_mm_fault+0x862/0xdf0 [12538.167408] handle_mm_fault+0x154/0x550 [12538.187401] __do_page_fault+0x42f/0xa60 [12538.207395] do_page_fault+0x38/0x5e0 [12538.225777] page_fault+0x1e/0x30 [12538.243010] [12538.243010] -> #0 (&mm->mmap_sem){++++}: [12538.267875] lock_acquire+0x14c/0x420 [12538.286848] __might_fault+0x119/0x1b0 [12538.306006] keyring_read_iterator+0x7e/0x170 [12538.327936] assoc_array_subtree_iterate+0x97/0x280 [12538.352154] keyring_read+0xe9/0x110 [12538.370558] keyctl_read_key+0x1b9/0x220 [12538.391470] do_syscall_64+0xa5/0x4b0 [12538.410511] entry_SYSCALL_64_after_hwframe+0x6a/0xdf [12538.435535] [12538.435535] other info that might help us debug this: [12538.435535] [12538.472829] Chain exists of: [12538.472829] &mm->mmap_sem --> root_key_user.cons_lock --> &type->lock_class [12538.472829] [12538.524820] Possible unsafe locking scenario: [12538.524820] [12538.551431] CPU0 CPU1 [12538.572654] ---- ---- [12538.595865] lock(&type->lock_class); [12538.613737] lock(root_key_user.cons_lock); [12538.644234] lock(&type->lock_class); [12538.672410] lock(&mm->mmap_sem); [12538.687758] [12538.687758] *** DEADLOCK *** [12538.687758] [12538.714455] 1 lock held by keyctl/25598: [12538.732097] #0: 000000003de5b58d (&type->lock_class){++++}, at: keyctl_read_key+0x15a/0x220 [12538.770573] [12538.770573] stack backtrace: [12538.790136] CPU: 2 PID: 25598 Comm: keyctl Kdump: loaded Tainted: G [12538.844855] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015 [12538.881963] Call Trace: [12538.892897] dump_stack+0x9a/0xf0 [12538.907908] print_circular_bug.isra.25.cold.50+0x1bc/0x279 [12538.932891] ? save_trace+0xd6/0x250 [12538.948979] check_prev_add.constprop.32+0xc36/0x14f0 [12538.971643] ? keyring_compare_object+0x104/0x190 [12538.992738] ? check_usage+0x550/0x550 [12539.009845] ? sched_clock+0x5/0x10 [12539.025484] ? sched_clock_cpu+0x18/0x1e0 [12539.043555] __lock_acquire+0x1f12/0x38d0 [12539.061551] ? trace_hardirqs_on+0x10/0x10 [12539.080554] lock_acquire+0x14c/0x420 [12539.100330] ? __might_fault+0xc4/0x1b0 [12539.119079] __might_fault+0x119/0x1b0 [12539.135869] ? __might_fault+0xc4/0x1b0 [12539.153234] keyring_read_iterator+0x7e/0x170 [12539.172787] ? keyring_read+0x110/0x110 [12539.190059] assoc_array_subtree_iterate+0x97/0x280 [12539.211526] keyring_read+0xe9/0x110 [12539.227561] ? keyring_gc_check_iterator+0xc0/0xc0 [12539.249076] keyctl_read_key+0x1b9/0x220 [12539.266660] do_syscall_64+0xa5/0x4b0 [12539.283091] entry_SYSCALL_64_after_hwframe+0x6a/0xdf One way to prevent this deadlock scenario from happening is to not allow writing to userspace while holding the key semaphore. Instead, an internal buffer is allocated for getting the keys out from the read method first before copying them out to userspace without holding the lock. That requires taking out the __user modifier from all the relevant read methods as well as additional changes to not use any userspace write helpers. That is, 1) The put_user() call is replaced by a direct copy. 2) The copy_to_user() call is replaced by memcpy(). 3) All the fault handling code is removed. Compiling on a x86-64 system, the size of the rxrpc_read() function is reduced from 3795 bytes to 2384 bytes with this patch. Fixes: ^1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Jarkko Sakkinen Signed-off-by: Waiman Long Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 5d53bfdce008ed5c5429cdee26ad177580f252b7 Author: Wen Yang Date: Wed Mar 18 23:31:56 2020 +0800 mtd: phram: fix a double free issue in error path commit 49c64df880570034308e4a9a49c4bc95cf8cdb33 upstream. The variable 'name' is released multiple times in the error path, which may cause double free issues. This problem is avoided by adding a goto label to release the memory uniformly. And this change also makes the code a bit more cleaner. Fixes: 4f678a58d335 ("mtd: fix memory leaks in phram_setup") Signed-off-by: Wen Yang Cc: Joern Engel Cc: Miquel Raynal Cc: Richard Weinberger Cc: Vignesh Raghavendra Cc: linux-mtd@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200318153156.25612-1-wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 4191ebe1fc71b6343c9d72b4de6e408c8d0b03bd Author: Dan Carpenter Date: Fri Feb 28 12:25:54 2020 +0300 mtd: lpddr: Fix a double free in probe() commit 4da0ea71ea934af18db4c63396ba2af1a679ef02 upstream. This function is only called from lpddr_probe(). We free "lpddr" both here and in the caller, so it's a double free. The best place to free "lpddr" is in lpddr_probe() so let's delete this one. Fixes: 8dc004395d5e ("[MTD] LPDDR qinfo probing.") Signed-off-by: Dan Carpenter Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200228092554.o57igp3nqhyvf66t@kili.mountain Signed-off-by: Greg Kroah-Hartman commit 7d4adb1d3c69efb1d0d90161cdea75b8dcae80a6 Author: Jonathan Neuschäfer Date: Tue Feb 18 16:02:19 2020 +0100 docs: Fix path to MTD command line partition parser commit fb2511247dc4061fd122d0195838278a4a0b7b59 upstream. cmdlinepart.c has been moved to drivers/mtd/parsers/. Fixes: a3f12a35c91d ("mtd: parsers: Move CMDLINE parser") Signed-off-by: Jonathan Neuschäfer Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit 318d5088fdfeb52955c0bdd1bf3ee688db204230 Author: Frieder Schrempf Date: Tue Feb 18 10:05:25 2020 +0000 mtd: spinand: Explicitly use MTD_OPS_RAW to write the bad block marker to OOB commit 621a7b780bd8b7054647d53d5071961f2c9e0873 upstream. When writing the bad block marker to the OOB area the access mode should be set to MTD_OPS_RAW as it is done for reading the marker. Currently this only works because req.mode is initialized to MTD_OPS_PLACE_OOB (0) and spinand_write_to_cache_op() checks for req.mode != MTD_OPS_AUTO_OOB. Fix this by explicitly setting req.mode to MTD_OPS_RAW. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Signed-off-by: Frieder Schrempf Reviewed-by: Boris Brezillon Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200218100432.32433-3-frieder.schrempf@kontron.de Signed-off-by: Greg Kroah-Hartman commit 700bccb8e9a2ef43c4ce5f3aedd663973a4d7aea Author: Christophe Kerello Date: Thu Jan 23 09:22:48 2020 +0100 mtd: rawnand: free the nand_device object commit 009264605cdf1b12962c3a46f75818d05452e890 upstream. This patch releases the resources allocated in nanddev_init function. Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Signed-off-by: Christophe Kerello Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/1579767768-32295-1-git-send-email-christophe.kerello@st.com Signed-off-by: Greg Kroah-Hartman commit 0c72ec11d8bd54975266ea09d1f65160fadd2f4c Author: Paul E. McKenney Date: Thu Jan 23 09:19:01 2020 -0800 locktorture: Print ratio of acquisitions, not failures commit 80c503e0e68fbe271680ab48f0fe29bc034b01b7 upstream. The __torture_print_stats() function in locktorture.c carefully initializes local variable "min" to statp[0].n_lock_acquired, but then compares it to statp[i].n_lock_fail. Given that the .n_lock_fail field should normally be zero, and given the initialization, it seems reasonable to display the maximum and minimum number acquisitions instead of miscomputing the maximum and minimum number of failures. This commit therefore switches from failures to acquisitions. And this turns out to be not only a day-zero bug, but entirely my own fault. I hate it when that happens! Fixes: 0af3fe1efa53 ("locktorture: Add a lock-torture kernel module") Reported-by: Will Deacon Signed-off-by: Paul E. McKenney Acked-by: Will Deacon Cc: Davidlohr Bueso Cc: Josh Triplett Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 01c9e2a9fc5ce7f0ce0e692aaf0c57fbaf224bfc Author: Stephen Rothwell Date: Thu Jan 9 18:39:12 2020 +1100 tty: evh_bytechan: Fix out of bounds accesses commit 3670664b5da555a2a481449b3baafff113b0ac35 upstream. ev_byte_channel_send() assumes that its third argument is a 16 byte array. Some places where it is called it may not be (or we can't easily tell if it is). Newer compilers have started producing warnings about this, so make sure we actually pass a 16 byte array. There may be more elegant solutions to this, but the driver is quite old and hasn't been updated in many years. The warnings (from a powerpc allyesconfig build) are: In file included from include/linux/byteorder/big_endian.h:5, from arch/powerpc/include/uapi/asm/byteorder.h:14, from include/asm-generic/bitops/le.h:6, from arch/powerpc/include/asm/bitops.h:250, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:19, from arch/powerpc/include/asm/bug.h:109, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/gfp.h:5, from include/linux/slab.h:15, from drivers/tty/ehv_bytechan.c:24: drivers/tty/ehv_bytechan.c: In function ‘ehv_bc_udbg_putc’: arch/powerpc/include/asm/epapr_hcalls.h:298:20: warning: array subscript 1 is outside array bounds of ‘const char[1]’ [-Warray-bounds] 298 | r6 = be32_to_cpu(p[1]); include/uapi/linux/byteorder/big_endian.h:40:51: note: in definition of macro ‘__be32_to_cpu’ 40 | #define __be32_to_cpu(x) ((__force __u32)(__be32)(x)) | ^ arch/powerpc/include/asm/epapr_hcalls.h:298:7: note: in expansion of macro ‘be32_to_cpu’ 298 | r6 = be32_to_cpu(p[1]); | ^~~~~~~~~~~ drivers/tty/ehv_bytechan.c:166:13: note: while referencing ‘data’ 166 | static void ehv_bc_udbg_putc(char c) | ^~~~~~~~~~~~~~~~ Fixes: dcd83aaff1c8 ("tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver") Signed-off-by: Stephen Rothwell Tested-by: Laurentiu Tudor [mpe: Trim warnings from change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200109183912.5fcb52aa@canb.auug.org.au Signed-off-by: Greg Kroah-Hartman commit f656649089a3509481c084bfab4837eeef8d16a0 Author: Nathan Chancellor Date: Tue Dec 17 20:00:25 2019 -0700 fbmem: Adjust indentation in fb_prepare_logo and fb_blank commit 93166f5f2e4dc593cff8ca77ef828ac6f148b0f3 upstream. Clang warns: ../drivers/video/fbdev/core/fbmem.c:665:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] if (fb_logo.depth > 4 && depth > 4) { ^ ../drivers/video/fbdev/core/fbmem.c:661:2: note: previous statement is here else ^ ../drivers/video/fbdev/core/fbmem.c:1075:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] return ret; ^ ../drivers/video/fbdev/core/fbmem.c:1072:2: note: previous statement is here if (!ret) ^ 2 warnings generated. This warning occurs because there are spaces before the tabs on these lines. Normalize the indentation in these functions so that it is consistent with the Linux kernel coding style and clang no longer warns. Fixes: 1692b37c99d5 ("fbdev: Fix logo if logo depth is less than framebuffer depth") Link: https://github.com/ClangBuiltLinux/linux/issues/825 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20191218030025.10064-1-natechancellor@gmail.com Signed-off-by: Greg Kroah-Hartman commit 47e4d791d51483ad201d0b662f4ecdf6a4a9eba1 Author: Maxime Roussin-Bélanger Date: Wed Feb 19 12:40:08 2020 -0500 iio: si1133: read 24-bit signed integer for measurement commit 328b50e9a0ad1fe8accdf8c19923deebab5e0c01 upstream. The chip is configured in 24 bit mode. The values read from it must always be treated as is. This fixes the issue by replacing the previous 16 bits value by a 24 bits buffer. This changes affects the value output by previous version of the driver, since the least significant byte was missing. The upper half of 16 bit values previously output are now the upper half of a 24 bit value. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Reported-by: Simon Goyette Co-authored-by: Guillaume Champagne Signed-off-by: Maxime Roussin-Bélanger Signed-off-by: Guillaume Champagne Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a2a385aae5510bf900fff3772342b162a0b1cdf5 Author: Jernej Skrabec Date: Sat Jan 25 00:20:09 2020 +0100 ARM: dts: sunxi: Fix DE2 clocks register range commit da180322582bd9db07f29e6d4a2d170afde0703f upstream. As it can be seen from DE2 manual, clock range is 0x10000. Fix it. Signed-off-by: Jernej Skrabec Fixes: 73f122c82775 ("ARM: dts: sun8i: a83t: Add display pipeline") Fixes: 05a43a262d03 ("ARM: dts: sun8i: r40: Add HDMI pipeline") Fixes: 21b299209330 ("ARM: sun8i: v3s: add device nodes for DE2 display pipeline") Fixes: d8c6f1f0295c ("ARM: sun8i: h3/h5: add DE2 CCU device node for H3") [wens@csie.org: added fixes tags] Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit 7e141c307834afbf02b0cfa0490baa946973882a Author: Dan Carpenter Date: Mon Jan 13 14:08:14 2020 +0300 fbdev: potential information leak in do_fb_ioctl() commit d3d19d6fc5736a798b118971935ce274f7deaa82 upstream. The "fix" struct has a 2 byte hole after ->ywrapstep and the "fix = info->fix;" assignment doesn't necessarily clear it. It depends on the compiler. The solution is just to replace the assignment with an memcpy(). Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held") Signed-off-by: Dan Carpenter Cc: Andrew Morton Cc: Arnd Bergmann Cc: "Eric W. Biederman" Cc: Andrea Righi Cc: Daniel Vetter Cc: Sam Ravnborg Cc: Maarten Lankhorst Cc: Daniel Thompson Cc: Peter Rosin Cc: Jani Nikula Cc: Gerd Hoffmann Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200113100132.ixpaymordi24n3av@kili.mountain Signed-off-by: Greg Kroah-Hartman commit f0938746879af331d1abf946a4b073fdd92a0d79 Author: Grygorii Strashko Date: Wed Apr 8 22:43:00 2020 +0300 dma-debug: fix displaying of dma allocation type commit 9bb50ed7470944238ec8e30a94ef096caf9056ee upstream. The commit 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using dma_map_page_attrs") removed "dma_debug_page" enum, but missed to update type2name string table. This causes incorrect displaying of dma allocation type. Fix it by removing "page" string from type2name string table and switch to use named initializers. Before (dma_alloc_coherent()): k3-ringacc 4b800000.ringacc: scather-gather idx 2208 P=d1140000 N=d114 D=d1140000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable k3-ringacc 4b800000.ringacc: scather-gather idx 2216 P=d1150000 N=d115 D=d1150000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable After: k3-ringacc 4b800000.ringacc: coherent idx 2208 P=d1140000 N=d114 D=d1140000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable k3-ringacc 4b800000.ringacc: coherent idx 2216 P=d1150000 N=d115 D=d1150000 L=40 DMA_BIDIRECTIONAL dma map error check not applicable Fixes: 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using dma_map_page_attrs") Signed-off-by: Grygorii Strashko Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit bc69709c54dfc48ca38dff1d50dc7c06567e4de8 Author: Florian Fainelli Date: Mon Mar 30 14:38:46 2020 -0700 net: dsa: bcm_sf2: Fix overflow checks commit d0802dc411f469569a537283b6f3833af47aece9 upstream. Commit f949a12fd697 ("net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc") tried to fix the some user controlled buffer overflows in bcm_sf2_cfp_rule_set() and bcm_sf2_cfp_rule_del() but the fix was using CFP_NUM_RULES, which while it is correct not to overflow the bitmaps, is not representative of what the device actually supports. Correct that by using bcm_sf2_cfp_rule_size() instead. The latter subtracts the number of rules by 1, so change the checks from greater than or equal to greater than accordingly. Fixes: f949a12fd697 ("net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 762d35aa906f2776c79e91d97194adf12e119122 Author: Ben Skeggs Date: Tue Mar 31 16:08:44 2020 +1000 drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init [ Upstream commit 028a12f5aa829b4ba6ac011530b815eda4960e89 ] Certain boards with GP107/GP108 chipsets hang (often, but randomly) for unknown reasons during GR initialisation. The first tell-tale symptom of this issue is: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ] appearing in dmesg, likely followed by many other failures being logged. Karol found this WAR for the issue a while back, but efforts to isolate the root cause and proper fix have not yielded success so far. I've modified the original patch to include a few more details, limit it to GP107/GP108 by default, and added a config option to override this choice. Signed-off-by: Ben Skeggs Reviewed-by: Karol Herbst Signed-off-by: Sasha Levin commit a156e67acf6c77f1c379448c7629c04113b6ee5c Author: Chao Yu Date: Fri Feb 14 17:45:12 2020 +0800 f2fs: fix to wait all node page writeback [ Upstream commit dc5a941223edd803f476a153abd950cc3a83c3e1 ] There is a race condition that we may miss to wait for all node pages writeback, fix it. - fsync() - shrink - f2fs_do_sync_file - __write_node_page - set_page_writeback(page#0) : remove DIRTY/TOWRITE flag - f2fs_fsync_node_pages : won't find page #0 as TOWRITE flag was removeD - f2fs_wait_on_node_pages_writeback : wont' wait page #0 writeback as it was not in fsync_node_list list. - f2fs_add_fsync_node_entry Fixes: 50fa53eccf9f ("f2fs: fix to avoid broken of dnode block list") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f08e4e70b0acec78574431f1eac10d273695f790 Author: Adrian Huang Date: Fri Feb 14 18:44:51 2020 +0800 iommu/amd: Fix the configuration of GCR3 table root pointer [ Upstream commit c20f36534666e37858a14e591114d93cc1be0d34 ] The SPA of the GCR3 table root pointer[51:31] masks 20 bits. However, this requires 21 bits (Please see the AMD IOMMU specification). This leads to the potential failure when the bit 51 of SPA of the GCR3 table root pointer is 1'. Signed-off-by: Adrian Huang Fixes: 52815b75682e2 ("iommu/amd: Add support for IOMMUv2 domain mode") Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 436af737c3c2831dd0505a6a1247b1ec0d8f6375 Author: Dan Carpenter Date: Tue Feb 25 19:20:56 2020 +0300 libnvdimm: Out of bounds read in __nd_ioctl() [ Upstream commit f84afbdd3a9e5e10633695677b95422572f920dc ] The "cmd" comes from the user and it can be up to 255. It it's more than the number of bits in long, it results out of bounds read when we check test_bit(cmd, &cmd_mask). The highest valid value for "cmd" is ND_CMD_CALL (10) so I added a compare against that. Fixes: 62232e45f4a2 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200225162055.amtosfy7m35aivxg@kili.mountain Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit dcb122749f58ece13ad7d3c353e3cc784a2bf7a2 Author: Jeffery Miller Date: Tue Feb 25 16:59:41 2020 -0600 power: supply: axp288_fuel_gauge: Broaden vendor check for Intel Compute Sticks. [ Upstream commit e42fe5b29ac07210297e75f36deefe54edbdbf80 ] The Intel Compute Stick `STK1A32SC` can have a system vendor of "Intel(R) Client Systems". Broaden the Intel Compute Stick DMI checks so that they match "Intel Corporation" as well as "Intel(R) Client Systems". This fixes an issue where the STK1A32SC compute sticks were still exposing a battery with the existing blacklist entry. Signed-off-by: Jeffery Miller Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 760eecac993b7734d37aa3f0766cea7220f0a048 Author: Guo Ren Date: Wed Feb 26 10:23:26 2020 +0800 csky: Fixup init_fpu compile warning with __init [ Upstream commit 12879bda3c2a974b7e4fe199a9c21f0c5f6bca04 ] WARNING: vmlinux.o(.text+0x2366): Section mismatch in reference from the function csky_start_secondary() to the function .init.text:init_fpu() The function csky_start_secondary() references the function __init init_fpu(). This is often because csky_start_secondary lacks a __init annotation or the annotation of init_fpu is wrong. Reported-by: Lu Chongzhi Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit 1500c7003146d6047b1a5cba0ccae4981eda93e6 Author: Chuck Lever Date: Wed Mar 11 11:21:07 2020 -0400 sunrpc: Fix gss_unwrap_resp_integ() again [ Upstream commit 4047aa909c4a40fceebc36fff708d465a4d3c6e2 ] xdr_buf_read_mic() tries to find unused contiguous space in a received xdr_buf in order to linearize the checksum for the call to gss_verify_mic. However, the corner cases in this code are numerous and we seem to keep missing them. I've just hit yet another buffer overrun related to it. This overrun is at the end of xdr_buf_read_mic(): 1284 if (buf->tail[0].iov_len != 0) 1285 mic->data = buf->tail[0].iov_base + buf->tail[0].iov_len; 1286 else 1287 mic->data = buf->head[0].iov_base + buf->head[0].iov_len; 1288 __read_bytes_from_xdr_buf(&subbuf, mic->data, mic->len); 1289 return 0; This logic assumes the transport has set the length of the tail based on the size of the received message. base + len is then supposed to be off the end of the message but still within the actual buffer. In fact, the length of the tail is set by the upper layer when the Call is encoded so that the end of the tail is actually the end of the allocated buffer itself. This causes the logic above to set mic->data to point past the end of the receive buffer. The "mic->data = head" arm of this if statement is no less fragile. As near as I can tell, this has been a problem forever. I'm not sure that minimizing au_rslack recently changed this pathology much. So instead, let's use a more straightforward approach: kmalloc a separate buffer to linearize the checksum. This is similar to how gss_validate() currently works. Coming back to this code, I had some trouble understanding what was going on. So I've cleaned up the variable naming and added a few comments that point back to the XDR definition in RFC 2203 to help guide future spelunkers, including myself. As an added clean up, the functionality that was in xdr_buf_read_mic() is folded directly into gss_unwrap_resp_integ(), as that is its only caller. Signed-off-by: Chuck Lever Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ddb8812a21e16a955df6b34dde48a8fd8ccbd5d1 Author: Jan Kara Date: Tue Mar 17 12:40:02 2020 +0100 ext2: fix debug reference to ext2_xattr_cache [ Upstream commit 32302085a8d90859c40cf1a5e8313f575d06ec75 ] Fix a debug-only build error in ext2/xattr.c: When building without extra debugging, (and with another patch that uses no_printk() instead of for the ext2-xattr debug-print macros, this build error happens: ../fs/ext2/xattr.c: In function ‘ext2_xattr_cache_insert’: ../fs/ext2/xattr.c:869:18: error: ‘ext2_xattr_cache’ undeclared (first use in this function); did you mean ‘ext2_xattr_list’? atomic_read(&ext2_xattr_cache->c_entry_count)); Fix the problem by removing cached entry count from the debug message since otherwise we'd have to export the mbcache structure just for that. Fixes: be0726d33cb8 ("ext2: convert to mbcache2") Reported-by: Randy Dunlap Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 24191c8c9bd2770e106dea524707f640a2053228 Author: Jacob Pan Date: Tue Mar 17 09:10:18 2020 +0800 iommu/vt-d: Fix page request descriptor size [ Upstream commit 52355fb1919ef7ed9a38e0f3de6e928de1f57217 ] Intel VT-d might support PRS (Page Reqest Support) when it's running in the scalable mode. Each page request descriptor occupies 32 bytes and is 32-bytes aligned. The page request descriptor offset mask should be 32-bytes aligned. Fixes: 5b438f4ba315d ("iommu/vt-d: Support page request in scalable mode") Signed-off-by: Lu Baolu Signed-off-by: Liu Yi L Signed-off-by: Jacob Pan Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a5a1d567a0690ffd5426eae622601861775a8ffc Author: Qian Cai Date: Tue Mar 17 11:03:26 2020 -0400 iommu/vt-d: Silence RCU-list debugging warning in dmar_find_atsr() [ Upstream commit c6f4ebdeba4cff590594df931ff1ee610c426431 ] dmar_find_atsr() calls list_for_each_entry_rcu() outside of an RCU read side critical section but with dmar_global_lock held. Silence this false positive. drivers/iommu/intel-iommu.c:4504 RCU-list traversed in non-reader section!! 1 lock held by swapper/0/1: #0: ffffffff9755bee8 (dmar_global_lock){+.+.}, at: intel_iommu_init+0x1a6/0xe19 Call Trace: dump_stack+0xa4/0xfe lockdep_rcu_suspicious+0xeb/0xf5 dmar_find_atsr+0x1ab/0x1c0 dmar_parse_one_atsr+0x64/0x220 dmar_walk_remapping_entries+0x130/0x380 dmar_table_init+0x166/0x243 intel_iommu_init+0x1ab/0xe19 pci_iommu_init+0x1a/0x44 do_one_initcall+0xae/0x4d0 kernel_init_freeable+0x412/0x4c5 kernel_init+0x19/0x193 Signed-off-by: Qian Cai Acked-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 21439dff919e5bfcc00b8d695ba560a9c30e348f Author: Randy Dunlap Date: Sun Mar 22 19:45:41 2020 -0700 ext2: fix empty body warnings when -Wextra is used [ Upstream commit 44a52022e7f15cbaab957df1c14f7a4f527ef7cf ] When EXT2_ATTR_DEBUG is not defined, modify the 2 debug macros to use the no_printk() macro instead of . This fixes gcc warnings when -Wextra is used: ../fs/ext2/xattr.c:252:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../fs/ext2/xattr.c:258:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../fs/ext2/xattr.c:330:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../fs/ext2/xattr.c:872:45: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] I have verified that the only object code change (with gcc 7.5.0) is the reversal of some instructions from 'cmp a,b' to 'cmp b,a'. Link: https://lore.kernel.org/r/e18a7395-61fb-2093-18e8-ed4f8cf56248@infradead.org Signed-off-by: Randy Dunlap Cc: Jan Kara Cc: linux-ext4@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit d00041a48c3e4d82e81ed1f538bba3972ba5ac9f Author: Olga Kornievskaia Date: Thu Mar 26 10:24:51 2020 -0400 SUNRPC: fix krb5p mount to provide large enough buffer in rq_rcvsize [ Upstream commit df513a7711712758b9cb1a48d86712e7e1ee03f4 ] Ever since commit 2c94b8eca1a2 ("SUNRPC: Use au_rslack when computing reply buffer size"). It changed how "req->rq_rcvsize" is calculated. It used to use au_cslack value which was nice and large and changed it to au_rslack value which turns out to be too small. Since 5.1, v3 mount with sec=krb5p fails against an Ontap server because client's receive buffer it too small. For gss krb5p, we need to account for the mic token in the verifier, and the wrap token in the wrap token. RFC 4121 defines: mic token Octet no Name Description -------------------------------------------------------------- 0..1 TOK_ID Identification field. Tokens emitted by GSS_GetMIC() contain the hex value 04 04 expressed in big-endian order in this field. 2 Flags Attributes field, as described in section 4.2.2. 3..7 Filler Contains five octets of hex value FF. 8..15 SND_SEQ Sequence number field in clear text, expressed in big-endian order. 16..last SGN_CKSUM Checksum of the "to-be-signed" data and octet 0..15, as described in section 4.2.4. that's 16bytes (GSS_KRB5_TOK_HDR_LEN) + chksum wrap token Octet no Name Description -------------------------------------------------------------- 0..1 TOK_ID Identification field. Tokens emitted by GSS_Wrap() contain the hex value 05 04 expressed in big-endian order in this field. 2 Flags Attributes field, as described in section 4.2.2. 3 Filler Contains the hex value FF. 4..5 EC Contains the "extra count" field, in big- endian order as described in section 4.2.3. 6..7 RRC Contains the "right rotation count" in big- endian order, as described in section 4.2.5. 8..15 SND_SEQ Sequence number field in clear text, expressed in big-endian order. 16..last Data Encrypted data for Wrap tokens with confidentiality, or plaintext data followed by the checksum for Wrap tokens without confidentiality, as described in section 4.2.4. Also 16bytes of header (GSS_KRB5_TOK_HDR_LEN), encrypted data, and cksum (other things like padding) RFC 3961 defines known cksum sizes: Checksum type sumtype checksum section or value size reference --------------------------------------------------------------------- CRC32 1 4 6.1.3 rsa-md4 2 16 6.1.2 rsa-md4-des 3 24 6.2.5 des-mac 4 16 6.2.7 des-mac-k 5 8 6.2.8 rsa-md4-des-k 6 16 6.2.6 rsa-md5 7 16 6.1.1 rsa-md5-des 8 24 6.2.4 rsa-md5-des3 9 24 ?? sha1 (unkeyed) 10 20 ?? hmac-sha1-des3-kd 12 20 6.3 hmac-sha1-des3 13 20 ?? sha1 (unkeyed) 14 20 ?? hmac-sha1-96-aes128 15 20 [KRB5-AES] hmac-sha1-96-aes256 16 20 [KRB5-AES] [reserved] 0x8003 ? [GSS-KRB5] Linux kernel now mainly supports type 15,16 so max cksum size is 20bytes. (GSS_KRB5_MAX_CKSUM_LEN) Re-use already existing define of GSS_KRB5_MAX_SLACK_NEEDED that's used for encoding the gss_wrap tokens (same tokens are used in reply). Fixes: 2c94b8eca1a2 ("SUNRPC: Use au_rslack when computing reply buffer size") Signed-off-by: Olga Kornievskaia Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 900cd0f6c688bfd87648bbca02f5bf34ef5a5af2 Author: Jacob Pan Date: Thu Mar 19 21:32:30 2020 -0700 iommu/vt-d: Fix mm reference leak [ Upstream commit 902baf61adf6b187f0a6b789e70d788ea71ff5bc ] Move canonical address check before mmget_not_zero() to avoid mm reference leak. Fixes: 9d8c3af31607 ("iommu/vt-d: IOMMU Page Request needs to check if address is canonical.") Signed-off-by: Jacob Pan Acked-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 9c01a49a7117fa824ee0703c9f46b2fa54dfd94d Author: Jean-Philippe Brucker Date: Thu Mar 26 10:35:57 2020 +0100 iommu/virtio: Fix freeing of incomplete domains [ Upstream commit 7062af3ed2ba451029e3733d9f677c68f5ea9e77 ] Calling viommu_domain_free() on a domain that hasn't been finalised (not attached to any device, for example) can currently cause an Oops, because we attempt to call ida_free() on ID 0, which may either be unallocated or used by another domain. Only initialise the vdomain->viommu pointer, which denotes a finalised domain, at the end of a successful viommu_domain_finalise(). Fixes: edcd69ab9a32 ("iommu: Add virtio-iommu driver") Reported-by: Eric Auger Signed-off-by: Jean-Philippe Brucker Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20200326093558.2641019-3-jean-philippe@linaro.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 475bec7063bcc941c3bbb4acc9c9f402259afadc Author: Nicolas Saenz Julienne Date: Thu Mar 26 13:20:01 2020 +0100 drm/vc4: Fix HDMI mode validation [ Upstream commit b1e7396a1d0e6af6806337fdaaa44098d6b3343c ] Current mode validation impedes setting up some video modes which should be supported otherwise. Namely 1920x1200@60Hz. Fix this by lowering the minimum HDMI state machine clock to pixel clock ratio allowed. Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.") Reported-by: Stefan Wahren Suggested-by: Dave Stevenson Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulienne@suse.de Signed-off-by: Sasha Levin commit b58244c482cebbdfba6e806027ea0e8458cc304a Author: Alan Maguire Date: Tue Mar 17 17:35:34 2020 +0000 um: falloc.h needs to be directly included for older libc [ Upstream commit 35f3401317a3b26aa01fde8facfd320f2628fdcc ] When building UML with glibc 2.17 installed, compilation of arch/um/os-Linux/file.c fails due to failure to find FALLOC_FL_PUNCH_HOLE and FALLOC_FL_KEEP_SIZE definitions. It appears that /usr/include/bits/fcntl-linux.h (indirectly included by /usr/include/fcntl.h) does not include falloc.h with an older glibc, whereas a more up-to-date version does. Adding the direct include to file.c resolves the issue and does not cause problems for more recent glibc. Fixes: 50109b5a03b4 ("um: Add support for DISCARD in the UBD Driver") Cc: Brendan Higgins Signed-off-by: Alan Maguire Reviewed-by: Brendan Higgins Acked-By: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 6c3339269a8af0ee4d3661ec28b0fb06b79191ec Author: Bob Moore Date: Fri Mar 27 15:21:09 2020 -0700 ACPICA: Fixes for acpiExec namespace init file [ Upstream commit 9a1ae80412dcaa67a29eecf19de44f32b5f1c357 ] This is the result of squashing the following ACPICA commit ID's: 6803997e5b4f3635cea6610b51ff69e29d251de3 f31cdf8bfda22fe265c1a176d0e33d311c82a7f7 This change fixes several problems with the support for the acpi_exec namespace init file (-fi option). Specifically, it fixes AE_ALREADY_EXISTS errors, as well as various seg faults. Link: https://github.com/acpica/acpica/commit/f31cdf8b Link: https://github.com/acpica/acpica/commit/6803997e Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9f8b1216dac997de2dbcee04d1820306e33eacbb Author: Chao Yu Date: Thu Mar 19 19:58:00 2020 +0800 f2fs: fix NULL pointer dereference in f2fs_write_begin() [ Upstream commit 62f63eea291b50a5677ae7503ac128803174698a ] BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:f2fs_write_begin+0x823/0xb90 [f2fs] Call Trace: f2fs_quota_write+0x139/0x1d0 [f2fs] write_blk+0x36/0x80 [quota_tree] get_free_dqblk+0x42/0xa0 [quota_tree] do_insert_tree+0x235/0x4a0 [quota_tree] do_insert_tree+0x26e/0x4a0 [quota_tree] do_insert_tree+0x26e/0x4a0 [quota_tree] do_insert_tree+0x26e/0x4a0 [quota_tree] qtree_write_dquot+0x70/0x190 [quota_tree] v2_write_dquot+0x43/0x90 [quota_v2] dquot_acquire+0x77/0x100 f2fs_dquot_acquire+0x2f/0x60 [f2fs] dqget+0x310/0x450 dquot_transfer+0x7e/0x120 f2fs_setattr+0x11a/0x4a0 [f2fs] notify_change+0x349/0x480 chown_common+0x168/0x1c0 do_fchownat+0xbc/0xf0 __x64_sys_fchownat+0x20/0x30 do_syscall_64+0x5f/0x220 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Passing fsdata parameter to .write_{begin,end} in f2fs_quota_write(), so that if quota file is compressed one, we can avoid above NULL pointer dereference when updating quota content. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 57615a8561f0b9fef57f18c2c51cb08f679307c8 Author: Guo Ren Date: Tue Mar 31 23:45:52 2020 +0800 csky: Fixup get wrong psr value from phyical reg [ Upstream commit 9c0e343d7654a329d1f9b53d253cbf7fb6eff85d ] We should get psr value from regs->psr in stack, not directly get it from phyiscal register then save the vector number in tsk->trap_no. Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit c848e00e3b950a3f468fa0e03b4d3fc4adc7adbe Author: Trond Myklebust Date: Sun Mar 29 20:06:45 2020 -0400 NFS: Fix memory leaks in nfs_pageio_stop_mirroring() [ Upstream commit 862f35c94730c9270833f3ad05bd758a29f204ed ] If we just set the mirror count to 1 without first clearing out the mirrors, we can leak queued up requests. Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 2e03d3c569b6e60725acba3f80d74afdd1ca94e6 Author: Jack Zhang Date: Wed Apr 1 20:06:58 2020 +0800 drm/amdkfd: kfree the wrong pointer [ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ] Originally, it kfrees the wrong pointer for mem_obj. It would cause memory leak under stress test. Signed-off-by: Jack Zhang Acked-by: Nirmoy Das Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e907a0d09b34e63163fb73b6826805e334ae3e11 Author: Guo Ren Date: Sat Mar 28 19:14:37 2020 +0800 csky: Fixup cpu speculative execution to IO area [ Upstream commit aefd9461d34a1b0a2acad0750c43216c1c27b9d4 ] For the memory size ( > 512MB, < 1GB), the MSA setting is: - SSEG0: PHY_START , PHY_START + 512MB - SSEG1: PHY_START + 512MB, PHY_START + 1GB But the real memory is no more than 1GB, there is a gap between the end size of memory and border of 1GB. CPU could speculatively execute to that gap and if the gap of the bus couldn't respond to the CPU request, then the crash will happen. Now make the setting with: - SSEG0: PHY_START , PHY_START + 512MB (no change) - SSEG1: Disabled (We use highmem to use the memory of 512MB~1GB) We also deprecated zhole_szie[] settings, it's only used by arm style CPUs. All memory gap should use Reserved setting of dts in csky system. Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit 88591187bebc0140acb3901cb7e73c7442f92771 Author: Qian Cai Date: Fri Apr 3 10:03:45 2020 -0400 x86: ACPI: fix CPU hotplug deadlock [ Upstream commit 696ac2e3bf267f5a2b2ed7d34e64131f2287d0ad ] Similar to commit 0266d81e9bf5 ("acpi/processor: Prevent cpu hotplug deadlock") except this is for acpi_processor_ffh_cstate_probe(): "The problem is that the work is scheduled on the current CPU from the hotplug thread associated with that CPU. It's not required to invoke these functions via the workqueue because the hotplug thread runs on the target CPU already. Check whether current is a per cpu thread pinned on the target CPU and invoke the function directly to avoid the workqueue." WARNING: possible circular locking dependency detected ------------------------------------------------------ cpuhp/1/15 is trying to acquire lock: ffffc90003447a28 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: __flush_work+0x4c6/0x630 but task is already holding lock: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x3e/0xc0 irq_calc_affinity_vectors+0x5f/0x91 __pci_enable_msix_range+0x10f/0x9a0 pci_alloc_irq_vectors_affinity+0x13e/0x1f0 pci_alloc_irq_vectors_affinity at drivers/pci/msi.c:1208 pqi_ctrl_init+0x72f/0x1618 [smartpqi] pqi_pci_probe.cold.63+0x882/0x892 [smartpqi] local_pci_probe+0x7a/0xc0 work_for_cpu_fn+0x2e/0x50 process_one_work+0x57e/0xb90 worker_thread+0x363/0x5b0 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50 -> #0 ((work_completion)(&wfc.work)){+.+.}-{0:0}: __lock_acquire+0x2244/0x32a0 lock_acquire+0x1a2/0x680 __flush_work+0x4e6/0x630 work_on_cpu+0x114/0x160 acpi_processor_ffh_cstate_probe+0x129/0x250 acpi_processor_evaluate_cst+0x4c8/0x580 acpi_processor_get_power_info+0x86/0x740 acpi_processor_hotplug+0xc3/0x140 acpi_soft_cpu_online+0x102/0x1d0 cpuhp_invoke_callback+0x197/0x1120 cpuhp_thread_fun+0x252/0x2f0 smpboot_thread_fn+0x255/0x440 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50 other info that might help us debug this: Chain exists of: (work_completion)(&wfc.work) --> cpuhp_state-up --> cpuidle_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(cpuidle_lock); lock(cpuhp_state-up); lock(cpuidle_lock); lock((work_completion)(&wfc.work)); *** DEADLOCK *** 3 locks held by cpuhp/1/15: #0: ffffffffaf51ab10 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0 #1: ffffffffaf51ad40 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0 #2: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20 Call Trace: dump_stack+0xa0/0xea print_circular_bug.cold.52+0x147/0x14c check_noncircular+0x295/0x2d0 __lock_acquire+0x2244/0x32a0 lock_acquire+0x1a2/0x680 __flush_work+0x4e6/0x630 work_on_cpu+0x114/0x160 acpi_processor_ffh_cstate_probe+0x129/0x250 acpi_processor_evaluate_cst+0x4c8/0x580 acpi_processor_get_power_info+0x86/0x740 acpi_processor_hotplug+0xc3/0x140 acpi_soft_cpu_online+0x102/0x1d0 cpuhp_invoke_callback+0x197/0x1120 cpuhp_thread_fun+0x252/0x2f0 smpboot_thread_fn+0x255/0x440 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50 Signed-off-by: Qian Cai Tested-by: Borislav Petkov [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit a9282e58238d228c76fbefa3f1b8200eee716378 Author: Ricardo Ribalda Delgado Date: Wed Apr 1 11:51:47 2020 +0200 leds: core: Fix warning message when init_data [ Upstream commit 64ed6588c2ea618d3f9ca9d8b365ae4c19f76225 ] The warning message when a led is renamed due to name collition can fail to show proper original name if init_data is used. Eg: [ 9.073996] leds-gpio a0040000.leds_0: Led (null) renamed to red_led_1 due to name collision Fixes: bb4e9af0348d ("leds: core: Add support for composing LED class device names") Signed-off-by: Ricardo Ribalda Delgado Acked-by: Jacek Anaszewski Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit ddf39dc2f7a306d1097eb011fc8c9d20e51da779 Author: Karol Herbst Date: Tue Mar 24 21:29:23 2020 +0100 drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges [ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ] Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state, currently in D3" "nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)" followed by backtraces of kernel crashes or timeouts within nouveau. It's still unkown why this issue exists, but this is a reliable workaround and solves a very annoying issue for user having to choose between a crashing kernel or higher power consumption of their Laptops. Signed-off-by: Karol Herbst Cc: Bjorn Helgaas Cc: Lyude Paul Cc: Rafael J. Wysocki Cc: Mika Westerberg Cc: linux-pci@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623 Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit f24d8de03b724fdcb6b8c5f100c2069a8677432f Author: David Hildenbrand Date: Fri Apr 3 17:30:48 2020 +0200 KVM: s390: vsie: Fix possible race when shadowing region 3 tables [ Upstream commit 1493e0f944f3c319d11e067c185c904d01c17ae5 ] We have to properly retry again by returning -EINVAL immediately in case somebody else instantiated the table concurrently. We missed to add the goto in this function only. The code now matches the other, similar shadowing functions. We are overwriting an existing region 2 table entry. All allocated pages are added to the crst_list to be freed later, so they are not lost forever. However, when unshadowing the region 2 table, we wouldn't trigger unshadowing of the original shadowed region 3 table that we replaced. It would get unshadowed when the original region 3 table is modified. As it's not connected to the page table hierarchy anymore, it's not going to get used anymore. However, for a limited time, this page table will stick around, so it's in some sense a temporary memory leak. Identified by manual code inspection. I don't think this classifies as stable material. Fixes: 998f637cc4b9 ("s390/mm: avoid races on region/segment/page table shadowing") Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20200403153050.20569-4-david@redhat.com Reviewed-by: Claudio Imbrenda Reviewed-by: Christian Borntraeger Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 3910babeac1ab031f4e178042cbd1af9a9a0ec51 Author: Vegard Nossum Date: Mon Apr 6 20:09:37 2020 -0700 compiler.h: fix error in BUILD_BUG_ON() reporting [ Upstream commit af9c5d2e3b355854ff0e4acfbfbfadcd5198a349 ] compiletime_assert() uses __LINE__ to create a unique function name. This means that if you have more than one BUILD_BUG_ON() in the same source line (which can happen if they appear e.g. in a macro), then the error message from the compiler might output the wrong condition. For this source file: #include #define macro() \ BUILD_BUG_ON(1); \ BUILD_BUG_ON(0); void foo() { macro(); } gcc would output: ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_9' declared with attribute error: BUILD_BUG_ON failed: 0 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) However, it was not the BUILD_BUG_ON(0) that failed, so it should say 1 instead of 0. With this patch, we use __COUNTER__ instead of __LINE__, so each BUILD_BUG_ON() gets a different function name and the correct condition is printed: ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_0' declared with attribute error: BUILD_BUG_ON failed: 1 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) Signed-off-by: Vegard Nossum Signed-off-by: Andrew Morton Reviewed-by: Masahiro Yamada Reviewed-by: Daniel Santos Cc: Rasmus Villemoes Cc: Ian Abbott Cc: Joe Perches Link: http://lkml.kernel.org/r/20200331112637.25047-1-vegard.nossum@oracle.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b525f94f16e52e7833419ac3812f0d8afb032fe4 Author: Qian Cai Date: Mon Apr 6 20:10:25 2020 -0700 percpu_counter: fix a data race at vm_committed_as [ Upstream commit 7e2345200262e4a6056580f0231cccdaffc825f3 ] "vm_committed_as.count" could be accessed concurrently as reported by KCSAN, BUG: KCSAN: data-race in __vm_enough_memory / percpu_counter_add_batch write to 0xffffffff9451c538 of 8 bytes by task 65879 on cpu 35: percpu_counter_add_batch+0x83/0xd0 percpu_counter_add_batch at lib/percpu_counter.c:91 __vm_enough_memory+0xb9/0x260 dup_mm+0x3a4/0x8f0 copy_process+0x2458/0x3240 _do_fork+0xaa/0x9f0 __do_sys_clone+0x125/0x160 __x64_sys_clone+0x70/0x90 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe read to 0xffffffff9451c538 of 8 bytes by task 66773 on cpu 19: __vm_enough_memory+0x199/0x260 percpu_counter_read_positive at include/linux/percpu_counter.h:81 (inlined by) __vm_enough_memory at mm/util.c:839 mmap_region+0x1b2/0xa10 do_mmap+0x45c/0x700 vm_mmap_pgoff+0xc0/0x130 ksys_mmap_pgoff+0x6e/0x300 __x64_sys_mmap+0x33/0x40 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe The read is outside percpu_counter::lock critical section which results in a data race. Fix it by adding a READ_ONCE() in percpu_counter_read_positive() which could also service as the existing compiler memory barrier. Signed-off-by: Qian Cai Signed-off-by: Andrew Morton Acked-by: Marco Elver Link: http://lkml.kernel.org/r/1582302724-2804-1-git-send-email-cai@lca.pw Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ffac60b8bc5f1cd51ac8afa497e895ae12cb488c Author: Steven Price Date: Mon Apr 6 20:08:43 2020 -0700 include/linux/swapops.h: correct guards for non_swap_entry() [ Upstream commit 3f3673d7d324d872d9d8ddb73b3e5e47fbf12e0d ] If CONFIG_DEVICE_PRIVATE is defined, but neither CONFIG_MEMORY_FAILURE nor CONFIG_MIGRATION, then non_swap_entry() will return 0, meaning that the condition (non_swap_entry(entry) && is_device_private_entry(entry)) in zap_pte_range() will never be true even if the entry is a device private one. Equally any other code depending on non_swap_entry() will not function as expected. I originally spotted this just by looking at the code, I haven't actually observed any problems. Looking a bit more closely it appears that actually this situation (currently at least) cannot occur: DEVICE_PRIVATE depends on ZONE_DEVICE ZONE_DEVICE depends on MEMORY_HOTREMOVE MEMORY_HOTREMOVE depends on MIGRATION Fixes: 5042db43cc26 ("mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory") Signed-off-by: Steven Price Signed-off-by: Andrew Morton Cc: Jérôme Glisse Cc: Arnd Bergmann Cc: Dan Williams Cc: John Hubbard Link: http://lkml.kernel.org/r/20200305130550.22693-1-steven.price@arm.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2a40eaab1fc4a863849493f86010274a39966588 Author: Ralph Campbell Date: Tue Mar 3 16:13:36 2020 -0800 drm/nouveau/svm: fix vma range check for migration [ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ] find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for this and can call migrate_vma_setup() with a starting address less than vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for the range instead of nouveau skipping that part of the range and migrating the rest. Signed-off-by: Ralph Campbell Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit f3955f1e58bec57ee2176aa81e6521461e977454 Author: Ralph Campbell Date: Tue Mar 3 16:13:37 2020 -0800 drm/nouveau/svm: check for SVM initialized before migrating [ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ] When migrating system memory to GPU memory, check that SVM has been enabled. Even though most errors can be ignored since migration is a performance optimization, return an error because this is a violation of the API. Signed-off-by: Ralph Campbell Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit a825ce86ebeddcb8467528297c5425fc5cd5edd8 Author: Christophe Leroy Date: Wed Apr 1 21:11:54 2020 -0700 mm/hugetlb: fix build failure with HUGETLB_PAGE but not HUGEBTLBFS [ Upstream commit bb297bb2de517e41199185021f043bbc5d75b377 ] When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the following build failure is encoutered: In file included from arch/powerpc/mm/fault.c:33:0: include/linux/hugetlb.h: In function 'hstate_inode': include/linux/hugetlb.h:477:9: error: implicit declaration of function 'HUGETLBFS_SB' [-Werror=implicit-function-declaration] return HUGETLBFS_SB(i->i_sb)->hstate; ^ include/linux/hugetlb.h:477:30: error: invalid type argument of '->' (have 'int') return HUGETLBFS_SB(i->i_sb)->hstate; ^ Gate hstate_inode() with CONFIG_HUGETLBFS instead of CONFIG_HUGETLB_PAGE. Fixes: a137e1cc6d6e ("hugetlbfs: per mount huge page sizes") Reported-by: kbuild test robot Signed-off-by: Christophe Leroy Signed-off-by: Andrew Morton Reviewed-by: Mike Kravetz Cc: Baoquan He Cc: Nishanth Aravamudan Cc: Nick Piggin Cc: Adam Litke Cc: Andi Kleen Link: http://lkml.kernel.org/r/7e8c3a3c9a587b9cd8a2f146df32a421b961f3a2.1584432148.git.christophe.leroy@c-s.fr Link: https://patchwork.ozlabs.org/patch/1255548/#2386036 Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 23e2519760f82c3e45a9fcab4713163c17e6daf4 Author: Long Li Date: Thu Mar 26 22:09:20 2020 -0700 cifs: Allocate encryption header through kmalloc [ Upstream commit 3946d0d04bb360acca72db5efe9ae8440012d9dc ] When encryption is used, smb2_transform_hdr is defined on the stack and is passed to the transport. This doesn't work with RDMA as the buffer needs to be DMA'ed. Fix it by using kmalloc. Signed-off-by: Long Li Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6ba010ea48563b3a01cbdffb5daf289ee8c76a84 Author: Gabriel Krisman Bertazi Date: Mon Mar 16 20:45:06 2020 -0400 um: ubd: Prevent buffer overrun on command completion [ Upstream commit 6e682d53fc1ef73a169e2a5300326cb23abb32ee ] On the hypervisor side, when completing commands and the pipe is full, we retry writing only the entries that failed, by offsetting io_req_buffer, but we don't reduce the number of bytes written, which can cause a buffer overrun of io_req_buffer, and write garbage to the pipe. Cc: Martyn Welch Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit b9f88c31b266475305d624c109167f5d3e113231 Author: Eric Sandeen Date: Wed Mar 18 14:19:38 2020 -0500 ext4: do not commit super on read-only bdev [ Upstream commit c96e2b8564adfb8ac14469ebc51ddc1bfecb3ae2 ] Under some circumstances we may encounter a filesystem error on a read-only block device, and if we try to save the error info to the superblock and commit it, we'll wind up with a noisy error and backtrace, i.e.: [ 3337.146838] EXT4-fs error (device pmem1p2): ext4_get_journal_inode:4634: comm mount: inode #0: comm mount: iget: illegal inode # ------------[ cut here ]------------ generic_make_request: Trying to write to read-only block-device pmem1p2 (partno 2) WARNING: CPU: 107 PID: 115347 at block/blk-core.c:788 generic_make_request_checks+0x6b4/0x7d0 ... To avoid this, commit the error info in the superblock only if the block device is writable. Reported-by: Ritesh Harjani Signed-off-by: Eric Sandeen Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/4b6e774d-cc00-3469-7abb-108eb151071a@sandeen.net Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4078dceb122861b1fac5144a702dadbf998303a1 Author: Thomas Richter Date: Mon Mar 23 11:09:07 2020 +0100 s390/cpum_sf: Fix wrong page count in error message [ Upstream commit 4141b6a5e9f171325effc36a22eb92bf961e7a5c ] When perf record -e SF_CYCLES_BASIC_DIAG runs with very high frequency, the samples arrive faster than the perf process can save them to file. Eventually, for longer running processes, this leads to the siutation where the trace buffers allocated by perf slowly fills up. At one point the auxiliary trace buffer is full and the CPU Measurement sampling facility is turned off. Furthermore a warning is printed to the kernel log buffer: cpum_sf: The AUX buffer with 0 pages for the diagnostic-sampling mode is full The number of allocated pages for the auxiliary trace buffer is shown as zero pages. That is wrong. Fix this by saving the number of allocated pages before entering the work loop in the interrupt handler. When the interrupt handler processes the samples, it may detect the buffer full condition and stop sampling, reducing the buffer size to zero. Print the correct value in the error message: cpum_sf: The AUX buffer with 256 pages for the diagnostic-sampling mode is full Signed-off-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit fd80f4a6805ca7772c2de7559ccef21ea5ba6289 Author: Nathan Chancellor Date: Mon Mar 23 15:27:29 2020 -0700 powerpc/maple: Fix declaration made after definition [ Upstream commit af6cf95c4d003fccd6c2ecc99a598fb854b537e7 ] When building ppc64 defconfig, Clang errors (trimmed for brevity): arch/powerpc/platforms/maple/setup.c:365:1: error: attribute declaration must precede definition [-Werror,-Wignored-attributes] machine_device_initcall(maple, maple_cpc925_edac_setup); ^ machine_device_initcall expands to __define_machine_initcall, which in turn has the macro machine_is used in it, which declares mach_##name with an __attribute__((weak)). define_machine actually defines mach_##name, which in this file happens before the declaration, hence the warning. To fix this, move define_machine after machine_device_initcall so that the declaration occurs before the definition, which matches how machine_device_initcall and define_machine work throughout arch/powerpc. While we're here, remove some spaces before tabs. Fixes: 8f101a051ef0 ("edac: cpc925 MC platform device setup") Reported-by: Nick Desaulniers Suggested-by: Ilie Halip Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200323222729.15365-1-natechancellor@gmail.com Signed-off-by: Sasha Levin commit bee9bc3e0248be297abc977b19e0aa8378ffa874 Author: Alexey Kardashevskiy Date: Thu Mar 12 18:44:04 2020 +1100 powerpc/prom_init: Pass the "os-term" message to hypervisor [ Upstream commit 74bb84e5117146fa73eb9d01305975c53022b3c3 ] The "os-term" RTAS calls has one argument with a message address of OS termination cause. rtas_os_term() already passes it but the recently added prom_init's version of that missed it; it also does not fill args correctly. This passes the message address and initializes the number of arguments. Fixes: 6a9c930bd775 ("powerpc/prom_init: Add the ESM call to prom_init") Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200312074404.87293-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 7650522178477a5eef85199a73689b5c3409a783 Author: Madhuparna Bhowmik Date: Fri Mar 6 12:22:43 2020 +0530 btrfs: add RCU locks around block group initialization [ Upstream commit 29566c9c773456467933ee22bbca1c2b72a3506c ] The space_info list is normally RCU protected and should be traversed with rcu_read_lock held. There's a warning [29.104756] WARNING: suspicious RCU usage [29.105046] 5.6.0-rc4-next-20200305 #1 Not tainted [29.105231] ----------------------------- [29.105401] fs/btrfs/block-group.c:2011 RCU-list traversed in non-reader section!! pointing out that the locking is missing in btrfs_read_block_groups. However this is not necessary as the list traversal happens at mount time when there's no other thread potentially accessing the list. To fix the warning and for consistency let's add the RCU lock/unlock, the code won't be affected much as it's doing some lightweight operations. Reported-by: Guenter Roeck Signed-off-by: Madhuparna Bhowmik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 285f25c97f24a91c0c9765dcb8ccfa67cb2fecc8 Author: Domenico Andreoli Date: Mon Mar 23 08:22:15 2020 -0700 hibernate: Allow uswsusp to write to swap [ Upstream commit 56939e014a6c212b317414faa307029e2e80c3b9 ] It turns out that there is one use case for programs being able to write to swap devices, and that is the userspace hibernation code. Quick fix: disable the S_SWAPFILE check if hibernation is configured. Fixes: dc617f29dbe5 ("vfs: don't allow writes to swap files") Reported-by: Domenico Andreoli Reported-by: Marian Klein Signed-off-by: Domenico Andreoli Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 4753b111f003f3c193d6313ffcd859424cc33c14 Author: Alexander Gordeev Date: Mon Mar 16 12:39:55 2020 +0100 s390/cpuinfo: fix wrong output when CPU0 is offline [ Upstream commit 872f27103874a73783aeff2aac2b41a489f67d7c ] /proc/cpuinfo should not print information about CPU 0 when it is offline. Fixes: 281eaa8cb67c ("s390/cpuinfo: simplify locking and skip offline cpus early") Signed-off-by: Alexander Gordeev Reviewed-by: Heiko Carstens [heiko.carstens@de.ibm.com: shortened commit message] Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 380d1290460345bc69aadd3d4ca9e73b62f29cb8 Author: Sahitya Tummala Date: Tue Mar 3 19:59:26 2020 +0530 f2fs: Add a new CP flag to help fsck fix resize SPO issues [ Upstream commit c84ef3c5e65ccf99a7a91a4d731ebb5d6331a178 ] Add and set a new CP flag CP_RESIZEFS_FLAG during online resize FS to help fsck fix the metadata mismatch that may happen due to SPO during resize, where SB got updated but CP data couldn't be written yet. fsck errors - Info: CKPT version = 6ed7bccb Wrong user_block_count(2233856) [f2fs_do_mount:3365] Checkpoint is polluted Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 066f1e4174f2adbee9aaf19e7e236289e68ce756 Author: Sahitya Tummala Date: Tue Mar 3 19:59:25 2020 +0530 f2fs: Fix mount failure due to SPO after a successful online resize FS [ Upstream commit 682756827501dc52593bf490f2d437c65ec9efcb ] Even though online resize is successfully done, a SPO immediately after resize, still causes below error in the next mount. [ 11.294650] F2FS-fs (sda8): Wrong user_block_count: 2233856 [ 11.300272] F2FS-fs (sda8): Failed to get valid F2FS checkpoint This is because after FS metadata is updated in update_fs_metadata() if the SBI_IS_DIRTY is not dirty, then CP will not be done to reflect the new user_block_count. Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ea468f37370a92c64656b3a7b51406cfab212188 Author: Misono Tomohiro Date: Wed Aug 28 17:01:22 2019 +0900 NFS: direct.c: Fix memory leak of dreq when nfs_get_lock_context fails [ Upstream commit 8605cf0e852af3b2c771c18417499dc4ceed03d5 ] When dreq is allocated by nfs_direct_req_alloc(), dreq->kref is initialized to 2. Therefore we need to call nfs_direct_req_release() twice to release the allocated dreq. Usually it is called in nfs_file_direct_{read, write}() and nfs_direct_complete(). However, current code only calls nfs_direct_req_relese() once if nfs_get_lock_context() fails in nfs_file_direct_{read, write}(). So, that case would result in memory leak. Fix this by adding the missing call. Signed-off-by: Misono Tomohiro Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 81b41f5ecc966a10b46e6e53f5a7c0c10c059cca Author: Kunihiko Hayashi Date: Thu Jan 30 15:52:41 2020 +0900 phy: uniphier-usb3ss: Add Pro5 support [ Upstream commit 9376fa634afc207a3ce99e0957e04948c34d6510 ] Pro5 SoC has same scheme of USB3 ss-phy as Pro4, so the data for Pro5 is equivalent to Pro4. Signed-off-by: Kunihiko Hayashi Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 3e85d501828c37ecb7dfc7a82d7a3cc4e5519809 Author: Chao Yu Date: Fri Feb 14 17:45:11 2020 +0800 f2fs: fix to show norecovery mount option [ Upstream commit a9117eca1de6b738e713d2142126db2cfbf6fb36 ] Previously, 'norecovery' mount option will be shown as 'disable_roll_forward', fix to show original option name correctly. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ffbad91b66ce45519c38fcc0a9500bbca9bc974a Author: Michael Roth Date: Tue Mar 10 16:11:28 2020 -0500 KVM: PPC: Book3S HV: Fix H_CEDE return code for nested guests [ Upstream commit 1f50cc1705350a4697923203fedd7d8fb1087fe2 ] The h_cede_tm kvm-unit-test currently fails when run inside an L1 guest via the guest/nested hypervisor. ./run-tests.sh -v ... TESTNAME=h_cede_tm TIMEOUT=90s ACCEL= ./powerpc/run powerpc/tm.elf -smp 2,threads=2 -machine cap-htm=on -append "h_cede_tm" FAIL h_cede_tm (2 tests, 1 unexpected failures) While the test relates to transactional memory instructions, the actual failure is due to the return code of the H_CEDE hypercall, which is reported as 224 instead of 0. This happens even when no TM instructions are issued. 224 is the value placed in r3 to execute a hypercall for H_CEDE, and r3 is where the caller expects the return code to be placed upon return. In the case of guest running under a nested hypervisor, issuing H_CEDE causes a return from H_ENTER_NESTED. In this case H_CEDE is specially-handled immediately rather than later in kvmppc_pseries_do_hcall() as with most other hcalls, but we forget to set the return code for the caller, hence why kvm-unit-test sees the 224 return code and reports an error. Guest kernels generally don't check the return value of H_CEDE, so that likely explains why this hasn't caused issues outside of kvm-unit-tests so far. Fix this by setting r3 to 0 after we finish processing the H_CEDE. RHBZ: 1778556 Fixes: 4bad77799fed ("KVM: PPC: Book3S HV: Handle hypercalls correctly when nested") Cc: linuxppc-dev@ozlabs.org Cc: David Gibson Cc: Paul Mackerras Signed-off-by: Michael Roth Reviewed-by: David Gibson Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit ea410f2a1fc8ae32ffd3fea7dfe7acb370cf12f9 Author: Johan Jonker Date: Mon Mar 16 18:46:47 2020 +0100 ARM: dts: rockchip: fix lvds-encoder ports subnode for rk3188-bqedison2qc [ Upstream commit 1a7e99599dffd836fcb720cdc0eaf3cd43d7af4a ] A test with the command below gives this error: arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml: lvds-encoder: 'ports' is a required property Fix error by adding a ports wrapper for port@0 and port@1 inside the 'lvds-encoder' node for rk3188-bqedison2qc. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/ bridge/lvds-codec.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200316174647.5598-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 59bafdc99440ca6aef8bd1a93491d637a09853f2 Author: Murphy Zhou Date: Fri Feb 14 22:34:09 2020 +0800 NFSv4.2: error out when relink swapfile [ Upstream commit f5fdf1243fb750598b46305dd03c553949cfa14f ] This fixes xfstests generic/356 failure on NFSv4.2. Signed-off-by: Murphy Zhou Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 264e3f1597e8f6d45caf815f6883c4c98a8ed056 Author: Trond Myklebust Date: Thu Feb 27 11:01:12 2020 -0500 NFSv4/pnfs: Return valid stateids in nfs_layout_find_inode_by_stateid() [ Upstream commit d911c57a19551c6bef116a3b55c6b089901aacb0 ] Make sure to test the stateid for validity so that we catch instances where the server may have been reusing stateids in nfs_layout_find_inode_by_stateid(). Fixes: 7b410d9ce460 ("pNFS: Delay getting the layout header in CB_LAYOUTRECALL handlers") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 07cd4e8f745cab38a608d2aa04972adf2ea0c756 Author: Trond Myklebust Date: Fri Feb 7 19:32:49 2020 -0500 NFS: alloc_nfs_open_context() must use the file cred when available [ Upstream commit 1d179d6bd67369a52edea8562154b31ee20be1cc ] If we're creating a nfs_open_context() for a specific file pointer, we must use the cred assigned to that file. Fixes: a52458b48af1 ("NFS/NFSD/SUNRPC: replace generic creds with 'struct cred'.") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 66bfacd0f3021d9911a3bfc62d90ab7a1d207fa6 Author: Alexandre Belloni Date: Wed Mar 11 23:39:51 2020 +0100 rtc: 88pm860x: fix possible race condition [ Upstream commit 9cf4789e6e4673d0b2c96fa6bb0c35e81b43111a ] The RTC IRQ is requested before the struct rtc_device is allocated, this may lead to a NULL pointer dereference in the IRQ handler. To fix this issue, allocating the rtc_device struct before requesting the RTC IRQ using devm_rtc_allocate_device, and use rtc_register_device to register the RTC device. Also remove the unnecessary error message as the core already prints the info. Link: https://lore.kernel.org/r/20200311223956.51352-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 56aaa0e8c92a5262e5bde7057972080e8b2f17d6 Author: Kevin Grandemange Date: Thu Mar 12 15:41:45 2020 +0000 dma-coherent: fix integer overflow in the reserved-memory dma allocation [ Upstream commit 286c21de32b904131f8cf6a36ce40b8b0c9c5da3 ] pageno is an int and the PAGE_SHIFT shift is done on an int, overflowing if the memory is bigger than 2G This can be reproduced using for example a reserved-memory of 4G reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; reserved_dma: buffer@0 { compatible = "shared-dma-pool"; no-map; reg = <0x5 0x00000000 0x1 0x0>; }; }; Signed-off-by: Kevin Grandemange Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 960bf4e436ca0eeb72a2b838b3453f823563a0f3 Author: Lucas Stach Date: Fri Mar 13 11:09:12 2020 +0100 soc: imx: gpc: fix power up sequencing [ Upstream commit e0ea2d11f8a08ba7066ff897e16c5217215d1e68 ] Currently we wait only until the PGC inverts the isolation setting before disabling the peripheral clocks. This doesn't ensure that the reset is properly propagated through the peripheral devices in the power domain. Wait until the PGC signals that the power up request is done and wait a bit for resets to propagate before disabling the clocks. Signed-off-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 1e7abaf24875353260007b7b036691612661f360 Author: Russell King Date: Tue Feb 25 11:45:12 2020 +0000 arm64: dts: clearfog-gt-8k: set gigabit PHY reset deassert delay [ Upstream commit 46f94c7818e7ab82758fca74935ef3d454340b4e ] If the mv88e6xxx DSA driver is built as a module, it causes the ethernet driver to re-probe when it's loaded. This in turn causes the gigabit PHY to be momentarily reset and reprogrammed. However, we attempt to reprogram the PHY immediately after deasserting reset, and the PHY ignores the writes. This results in the PHY operating in the wrong mode, and the copper link states down. Set a reset deassert delay of 10ms for the gigabit PHY to avoid this. Fixes: babc5544c293 ("arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal") Signed-off-by: Russell King Acked-by: Baruch Siach Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit d7b59cd020f73c36b58dd504a302e70fe3e0ec96 Author: Jon Hunter Date: Fri Feb 14 13:53:53 2020 +0000 arm64: tegra: Fix Tegra194 PCIe compatible string [ Upstream commit f9f711efd441ad0d22874be49986d92121862335 ] If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled then this can cause the kernel to incorrectly probe the generic designware PCIe platform driver instead of the Tegra194 designware PCIe driver. This causes a boot failure on Tegra194 because the necessary configuration to access the hardware is not performed. The order in which the compatible strings are populated in Device-Tree is not relevant in this case, because the kernel will attempt to probe the device as soon as a driver is loaded and if the generic designware PCIe driver is loaded first, then this driver will be probed first. Therefore, to fix this problem, remove the "snps,dw-pcie" string from the compatible string as we never want this driver to be probe on Tegra194. Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5615f66bfdfcab40cabce3b09e8db7a8457f81e7 Author: Vidya Sagar Date: Tue Mar 3 23:40:50 2020 +0530 arm64: tegra: Add PCIe endpoint controllers nodes for Tegra194 [ Upstream commit 0c988b731e6430f0081991fdb4f63f7fc837df9a ] Add endpoint mode controllers nodes for the dual mode PCIe controllers present in Tegra194 SoC. Signed-off-by: Vidya Sagar Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 540f9620f1927350a46cfd7386b521249a3449df Author: Sowjanya Komatineni Date: Mon Jan 13 23:24:09 2020 -0800 clk: tegra: Fix Tegra PMC clock out parents [ Upstream commit 6fe38aa8cac3a5db38154331742835a4d9740788 ] Tegra PMC clocks clk_out_1, clk_out_2, and clk_out_3 supported parents are osc, osc_div2, osc_div4 and extern clock. Clock driver is using incorrect parents clk_m, clk_m_div2, clk_m_div4 for PMC clocks. This patch fixes this. Tested-by: Dmitry Osipenko Reviewed-by: Dmitry Osipenko Signed-off-by: Sowjanya Komatineni Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b7dee304aa0eb5fc4f3a10d7fe1be14f19def0eb Author: Dmitry Osipenko Date: Mon Mar 9 00:51:43 2020 +0300 power: supply: bq27xxx_battery: Silence deferred-probe error [ Upstream commit 583b53ece0b0268c542a1eafadb62e3d4b0aab8c ] The driver fails to probe with -EPROBE_DEFER if battery's power supply (charger driver) isn't ready yet and this results in a bit noisy error message in KMSG during kernel's boot up. Let's silence the harmless error message. Signed-off-by: Dmitry Osipenko Reviewed-by: Andrew F. Davis Reviewed-by: Pali Rohár Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6a77217148355dc9dacef43d2b3439fcd725d9a9 Author: Jernej Skrabec Date: Sat Jan 25 00:20:10 2020 +0100 arm64: dts: allwinner: a64: Fix display clock register range [ Upstream commit 3e9a1a8b7f811de3eb1445d72f68766b704ad17c ] Register range of display clocks is 0x10000, as it can be seen from DE2 documentation. Fix it. Signed-off-by: Jernej Skrabec Fixes: 2c796fc8f5dbd ("arm64: dts: allwinner: a64: add necessary device tree nodes for DE2 CCU") [wens@csie.org: added fixes tag] Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 5d2861f840bb9bc52330295974feb83a91a427e9 Author: Johan Jonker Date: Sat Mar 7 14:48:37 2020 +0100 ARM: dts: rockchip: fix vqmmc-supply property name for rk3188-bqedison2qc [ Upstream commit 9cd568dc588c5d168615bf34f325fabe33b2c9a0 ] A test with the command below does not detect all errors in combination with 'additionalProperties: false' and allOf: - $ref: "synopsys-dw-mshc-common.yaml#" allOf: - $ref: "mmc-controller.yaml#" 'additionalProperties' applies to all properties that are not accounted-for by 'properties' or 'patternProperties' in the immediate schema. First when we combine rockchip-dw-mshc.yaml, synopsys-dw-mshc-common.yaml and mmc-controller.yaml it gives this error: arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml: mmc@10218000: 'vmmcq-supply' does not match any of the regexes: '^.*@[0-9]+$', '^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)| uhs-(sdr(12|25|50|104)|ddr50))$', 'pinctrl-[0-9]+' 'vmmcq-supply' is not a valid property name for mmc nodes. Fix this error by renaming it to 'vqmmc-supply'. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200307134841.13803-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 1321fb4320e7fdf874d69c6ba21b0af90cdd5d03 Author: Sahitya Tummala Date: Tue Feb 18 09:19:07 2020 +0530 f2fs: fix the panic in do_checkpoint() [ Upstream commit bf22c3cc8ce71454dddd772284773306a68031d8 ] There could be a scenario where f2fs_sync_meta_pages() will not ensure that all F2FS_DIRTY_META pages are submitted for IO. Thus, resulting in the below panic in do_checkpoint() - f2fs_bug_on(sbi, get_pages(sbi, F2FS_DIRTY_META) && !f2fs_cp_error(sbi)); This can happen in a low-memory condition, where shrinker could also be doing the writepage operation (stack shown below) at the same time when checkpoint is running on another core. schedule down_write f2fs_submit_page_write -> by this time, this page in page cache is tagged as PAGECACHE_TAG_WRITEBACK and PAGECACHE_TAG_DIRTY is cleared, due to which f2fs_sync_meta_pages() cannot sync this page in do_checkpoint() path. f2fs_do_write_meta_page __f2fs_write_meta_page f2fs_write_meta_page shrink_page_list shrink_inactive_list shrink_node_memcg shrink_node kswapd Signed-off-by: Sahitya Tummala Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 6d4330391c491cb82f705143bf72606f1bd5de98 Author: Aya Levin Date: Tue Feb 11 14:32:49 2020 -0800 net/mlx5e: Enforce setting of a single FEC mode [ Upstream commit 4bd9d5070b92da012f2715cf8e4859acb78b8f35 ] Ethtool command allow setting of several FEC modes in a single set command. The driver can only set a single FEC mode at a time. With this patch driver will reply not-supported on setting several FEC modes. Signed-off-by: Aya Levin Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 0d03cbfdf3641763c9f79b6dab380f89672e6852 Author: Claudiu Beznea Date: Fri Jan 17 13:36:46 2020 +0200 clk: at91: usb: continue if clk_hw_round_rate() return zero [ Upstream commit b0ecf1c6c6e82da4847900fad0272abfd014666d ] clk_hw_round_rate() may call round rate function of its parents. In case of SAM9X60 two of USB parrents are PLLA and UPLL. These clocks are controlled by clk-sam9x60-pll.c driver. The round rate function for this driver is sam9x60_pll_round_rate() which call in turn sam9x60_pll_get_best_div_mul(). In case the requested rate is not in the proper range (rate < characteristics->output[0].min && rate > characteristics->output[0].max) the sam9x60_pll_round_rate() will return a negative number to its caller (called by clk_core_round_rate_nolock()). clk_hw_round_rate() will return zero in case a negative number is returned by clk_core_round_rate_nolock(). With this, the USB clock will continue its rate computation even caller of clk_hw_round_rate() returned an error. With this, the USB clock on SAM9X60 may not chose the best parent. I detected this after a suspend/resume cycle on SAM9X60. Signed-off-by: Claudiu Beznea Link: https://lkml.kernel.org/r/1579261009-4573-2-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 04e43c7c664a56dd92d1e27d8d9c4577553d5aaf Author: Stephen Boyd Date: Wed Feb 5 15:27:59 2020 -0800 clk: Don't cache errors from clk_ops::get_phase() [ Upstream commit f21cf9c77ee82ef8adfeb2143adfacf21ec1d5cc ] We don't check for errors from clk_ops::get_phase() before storing away the result into the clk_core::phase member. This can lead to some fairly confusing debugfs information if these ops do return an error. Let's skip the store when this op fails to fix this. While we're here, move the locking outside of clk_core_get_phase() to simplify callers from the debugfs side. Cc: Douglas Anderson Cc: Heiko Stuebner Cc: Jerome Brunet Signed-off-by: Stephen Boyd Link: https://lkml.kernel.org/r/20200205232802.29184-2-sboyd@kernel.org Acked-by: Jerome Brunet Signed-off-by: Sasha Levin commit 83321ee302e383409172910d56533381062ff74f Author: xinhui pan Date: Wed Jan 15 14:07:45 2020 +0800 drm/ttm: flush the fence on the bo after we individualize the reservation object [ Upstream commit 1bbcf69e42fe7fd49b6f4339c970729d0e343753 ] As we move the ttm_bo_individualize_resv() upwards, we need flush the copied fence too. Otherwise the driver keeps waiting for fence. run&Kill kfdtest, then perf top. 25.53% [ttm] [k] ttm_bo_delayed_delete 24.29% [kernel] [k] dma_resv_test_signaled_rcu 19.72% [kernel] [k] ww_mutex_lock Fix: 378e2d5b("drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more") Signed-off-by: xinhui pan Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/series/72339/ Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 94ebb1eea0e7174a1290def4613fd7cb70f20760 Author: Tianyu Lan Date: Mon Apr 6 08:53:27 2020 -0700 x86/Hyper-V: Free hv_panic_page when fail to register kmsg dump [ Upstream commit 7f11a2cc10a4ae3a70e2c73361f4a9a33503539b ] If kmsg_dump_register() fails, hv_panic_page will not be used anywhere. So free and reset it. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley Signed-off-by: Tianyu Lan Link: https://lore.kernel.org/r/20200406155331.2105-3-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit d662b44161e4e889ed1ad7e1133730df291207b6 Author: Ilya Dryomov Date: Mon Mar 16 15:52:54 2020 +0100 rbd: call rbd_dev_unprobe() after unwatching and flushing notifies [ Upstream commit 952c48b0ed18919bff7528501e9a3fff8a24f8cd ] rbd_dev_unprobe() is supposed to undo most of rbd_dev_image_probe(), including rbd_dev_header_info(), which means that rbd_dev_header_info() isn't supposed to be called after rbd_dev_unprobe(). However, rbd_dev_image_release() calls rbd_dev_unprobe() before rbd_unregister_watch(). This is racy because a header update notify can sneak in: "rbd unmap" thread ceph-watch-notify worker rbd_dev_image_release() rbd_dev_unprobe() free and zero out header rbd_watch_cb() rbd_dev_refresh() rbd_dev_header_info() read in header The same goes for "rbd map" because rbd_dev_image_probe() calls rbd_dev_unprobe() on errors. In both cases this results in a memory leak. Fixes: fd22aef8b47c ("rbd: move rbd_unregister_watch() call into rbd_dev_image_release()") Signed-off-by: Ilya Dryomov Reviewed-by: Jason Dillaman Signed-off-by: Sasha Levin commit 88a57e387cf0b967fc84a6632086e76b9d6c3431 Author: Ilya Dryomov Date: Fri Mar 13 11:20:51 2020 +0100 rbd: avoid a deadlock on header_rwsem when flushing notifies [ Upstream commit 0e4e1de5b63fa423b13593337a27fd2d2b0bcf77 ] rbd_unregister_watch() flushes notifies and therefore cannot be called under header_rwsem because a header update notify takes header_rwsem to synchronize with "rbd map". If mapping an image fails after the watch is established and a header update notify sneaks in, we deadlock when erroring out from rbd_dev_image_probe(). Move watch registration and unregistration out of the critical section. The only reason they were put there was to make header_rwsem management slightly more obvious. Fixes: 811c66887746 ("rbd: fix rbd map vs notify races") Signed-off-by: Ilya Dryomov Reviewed-by: Jason Dillaman Signed-off-by: Sasha Levin commit a362482b2325fc5fb522b1786225fb8d868590c5 Author: Paolo Valente Date: Sat Mar 21 10:45:21 2020 +0100 block, bfq: invoke flush_idle_tree after reparent_active_queues in pd_offline commit 4d38a87fbb77fb9ff2ff4e914162a8ae6453eff5 upstream. In bfq_pd_offline(), the function bfq_flush_idle_tree() is invoked to flush the rb tree that contains all idle entities belonging to the pd (cgroup) being destroyed. In particular, bfq_flush_idle_tree() is invoked before bfq_reparent_active_queues(). Yet the latter may happen to add some entities to the idle tree. It happens if, in some of the calls to bfq_bfqq_move() performed by bfq_reparent_active_queues(), the queue to move is empty and gets expired. This commit simply reverses the invocation order between bfq_flush_idle_tree() and bfq_reparent_active_queues(). Tested-by: cki-project@redhat.com Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 839b7cd1d8bce99a04a77ba69105c8277c77ee15 Author: Paolo Valente Date: Sat Mar 21 10:45:20 2020 +0100 block, bfq: make reparent_leaf_entity actually work only on leaf entities commit 576682fa52cbd95deb3773449566274f206acc58 upstream. bfq_reparent_leaf_entity() reparents the input leaf entity (a leaf entity represents just a bfq_queue in an entity tree). Yet, the input entity is guaranteed to always be a leaf entity only in two-level entity trees. In this respect, because of the error fixed by commit 14afc5936197 ("block, bfq: fix overwrite of bfq_group pointer in bfq_find_set_group()"), all (wrongly collapsed) entity trees happened to actually have only two levels. After the latter commit, this does not hold any longer. This commit fixes this problem by modifying bfq_reparent_leaf_entity(), so that it searches an active leaf entity down the path that stems from the input entity. Such a leaf entity is guaranteed to exist when bfq_reparent_leaf_entity() is invoked. Tested-by: cki-project@redhat.com Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ad749ca022ad4b5165e636cc74695e43fa43f9b9 Author: Paolo Valente Date: Sat Mar 21 10:45:19 2020 +0100 block, bfq: turn put_queue into release_process_ref in __bfq_bic_change_cgroup commit c8997736650060594845e42c5d01d3118aec8d25 upstream. A bfq_put_queue() may be invoked in __bfq_bic_change_cgroup(). The goal of this put is to release a process reference to a bfq_queue. But process-reference releases may trigger also some extra operation, and, to this goal, are handled through bfq_release_process_ref(). So, turn the invocation of bfq_put_queue() into an invocation of bfq_release_process_ref(). Tested-by: cki-project@redhat.com Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 00d3928737712c0dcfae6019693cb889dd8e8445 Author: David Howells Date: Fri Apr 10 15:23:27 2020 +0100 afs: Fix race between post-modification dir edit and readdir/d_revalidate commit 2105c2820d366b76f38e6ad61c75771881ecc532 upstream. AFS directories are retained locally as a structured file, with lookup being effected by a local search of the file contents. When a modification (such as mkdir) happens, the dir file content is modified locally rather than redownloading the directory. The directory contents are accessed in a number of ways, with a number of different locks schemes: (1) Download of contents - dvnode->validate_lock/write in afs_read_dir(). (2) Lookup and readdir - dvnode->validate_lock/read in afs_dir_iterate(), downgrading from (1) if necessary. (3) d_revalidate of child dentry - dvnode->validate_lock/read in afs_do_lookup_one() downgrading from (1) if necessary. (4) Edit of dir after modification - page locks on individual dir pages. Unfortunately, because (4) uses different locking scheme to (1) - (3), nothing protects against the page being scanned whilst the edit is underway. Even download is not safe as it doesn't lock the pages - relying instead on the validate_lock to serialise as a whole (the theory being that directory contents are treated as a block and always downloaded as a block). Fix this by write-locking dvnode->validate_lock around the edits. Care must be taken in the rename case as there may be two different dirs - but they need not be locked at the same time. In any case, once the lock is taken, the directory version must be rechecked, and the edit skipped if a later version has been downloaded by revalidation (there can't have been any local changes because the VFS holds the inode lock, but there can have been remote changes). Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 42e343cf3285c4525db800a264e51571ae66310c Author: David Howells Date: Sat Apr 11 08:50:45 2020 +0100 afs: Fix afs_d_validate() to set the right directory version commit 40fc81027f892284ce31f8b6de1e497f5b47e71f upstream. If a dentry's version is somewhere between invalid_before and the current directory version, we should be setting it forward to the current version, not backwards to the invalid_before version. Note that we're only doing this at all because dentry::d_fsdata isn't large enough on a 32-bit system. Fix this by using a separate variable for invalid_before so that we don't accidentally clobber the current dir version. Fixes: a4ff7401fbfa ("afs: Keep track of invalid-before version for dentry coherency") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 8c3e4ba0fa7acec881ee87177eab2b28a2c78062 Author: David Howells Date: Wed Apr 8 20:56:20 2020 +0100 afs: Fix rename operation status delivery commit b98f0ec91c42d87a70da42726b852ac8d78a3257 upstream. The afs_deliver_fs_rename() and yfs_deliver_fs_rename() functions both only decode the second file status returned unless the parent directories are different - unfortunately, this means that the xdr pointer isn't advanced and the volsync record will be read incorrectly in such an instance. Fix this by always decoding the second status into the second status/callback block which wasn't being used if the dirs were the same. The afs_update_dentry_version() calls that update the directory data version numbers on the dentries can then unconditionally use the second status record as this will always reflect the state of the destination dir (the two records will be identical if the destination dir is the same as the source dir) Fixes: 260a980317da ("[AFS]: Add "directory write" support.") Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 4eba6ec9644adb68f596ba0720a85fbd222d5a48 Author: David Howells Date: Wed Apr 8 17:32:10 2020 +0100 afs: Fix decoding of inline abort codes from version 1 status records commit 3e0d9892c0e7fa426ca6bf921cb4b543ca265714 upstream. If we're decoding an AFSFetchStatus record and we see that the version is 1 and the abort code is set and we're expecting inline errors, then we store the abort code and ignore the remaining status record (which is correct), but we don't set the flag to say we got a valid abort code. This can affect operation of YFS.RemoveFile2 when removing a file and the operation of {,Y}FS.InlineBulkStatus when prospectively constructing or updating of a set of inodes during a lookup. Fix this to indicate the reception of a valid abort code. Fixes: a38a75581e6e ("afs: Fix unlink to handle YFS.RemoveFile2 better") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 0604b60ef9d7493c275244944204ff7c2ac63991 Author: David Howells Date: Wed Apr 8 16:13:20 2020 +0100 afs: Fix missing XDR advance in xdr_decode_{AFS,YFS}FSFetchStatus() commit c72057b56f7e24865840a6961d801a7f21d30a5f upstream. If we receive a status record that has VNOVNODE set in the abort field, xdr_decode_AFSFetchStatus() and xdr_decode_YFSFetchStatus() don't advance the XDR pointer, thereby corrupting anything subsequent decodes from the same block of data. This has the potential to affect AFS.InlineBulkStatus and YFS.InlineBulkStatus operation, but probably doesn't since the status records are extracted as individual blocks of data and the buffer pointer is reset between blocks. It does affect YFS.RemoveFile2 operation, corrupting the volsync record - though that is not currently used. Other operations abort the entire operation rather than returning an error inline, in which case there is no decoding to be done. Fix this by unconditionally advancing the xdr pointer. Fixes: 684b0f68cf1c ("afs: Fix AFSFetchStatus decoder to provide OpenAFS compatibility") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit 4f7b1e892ed02081392e727455b7b29b2a695b67 Author: Tianyu Lan Date: Mon Apr 6 08:53:31 2020 -0700 x86/Hyper-V: Report crash data in die() when panic_on_oops is set commit f3a99e761efa616028b255b4de58e9b5b87c5545 upstream. When oops happens with panic_on_oops unset, the oops thread is killed by die() and system continues to run. In such case, guest should not report crash register data to host since system still runs. Check panic_on_oops and return directly in hyperv_report_panic() when the function is called in the die() and panic_on_oops is unset. Fix it. Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful") Signed-off-by: Tianyu Lan Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20200406155331.2105-7-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 5097186b279a8544c171eec0bbc409cf267ed25e Author: Tianyu Lan Date: Mon Apr 6 08:53:30 2020 -0700 x86/Hyper-V: Report crash register data when sysctl_record_panic_msg is not set commit 040026df7088c56ccbad28f7042308f67bde63df upstream. When sysctl_record_panic_msg is not set, the panic will not be reported to Hyper-V via hyperv_report_panic_msg(). So the crash should be reported via hyperv_report_panic(). Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley Signed-off-by: Tianyu Lan Link: https://lore.kernel.org/r/20200406155331.2105-6-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 31ebf98817c6a4e68f67dbef03275dc976780590 Author: Tianyu Lan Date: Mon Apr 6 08:53:29 2020 -0700 x86/Hyper-V: Report crash register data or kmsg before running crash kernel commit a11589563e96bf262767294b89b25a9d44e7303b upstream. We want to notify Hyper-V when a Linux guest VM crash occurs, so there is a record of the crash even when kdump is enabled. But crash_kexec_post_notifiers defaults to "false", so the kdump kernel runs before the notifiers and Hyper-V never gets notified. Fix this by always setting crash_kexec_post_notifiers to be true for Hyper-V VMs. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley Signed-off-by: Tianyu Lan Link: https://lore.kernel.org/r/20200406155331.2105-5-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 1ed38a98478fb2b372cfdf47dfd92e26e830c36c Author: Tianyu Lan Date: Mon Apr 6 08:53:28 2020 -0700 x86/Hyper-V: Trigger crash enlightenment only once during system crash. commit 73f26e526f19afb3a06b76b970a76bcac2cafd05 upstream. When a guest VM panics, Hyper-V should be notified only once via the crash synthetic MSRs. Current Linux code might write these crash MSRs twice during a system panic: 1) hyperv_panic/die_event() calling hyperv_report_panic() 2) hv_kmsg_dump() calling hyperv_report_panic_msg() Fix this by not calling hyperv_report_panic() if a kmsg dump has been successfully registered. The notification will happen later via hyperv_report_panic_msg(). Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful") Reviewed-by: Michael Kelley Signed-off-by: Tianyu Lan Link: https://lore.kernel.org/r/20200406155331.2105-4-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 9f38f7b46de0747c1909e8c557aa21715dce20c5 Author: Tianyu Lan Date: Mon Apr 6 08:53:26 2020 -0700 x86/Hyper-V: Unload vmbus channel in hv panic callback commit 74347a99e73ae00b8385f1209aaea193c670f901 upstream. When kdump is not configured, a Hyper-V VM might still respond to network traffic after a kernel panic when kernel parameter panic=0. The panic CPU goes into an infinite loop with interrupts enabled, and the VMbus driver interrupt handler still works because the VMbus connection is unloaded only in the kdump path. The network responses make the other end of the connection think the VM is still functional even though it has panic'ed, which could affect any failover actions that should be taken. Fix this by unloading the VMbus connection during the panic process. vmbus_initiate_unload() could then be called twice (e.g., by hyperv_panic_event() and hv_crash_handler(), so reset the connection state in vmbus_initiate_unload() to ensure the unload is done only once. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley Signed-off-by: Tianyu Lan Link: https://lore.kernel.org/r/20200406155331.2105-2-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit 4c2a34f9f4481bc6ca9ce74cade8ad24227c4a6a Author: Frank Rowand Date: Thu Apr 16 16:42:49 2020 -0500 of: overlay: kmemleak in dup_and_fixup_symbol_prop() commit 478ff649b1c8eb2409b1a54fb75eb46f7c29f140 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 4 of 5. target_path was not freed in the non-error path. Fixes: e0a58f3e08d4 ("of: overlay: remove a dependency on device node full_name") Reported-by: Erhard F. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 93ef21bb1a726bd2106bba584506011c8cee85b9 Author: Frank Rowand Date: Thu Apr 16 16:42:48 2020 -0500 of: unittest: kmemleak in of_unittest_overlay_high_level() commit 145fc138f9aae4f9e1331352e301df28e16aed35 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 3 of 5. of_unittest_overlay_high_level() failed to kfree the newly created property when the property named 'name' is skipped. Fixes: 39a751a4cb7e ("of: change overlay apply input data from unflattened to FDT") Reported-by: Erhard F. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit a1371954ee497836720138b2a90db873c35dff2c Author: Frank Rowand Date: Thu Apr 16 16:42:47 2020 -0500 of: unittest: kmemleak in of_unittest_platform_populate() commit 216830d2413cc61be3f76bc02ffd905e47d2439e upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 2 of 5. of_unittest_platform_populate() left an elevated reference count for grandchild nodes (which are platform devices). Fix the platform device reference counts so that the memory will be freed. Fixes: fb2caa50fbac ("of/selftest: add testcase for nodes with same name and address") Reported-by: Erhard F. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit dd3dd28241e02a88553e6676a18736e2cdfbaa4f Author: Frank Rowand Date: Thu Apr 16 16:42:46 2020 -0500 of: unittest: kmemleak on changeset destroy commit b3fb36ed694b05738d45218ea72cf7feb10ce2b1 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 1 of 5. of_unittest_changeset() reaches deeply into the dynamic devicetree functions. Several nodes were left with an elevated reference count and thus were not properly cleaned up. Fix the reference counts so that the memory will be freed. Fixes: 201c910bd689 ("of: Transactional DT support.") Reported-by: Erhard F. Signed-off-by: Frank Rowand Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 25c9cdef57488578da21d99eb614b97ffcf6e59f Author: Magnus Karlsson Date: Tue Apr 14 09:35:15 2020 +0200 xsk: Add missing check on user supplied headroom size commit 99e3a236dd43d06c65af0a2ef9cb44306aef6e02 upstream. Add a check that the headroom cannot be larger than the available space in the chunk. In the current code, a malicious user can set the headroom to a value larger than the chunk size minus the fixed XDP headroom. That way packets with a length larger than the supported size in the umem could get accepted and result in an out-of-bounds write. Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt") Reported-by: Bui Quang Minh Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann Link: https://bugzilla.kernel.org/show_bug.cgi?id=207225 Link: https://lore.kernel.org/bpf/1586849715-23490-1-git-send-email-magnus.karlsson@intel.com Signed-off-by: Greg Kroah-Hartman commit 9244c79da15c8a0791980c73018eea631ed8c47a Author: Takashi Iwai Date: Mon Apr 13 10:20:29 2020 +0200 ALSA: hda: Don't release card at firmware loading error commit 25faa4bd37c10f19e4b848b9032a17a3d44c6f09 upstream. At the error path of the firmware loading error, the driver tries to release the card object and set NULL to drvdata. This may be referred badly at the possible PM action, as the driver itself is still bound and the PM callbacks read the card object. Instead, we continue the probing as if it were no option set. This is often a better choice than the forced abort, too. Fixes: 5cb543dba986 ("ALSA: hda - Deferred probing with request_firmware_nowait()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 182fa4d72a7c128a4b02b6a702eb75f8862d5382 Author: Zenghui Yu Date: Wed Apr 8 19:43:52 2020 +0800 irqchip/mbigen: Free msi_desc on device teardown commit edfc23f6f9fdbd7825d50ac1f380243cde19b679 upstream. Using irq_domain_free_irqs_common() on the irqdomain free path will leave the MSI descriptor unfreed when platform devices get removed. Properly free it by MSI domain free function. Fixes: 9650c60ebfec0 ("irqchip/mbigen: Create irq domain for each mbigen device") Signed-off-by: Zenghui Yu Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200408114352.1604-1-yuzenghui@huawei.com Signed-off-by: Greg Kroah-Hartman commit daefa51c43533447c1c6a7dbafd48c0387fe19c6 Author: Pablo Neira Ayuso Date: Tue Apr 7 14:10:11 2020 +0200 netfilter: nf_tables: report EOPNOTSUPP on unsupported flags/object type commit d9583cdf2f38d0f526d9a8c8564dd2e35e649bc7 upstream. EINVAL should be used for malformed netlink messages. New userspace utility and old kernels might easily result in EINVAL when exercising new set features, which is misleading. Fixes: 8aeff920dcc9 ("netfilter: nf_tables: add stateful object reference to set elements") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit aea3873fb02cb5363a7dcb942d2e6e2bd005934b Author: Slava Bacherikov Date: Thu Apr 2 23:41:39 2020 +0300 kbuild, btf: Fix dependencies for DEBUG_INFO_BTF commit 7d32e69310d67e6b04af04f26193f79dfc2f05c7 upstream. Currently turning on DEBUG_INFO_SPLIT when DEBUG_INFO_BTF is also enabled will produce invalid btf file, since gen_btf function in link-vmlinux.sh script doesn't handle *.dwo files. Enabling DEBUG_INFO_REDUCED will also produce invalid btf file, and using GCC_PLUGIN_RANDSTRUCT with BTF makes no sense. Fixes: e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux") Reported-by: Jann Horn Reported-by: Liu Yiding Signed-off-by: Slava Bacherikov Signed-off-by: Daniel Borkmann Reviewed-by: Kees Cook Acked-by: KP Singh Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200402204138.408021-1-slava@bacher09.org Signed-off-by: Greg Kroah-Hartman commit e1e5c219f033aceb23705fea94308bff90cdea01 Author: Martin Fuzzey Date: Thu Apr 2 15:51:28 2020 +0200 ARM: dts: imx6: Use gpc for FEC interrupt controller to fix wake on LAN. commit 4141f1a40fc0789f6fd4330e171e1edf155426aa upstream. In order to wake from suspend by ethernet magic packets the GPC must be used as intc does not have wakeup functionality. But the FEC DT node currently uses interrupt-extended, specificying intc, thus breaking WoL. This problem is probably fallout from the stacked domain conversion as intc used to chain to GPC. So replace "interrupts-extended" by "interrupts" to use the default parent which is GPC. Fixes: b923ff6af0d5 ("ARM: imx6: convert GPC to stacked domains") Signed-off-by: Martin Fuzzey Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ed0a5355aa624521d34fc6868f0bb283473baf82 Author: Takashi Iwai Date: Mon Apr 13 10:20:30 2020 +0200 ALSA: hda: Honor PM disablement in PM freeze and thaw_noirq ops commit 10db5bccc390e8e4bd9fcd1fbd4f1b23f271a405 upstream. freeze_noirq and thaw_noirq need to check the PM availability like other PM ops. There are cases where the device got disabled due to the error, and the PM operation should be ignored for that. Fixes: 3e6db33aaf1d ("ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d8b667b45d72ad5c1f53db118fcbc6f76cf71da6 Author: Li Bin Date: Mon Apr 13 19:29:21 2020 +0800 scsi: sg: add sg_remove_request in sg_common_write commit 849f8583e955dbe3a1806e03ecacd5e71cce0a08 upstream. If the dxfer_len is greater than 256M then the request is invalid and we need to call sg_remove_request in sg_common_write. Link: https://lore.kernel.org/r/1586777361-17339-1-git-send-email-huawei.libin@huawei.com Fixes: f930c7043663 ("scsi: sg: only check for dxfer_len greater than 256M") Acked-by: Douglas Gilbert Signed-off-by: Li Bin Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d979eda8a72ba4126562fab9e8e0c7d5b998a03e Author: Josh Poimboeuf Date: Wed Apr 1 13:23:28 2020 -0500 objtool: Fix switch table detection in .text.unlikely commit b401efc120a399dfda1f4d2858a4de365c9b08ef upstream. If a switch jump table's indirect branch is in a ".cold" subfunction in .text.unlikely, objtool doesn't detect it, and instead prints a false warning: drivers/media/v4l2-core/v4l2-ioctl.o: warning: objtool: v4l_print_format.cold()+0xd6: sibling call from callable instruction with modified stack frame drivers/hwmon/max6650.o: warning: objtool: max6650_probe.cold()+0xa5: sibling call from callable instruction with modified stack frame drivers/media/dvb-frontends/drxk_hard.o: warning: objtool: init_drxk.cold()+0x16f: sibling call from callable instruction with modified stack frame Fix it by comparing the function, instead of the section and offset. Fixes: 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions") Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Reviewed-by: Miroslav Benes Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/157c35d42ca9b6354bbb1604fe9ad7d1153ccb21.1585761021.git.jpoimboe@redhat.com Signed-off-by: Greg Kroah-Hartman commit 2613535abd3b80d6acea8902c94fafe3897e4f58 Author: Luke Nelson Date: Thu Apr 9 15:17:52 2020 -0700 arm, bpf: Fix offset overflow for BPF_MEM BPF_DW commit 4178417cc5359c329790a4a8f4a6604612338cca upstream. This patch fixes an incorrect check in how immediate memory offsets are computed for BPF_DW on arm. For BPF_LDX/ST/STX + BPF_DW, the 32-bit arm JIT breaks down an 8-byte access into two separate 4-byte accesses using off+0 and off+4. If off fits in imm12, the JIT emits a ldr/str instruction with the immediate and avoids the use of a temporary register. While the current check off <= 0xfff ensures that the first immediate off+0 doesn't overflow imm12, it's not sufficient for the second immediate off+4, which may cause the second access of BPF_DW to read/write the wrong address. This patch fixes the problem by changing the check to off <= 0xfff - 4 for BPF_DW, ensuring off+4 will never overflow. A side effect of simplifying the check is that it now allows using negative immediate offsets in ldr/str. This means that small negative offsets can also avoid the use of a temporary register. This patch introduces no new failures in test_verifier or test_bpf.c. Fixes: c5eae692571d6 ("ARM: net: bpf: improve 64-bit store implementation") Fixes: ec19e02b343db ("ARM: net: bpf: fix LDX instructions") Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200409221752.28448-1-luke.r.nels@gmail.com Signed-off-by: Greg Kroah-Hartman commit d4adee8e8f2f7c4ba84d3ae2c7efc66ca57535b0 Author: Luke Nelson Date: Wed Apr 8 18:12:29 2020 +0000 arm, bpf: Fix bugs with ALU64 {RSH, ARSH} BPF_K shift by 0 commit bb9562cf5c67813034c96afb50bd21130a504441 upstream. The current arm BPF JIT does not correctly compile RSH or ARSH when the immediate shift amount is 0. This causes the "rsh64 by 0 imm" and "arsh64 by 0 imm" BPF selftests to hang the kernel by reaching an instruction the verifier determines to be unreachable. The root cause is in how immediate right shifts are encoded on arm. For LSR and ASR (logical and arithmetic right shift), a bit-pattern of 00000 in the immediate encodes a shift amount of 32. When the BPF immediate is 0, the generated code shifts by 32 instead of the expected behavior (a no-op). This patch fixes the bugs by adding an additional check if the BPF immediate is 0. After the change, the above mentioned BPF selftests pass. Fixes: 39c13c204bb11 ("arm: eBPF JIT compiler") Co-developed-by: Xi Wang Signed-off-by: Xi Wang Signed-off-by: Luke Nelson Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200408181229.10909-1-luke.r.nels@gmail.com Signed-off-by: Greg Kroah-Hartman commit e7f6c25bafa68c3a6f085d00851503a3f3897e74 Author: Li RongQing Date: Thu Apr 2 15:52:10 2020 +0800 xsk: Fix out of boundary write in __xsk_rcv_memcpy commit db5c97f02373917efe2c218ebf8e3d8b19e343b6 upstream. first_len is the remainder of the first page we're copying. If this size is larger, then out of page boundary write will otherwise happen. Fixes: c05cd3645814 ("xsk: add support to allow unaligned chunk placement") Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/1585813930-19712-1-git-send-email-lirongqing@baidu.com Signed-off-by: Greg Kroah-Hartman commit 9a9eae78529cfd9152af417acbf09a32019605c5 Author: Michael Walle Date: Fri Mar 27 17:24:50 2020 +0100 watchdog: sp805: fix restart handler commit ea104a9e4d3e9ebc26fb78dac35585b142ee288b upstream. The restart handler is missing two things, first, the registers has to be unlocked and second there is no synchronization for the write_relaxed() calls. This was tested on a custom board with the NXP LS1028A SoC. Fixes: 6c5c0d48b686c ("watchdog: sp805: add restart handler") Signed-off-by: Michael Walle Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20200327162450.28506-1-michael@walle.cc Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 41d097c83343326c5c72c9801a5222b2a575a27a Author: Roman Gushchin Date: Fri Feb 28 16:14:11 2020 -0800 ext4: use non-movable memory for superblock readahead commit d87f639258a6a5980183f11876c884931ad93da2 upstream. Since commit a8ac900b8163 ("ext4: use non-movable memory for the superblock") buffers for ext4 superblock were allocated using the sb_bread_unmovable() helper which allocated buffer heads out of non-movable memory blocks. It was necessarily to not block page migrations and do not cause cma allocation failures. However commit 85c8f176a611 ("ext4: preload block group descriptors") broke this by introducing pre-reading of the ext4 superblock. The problem is that __breadahead() is using __getblk() underneath, which allocates buffer heads out of movable memory. It resulted in page migration failures I've seen on a machine with an ext4 partition and a preallocated cma area. Fix this by introducing sb_breadahead_unmovable() and __breadahead_gfp() helpers which use non-movable memory for buffer head allocations and use them for the ext4 superblock readahead. Reviewed-by: Andreas Dilger Fixes: 85c8f176a611 ("ext4: preload block group descriptors") Signed-off-by: Roman Gushchin Link: https://lore.kernel.org/r/20200229001411.128010-1-guro@fb.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman