commit a39e75458e1ceb7fefaa3a0bd9df21558713cf0d Author: Greg Kroah-Hartman Date: Thu Jun 25 15:33:11 2020 +0200 Linux 4.19.130 commit be0bcec4a5ba3fe931262ef0a3a7f119d9745958 Author: Sean Christopherson Date: Wed May 27 01:49:09 2020 -0700 KVM: x86/mmu: Set mmio_value to '0' if reserved #PF can't be generated [ Upstream commit 6129ed877d409037b79866327102c9dc59a302fe ] Set the mmio_value to '0' instead of simply clearing the present bit to squash a benign warning in kvm_mmu_set_mmio_spte_mask() that complains about the mmio_value overlapping the lower GFN mask on systems with 52 bits of PA space. Opportunistically clean up the code and comments. Cc: stable@vger.kernel.org Fixes: d43e2675e96fc ("KVM: x86: only do L1TF workaround on affected processors") Signed-off-by: Sean Christopherson Message-Id: <20200527084909.23492-1-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 940ed58a08dde24575d9c727b6e69c101c1b4711 Author: Kai Huang Date: Fri May 3 03:08:53 2019 -0700 kvm: x86: Fix reserved bits related calculation errors caused by MKTME [ Upstream commit f3ecb59dd49f1742b97df6ba071aaa3d031154ac ] Intel MKTME repurposes several high bits of physical address as 'keyID' for memory encryption thus effectively reduces platform's maximum physical address bits. Exactly how many bits are reduced is configured by BIOS. To honor such HW behavior, the repurposed bits are reduced from cpuinfo_x86->x86_phys_bits when MKTME is detected in CPU detection. Similarly, AMD SME/SEV also reduces physical address bits for memory encryption, and cpuinfo->x86_phys_bits is reduced too when SME/SEV is detected, so for both MKTME and SME/SEV, boot_cpu_data.x86_phys_bits doesn't hold physical address bits reported by CPUID anymore. Currently KVM treats bits from boot_cpu_data.x86_phys_bits to 51 as reserved bits, but it's not true anymore for MKTME, since MKTME treats those reduced bits as 'keyID', but not reserved bits. Therefore boot_cpu_data.x86_phys_bits cannot be used to calculate reserved bits anymore, although we can still use it for AMD SME/SEV since SME/SEV treats the reduced bits differently -- they are treated as reserved bits, the same as other reserved bits in page table entity [1]. Fix by introducing a new 'shadow_phys_bits' variable in KVM x86 MMU code to store the effective physical bits w/o reserved bits -- for MKTME, it equals to physical address reported by CPUID, and for SME/SEV, it is boot_cpu_data.x86_phys_bits. Note that for the physical address bits reported to guest should remain unchanged -- KVM should report physical address reported by CPUID to guest, but not boot_cpu_data.x86_phys_bits. Because for Intel MKTME, there's no harm if guest sets up 'keyID' bits in guest page table (since MKTME only works at physical address level), and KVM doesn't even expose MKTME to guest. Arguably, for AMD SME/SEV, guest is aware of SEV thus it should adjust boot_cpu_data.x86_phys_bits when it detects SEV, therefore KVM should still reports physcial address reported by CPUID to guest. Reviewed-by: Sean Christopherson Signed-off-by: Kai Huang Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit fc095d7e8c23d3cbab9597a68cf7e5ab58b089d1 Author: Kai Huang Date: Fri May 3 03:08:52 2019 -0700 kvm: x86: Move kvm_set_mmio_spte_mask() from x86.c to mmu.c [ Upstream commit 7b6f8a06e482960ba6ab06faba51c8f3727a5c7b ] As a prerequisite to fix several SPTE reserved bits related calculation errors caused by MKTME, which requires kvm_set_mmio_spte_mask() to use local static variable defined in mmu.c. Also move call site of kvm_set_mmio_spte_mask() from kvm_arch_init() to kvm_mmu_module_init() so that kvm_set_mmio_spte_mask() can be static. Reviewed-by: Sean Christopherson Signed-off-by: Kai Huang Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f04928c3c2627deb43acd6724991d4573a4be7c8 Author: NeilBrown Date: Mon Sep 9 16:52:29 2019 +1000 md: add feature flag MD_FEATURE_RAID0_LAYOUT [ Upstream commit 33f2c35a54dfd75ad0e7e86918dcbe4de799a56c ] Due to a bug introduced in Linux 3.14 we cannot determine the correctly layout for a multi-zone RAID0 array - there are two possibilities. It is possible to tell the kernel which to chose using a module parameter, but this can be clumsy to use. It would be best if the choice were recorded in the metadata. So add a feature flag for this purpose. If it is set, then the 'layout' field of the superblock is used to determine which layout to use. If this flag is not set, then mddev->layout gets set to -1, which causes the module parameter to be required. Acked-by: Guoqing Jiang Signed-off-by: NeilBrown Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 6d6a0392ee570aa89308104cf0d1887611350c05 Author: Vladimir Oltean Date: Mon Jun 22 13:40:41 2020 +0300 Revert "dpaa_eth: fix usage as DSA master, try 3" This reverts commit b145710b69388aa4034d32b4a937f18f66b5538e which is commit 5d14c304bfc14b4fd052dc83d5224376b48f52f0 upstream. The patch is not wrong, but the Fixes: tag is. It should have been: Fixes: 060ad66f9795 ("dpaa_eth: change DMA device") which means that it's fixing a commit which was introduced in: git describe --tags 060ad66f97954 v5.4-rc3-783-g060ad66f9795 which then means it should have not been backported to linux-4.19.y, where things _were_ working and now they're not. Reported-by: Joakim Tjernlund Signed-off-by: Vladimir Oltean Signed-off-by: Greg Kroah-Hartman commit 29d1d0c7246462f2138ede9d5e5a1a7606366c17 Author: Ahmed S. Darwish Date: Wed Jun 3 16:49:44 2020 +0200 net: core: device_rename: Use rwsem instead of a seqcount [ Upstream commit 11d6011c2cf29f7c8181ebde6c8bc0c4d83adcd7 ] Sequence counters write paths are critical sections that must never be preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed. Commit 5dbe7c178d3f ("net: fix kernel deadlock with interface rename and netdev name retrieval.") handled a deadlock, observed with CONFIG_PREEMPTION=n, where the devnet_rename seqcount read side was infinitely spinning: it got scheduled after the seqcount write side blocked inside its own critical section. To fix that deadlock, among other issues, the commit added a cond_resched() inside the read side section. While this will get the non-preemptible kernel eventually unstuck, the seqcount reader is fully exhausting its slice just spinning -- until TIF_NEED_RESCHED is set. The fix is also still broken: if the seqcount reader belongs to a real-time scheduling policy, it can spin forever and the kernel will livelock. Disabling preemption over the seqcount write side critical section will not work: inside it are a number of GFP_KERNEL allocations and mutex locking through the drivers/base/ :: device_rename() call chain. >From all the above, replace the seqcount with a rwsem. Fixes: 5dbe7c178d3f (net: fix kernel deadlock with interface rename and netdev name retrieval.) Fixes: 30e6c9fa93cf (net: devnet_rename_seq should be a seqcount) Fixes: c91f6df2db49 (sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name) Cc: Reported-by: kbuild test robot [ v1 missing up_read() on error exit ] Reported-by: Dan Carpenter [ v1 missing up_read() on error exit ] Signed-off-by: Ahmed S. Darwish Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b855db2a128ae5d003e03e1b7e7faf8d88b02134 Author: Thomas Gleixner Date: Tue Oct 15 21:18:08 2019 +0200 sched/rt, net: Use CONFIG_PREEMPTION.patch [ Upstream commit 2da2b32fd9346009e9acdb68c570ca8d3966aba7 ] CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same functionality which today depends on CONFIG_PREEMPT. Update the comment to use CONFIG_PREEMPTION. Signed-off-by: Thomas Gleixner Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Acked-by: David S. Miller Cc: Linus Torvalds Cc: Peter Zijlstra Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20191015191821.11479-22-bigeasy@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 98abe944f93faf19c3707f8f188df5073e5668f8 Author: Jiri Olsa Date: Tue May 12 17:03:18 2020 +0900 kretprobe: Prevent triggering kretprobe from within kprobe_flush_task [ Upstream commit 9b38cc704e844e41d9cf74e647bff1d249512cb3 ] Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave. My test was also able to trigger lockdep output: ============================================ WARNING: possible recursive locking detected 5.6.0-rc6+ #6 Not tainted -------------------------------------------- sched-messaging/2767 is trying to acquire lock: ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0 but task is already holding lock: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(kretprobe_table_locks[i].lock)); lock(&(kretprobe_table_locks[i].lock)); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by sched-messaging/2767: #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 stack backtrace: CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6 Call Trace: dump_stack+0x96/0xe0 __lock_acquire.cold.57+0x173/0x2b7 ? native_queued_spin_lock_slowpath+0x42b/0x9e0 ? lockdep_hardirqs_on+0x590/0x590 ? __lock_acquire+0xf63/0x4030 lock_acquire+0x15a/0x3d0 ? kretprobe_hash_lock+0x52/0xa0 _raw_spin_lock_irqsave+0x36/0x70 ? kretprobe_hash_lock+0x52/0xa0 kretprobe_hash_lock+0x52/0xa0 trampoline_handler+0xf8/0x940 ? kprobe_fault_handler+0x380/0x380 ? find_held_lock+0x3a/0x1c0 kretprobe_trampoline+0x25/0x50 ? lock_acquired+0x392/0xbc0 ? _raw_spin_lock_irqsave+0x50/0x70 ? __get_valid_kprobe+0x1f0/0x1f0 ? _raw_spin_unlock_irqrestore+0x3b/0x40 ? finish_task_switch+0x4b9/0x6d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 The code within the kretprobe handler checks for probe reentrancy, so we won't trigger any _raw_spin_lock_irqsave probe in there. The problem is in outside kprobe_flush_task, where we call: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave where _raw_spin_lock_irqsave triggers the kretprobe and installs kretprobe_trampoline handler on _raw_spin_lock_irqsave return. The kretprobe_trampoline handler is then executed with already locked kretprobe_table_locks, and first thing it does is to lock kretprobe_table_locks ;-) the whole lockup path like: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed ---> kretprobe_table_locks locked kretprobe_trampoline trampoline_handler kretprobe_hash_lock(current, &head, &flags); <--- deadlock Adding kprobe_busy_begin/end helpers that mark code with fake probe installed to prevent triggering of another kprobe within this code. Using these helpers in kprobe_flush_task, so the probe recursion protection check is hit and the probe is never set to prevent above lockup. Link: http://lkml.kernel.org/r/158927059835.27680.7011202830041561604.stgit@devnote2 Fixes: ef53d9c5e4da ("kprobes: improve kretprobe scalability with hashed locking") Cc: Ingo Molnar Cc: "Gustavo A . R . Silva" Cc: Anders Roxell Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Ingo Molnar Cc: Peter Zijlstra Cc: stable@vger.kernel.org Reported-by: "Ziqian SUN (Zamir)" Acked-by: Masami Hiramatsu Signed-off-by: Jiri Olsa Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 10699fb989e6a4c0f8bdd4dc642d1e52a408ecf3 Author: Alexander Sverdlin Date: Fri May 29 14:17:10 2020 +0200 net: octeon: mgmt: Repair filling of RX ring commit 0c34bb598c510e070160029f34efeeb217000f8d upstream. The removal of mips_swiotlb_ops exposed a problem in octeon_mgmt Ethernet driver. mips_swiotlb_ops had an mb() after most of the operations and the removal of the ops had broken the receive functionality of the driver. My code inspection has shown no other places except octeon_mgmt_rx_fill_ring() where an explicit barrier would be obviously missing. The latter function however has to make sure that "ringing the bell" doesn't happen before RX ring entry is really written. The patch has been successfully tested on Octeon II. Fixes: a999933db9ed ("MIPS: remove mips_swiotlb_ops") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f31b2cab6ca50cb57e3bf8117c26a19846f32968 Author: Chen Yu Date: Fri May 22 01:59:00 2020 +0800 e1000e: Do not wake up the system via WOL if device wakeup is disabled commit 6bf6be1127f7e6d4bf39f84d56854e944d045d74 upstream. Currently the system will be woken up via WOL(Wake On LAN) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver") Reported-by: "Rafael J. Wysocki" Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Chen Yu Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 3489535570e286067af40b6df6a85119797a53c8 Author: Masami Hiramatsu Date: Tue May 12 17:02:56 2020 +0900 kprobes: Fix to protect kick_kprobe_optimizer() by kprobe_mutex commit 1a0aa991a6274161c95a844c58cfb801d681eb59 upstream. In kprobe_optimizer() kick_kprobe_optimizer() is called without kprobe_mutex, but this can race with other caller which is protected by kprobe_mutex. To fix that, expand kprobe_mutex protected area to protect kick_kprobe_optimizer() call. Link: http://lkml.kernel.org/r/158927057586.27680.5036330063955940456.stgit@devnote2 Fixes: cd7ebe2298ff ("kprobes: Use text_poke_smp_batch for optimizing") Cc: Ingo Molnar Cc: "Gustavo A . R . Silva" Cc: Anders Roxell Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Ziqian SUN Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit c0ef44cbed8af7bafd29225be441e94d488405c5 Author: Eric Biggers Date: Thu Jun 4 11:52:53 2020 -0700 crypto: algboss - don't wait during notifier callback commit 77251e41f89a813b4090f5199442f217bbf11297 upstream. When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST is sent to crypto_chain. cryptomgr_schedule_probe() handles this by starting a thread to instantiate the template, then waiting for this thread to complete via crypto_larval::completion. This can deadlock because instantiating the template may require loading modules, and this (apparently depending on userspace) may need to wait for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But crc-t10dif's module_init function uses crypto_register_notifier() and therefore takes crypto_chain.rwsem for write. That can't proceed until the notifier callback has finished, as it holds this semaphore for read. Fix this by removing the wait on crypto_larval::completion from within cryptomgr_schedule_probe(). It's actually unnecessary because crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending CRYPTO_MSG_ALG_REQUEST. This only actually became a problem in v4.20 due to commit b76377543b73 ("crc-t10dif: Pick better transform if one becomes available"), but the unnecessary wait was much older. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159 Reported-by: Mike Gerow Fixes: 398710379f51 ("crypto: algapi - Move larval completion into algboss") Cc: # v3.6+ Cc: Martin K. Petersen Signed-off-by: Eric Biggers Reported-by: Kai Lüke Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b3ad0cdbdca3c8593bc8bb8f51bb0177597cbf6c Author: Herbert Xu Date: Fri May 29 14:54:43 2020 +1000 crypto: algif_skcipher - Cap recv SG list at ctx->used commit 7cf81954705b7e5b057f7dc39a7ded54422ab6e1 upstream. Somewhere along the line the cap on the SG list length for receive was lost. This patch restores it and removes the subsequent test which is now redundant. Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of...") Cc: Signed-off-by: Herbert Xu Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d9d3352c20a0b9bbc224632418a075013ed1f702 Author: Imre Deak Date: Fri Jun 12 15:17:31 2020 +0300 drm/i915/icl+: Fix hotplug interrupt disabling after storm detection commit a3005c2edf7e8c3478880db1ca84028a2b6819bb upstream. Atm, hotplug interrupts on TypeC ports are left enabled after detecting an interrupt storm, fix this. Reported-by: Kunal Joshi References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 Cc: Kunal Joshi Cc: stable@vger.kernel.org Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200612121731.19596-1-imre.deak@intel.com (cherry picked from commit 587a87b9d7e94927edcdea018565bc1939381eb1) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 4f520660d5f91b137f59a29a9b0077cf3433ffd3 Author: Chris Wilson Date: Mon Jun 1 17:19:42 2020 +0100 drm/i915: Whitelist context-local timestamp in the gen9 cmdparser commit 273500ae71711c040d258a7b3f4b6f44c368fff2 upstream. Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: # v5.4+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk (cherry picked from commit f9496520df11de00fbafc3cbd693b9570d600ab3) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 1d3c79f49222c1fd26dec0dc3d71ebd2509ef3dd Author: Dmitry V. Levin Date: Tue Jun 2 21:00:51 2020 +0300 s390: fix syscall_get_error for compat processes commit b3583fca5fb654af2cfc1c08259abb9728272538 upstream. If both the tracer and the tracee are compat processes, and gprs[2] is assigned a value by __poke_user_compat, then the higher 32 bits of gprs[2] are cleared, IS_ERR_VALUE() always returns false, and syscall_get_error() always returns 0. Fix the implementation by sign-extending the value for compat processes the same way as x86 implementation does. The bug was exposed to user space by commit 201766a20e30f ("ptrace: add PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite. This change fixes strace syscall tampering on s390. Link: https://lkml.kernel.org/r/20200602180051.GA2427@altlinux.org Fixes: 753c4dd6a2fa2 ("[S390] ptrace changes") Cc: Elvira Khabirova Cc: stable@vger.kernel.org # v2.6.28+ Signed-off-by: Dmitry V. Levin Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit a686c2b412a63bb3e4e150544e37f2b4311d6123 Author: Miquel Raynal Date: Tue May 19 15:00:29 2020 +0200 mtd: rawnand: tmio: Fix the probe error path [ Upstream commit 75e9a330a9bd48f97a55a08000236084fe3dae56 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-57-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit f0524138740e1b7ef3408ec70d98adcb8da6abb9 Author: Miquel Raynal Date: Tue May 19 15:00:00 2020 +0200 mtd: rawnand: mtk: Fix the probe error path [ Upstream commit 8a82bbcadec877f5f938c54026278dfc1f05a332 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-28-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 5bf01fce23eafad5dd56dad58fa908ee382f13d9 Author: Miquel Raynal Date: Tue May 19 15:00:15 2020 +0200 mtd: rawnand: plat_nand: Fix the probe error path [ Upstream commit 5284024b4dac5e94f7f374ca905c7580dbc455e9 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible, hence pointing it as the commit to fix for backporting purposes, even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-43-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 4603f4112d9c9fce28f6bac3f73149bacbf023f3 Author: Miquel Raynal Date: Tue May 19 15:00:23 2020 +0200 mtd: rawnand: socrates: Fix the probe error path [ Upstream commit 9c6c2e5cc77119ce0dacb4f9feedb73ce0354421 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-51-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 45ed31bed499a8a8be4b6c48f0dbc489081e5ac3 Author: Miquel Raynal Date: Tue May 19 15:00:09 2020 +0200 mtd: rawnand: oxnas: Fix the probe error path [ Upstream commit 154298e2a3f6c9ce1d76cdb48d89fd5b107ea1a3 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. While at it, be consistent and move the function call in the error path thanks to a goto statement. Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-37-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 09fc51a9fa5264d496ef51c66d33cd8bc305d302 Author: Nishka Dasgupta Date: Tue Jul 9 22:40:16 2019 +0530 mtd: rawnand: oxnas: Add of_node_put() [ Upstream commit c436f68beeb20f2f92937677db1d9069b0dd2a3d ] Each iteration of for_each_child_of_node puts the previous node, but in the case of a goto from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put under a new goto to put the node at a loop exit. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 3431ad8cd07f8e336e99a17e3882e041674209b8 Author: Miquel Raynal Date: Tue May 19 15:00:06 2020 +0200 mtd: rawnand: orion: Fix the probe error path [ Upstream commit be238fbf78e4c7c586dac235ab967d3e565a4d1a ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-34-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 26a143895e1b127b0c98d6d47ccf541976da2cb4 Author: Miquel Raynal Date: Tue May 19 15:00:33 2020 +0200 mtd: rawnand: xway: Fix the probe error path [ Upstream commit 34531be5e804a8e1abf314a6c3a19fe342e4a154 ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no real Fixes tag applying here as the use of nand_release() in this driver predates the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if this commit is not introducing any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-61-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 9b9e207bec0e0936097d4ce2a88c3aa586b9640a Author: Miquel Raynal Date: Tue May 19 15:00:21 2020 +0200 mtd: rawnand: sharpsl: Fix the probe error path [ Upstream commit 0f44b3275b3798ccb97a2f51ac85871c30d6fbbc ] nand_release() is supposed be called after MTD device registration. Here, only nand_scan() happened, so use nand_cleanup() instead. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-49-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit f92c582dd871a565d816988a76b80cc140680feb Author: Miquel Raynal Date: Tue May 19 14:59:45 2020 +0200 mtd: rawnand: diskonchip: Fix the probe error path [ Upstream commit c5be12e45940f1aa1b5dfa04db5d15ad24f7c896 ] Not sure nand_cleanup() is the right function to call here but in any case it is not nand_release(). Indeed, even a comment says that calling nand_release() is a bit of a hack as there is no MTD device to unregister. So switch to nand_cleanup() for now and drop this comment. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if it did not intruce any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-13-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit eef1783440271af718380ad4dfc23ba5357874cc Author: Boris Brezillon Date: Thu Sep 6 14:05:15 2018 +0200 mtd: rawnand: Pass a nand_chip object to nand_release() [ Upstream commit 59ac276f22270fb2094910f9a734c17f41c25e70 ] Let's make the raw NAND API consistent by patching all helpers to take a nand_chip object instead of an mtd_info one. Now is nand_release()'s turn. Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 4c9539a319254b8d863ed7d0f8764953f144da60 Author: Boris Brezillon Date: Thu Sep 6 14:05:14 2018 +0200 mtd: rawnand: Pass a nand_chip object to nand_scan() [ Upstream commit 00ad378f304a091ab2e2df5f944892a6ed558610 ] Let's make the raw NAND API consistent by patching all helpers to take a nand_chip object instead of an mtd_info one. We start with nand_scan(). Signed-off-by: Boris Brezillon Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit e1906ca16db5d2b28dffd5785f058d22dbea1ab4 Author: Ahmed S. Darwish Date: Wed Jun 3 16:49:48 2020 +0200 block: nr_sects_write(): Disable preemption on seqcount write [ Upstream commit 15b81ce5abdc4b502aa31dff2d415b79d2349d2f ] For optimized block readers not holding a mutex, the "number of sectors" 64-bit value is protected from tearing on 32-bit architectures by a sequence counter. Disable preemption before entering that sequence counter's write side critical section. Otherwise, the read side can preempt the write side section and spin for the entire scheduler tick. If the reader belongs to a real-time scheduling class, it can spin forever and the kernel will livelock. Fixes: c83f6bf98dc1 ("block: add partition resize function to blkpg ioctl") Cc: Signed-off-by: Ahmed S. Darwish Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4cc4e2dbf958a0bb7a0f3b05c79fc4232d3c2398 Author: Ard Biesheuvel Date: Mon Jun 22 19:56:39 2020 +0000 x86/boot/compressed: Relax sed symbol type regex for LLVM ld.lld commit bc310baf2ba381c648983c7f4748327f17324562 upstream. The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h The symbol type is indicated by a single letter, which we match strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored. Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases. However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be undefined in a subtraction expression init_size: .long (0x00000000008fd000 - ZO_startup_32 + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Tested-by: Nathan Chancellor Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit e0a59a6e860f2a6edc465058fd9fb772efcbd9a6 Author: Lyude Paul Date: Fri Apr 3 15:47:15 2020 -0400 drm/dp_mst: Increase ACT retry timeout to 3s [ Upstream commit 873a95e0d59ac06901ae261dda0b7165ffd002b8 ] Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by: Lyude Paul Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul Cc: # v3.17+ Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.com Signed-off-by: Sasha Levin commit 5dbb625573abf67b9f7d6992c8e3f57acaef5946 Author: Theodore Ts'o Date: Wed Jun 10 11:16:37 2020 -0400 ext4: avoid race conditions when remounting with options that change dax [ Upstream commit 829b37b8cddb1db75c1b7905505b90e593b15db1 ] Trying to change dax mount options when remounting could allow mount options to be enabled for a small amount of time, and then the mount option change would be reverted. In the case of "mount -o remount,dax", this can cause a race where files would temporarily treated as DAX --- and then not. Cc: stable@kernel.org Reported-by: syzbot+bca9799bf129256190da@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 051bf267b1fabba8a585a185eb816bf0006bdae6 Author: Sasha Levin Date: Mon Jun 22 18:02:35 2020 -0400 ext4: fix partial cluster initialization when splitting extent [ Upstream commit cfb3c85a600c6aa25a2581b3c1c4db3460f14e46 ] Fix the bug when calculating the physical block number of the first block in the split extent. This bug will cause xfstests shared/298 failure on ext4 with bigalloc enabled occasionally. Ext4 error messages indicate that previously freed blocks are being freed again, and the following fsck will fail due to the inconsistency of block bitmap and bg descriptor. The following is an example case: 1. First, Initialize a ext4 filesystem with cluster size '16K', block size '4K', in which case, one cluster contains four blocks. 2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent tree of this file is like: ... 36864:[0]4:220160 36868:[0]14332:145408 51200:[0]2:231424 ... 3. Then execute PUNCH_HOLE fallocate on this file. The hole range is like: .. ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 ... 4. Then the extent tree of this file after punching is like ... 49507:[0]37:158047 49547:[0]58:158087 ... 5. Detailed procedure of punching hole [49544, 49546] 5.1. The block address space: ``` lblk ~49505 49506 49507~49543 49544~49546 49547~ ---------+------+-------------+----------------+-------- extent | hole | extent | hole | extent ---------+------+-------------+----------------+-------- pblk ~158045 158046 158047~158083 158084~158086 158087~ ``` 5.2. The detailed layout of cluster 39521: ``` cluster 39521 <-------------------------------> hole extent <----------------------><-------- lblk 49544 49545 49546 49547 +-------+-------+-------+-------+ | | | | | +-------+-------+-------+-------+ pblk 158084 1580845 158086 158087 ``` 5.3. The ftrace output when punching hole [49544, 49546]: - ext4_ext_remove_space (start 49544, end 49546) - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] - ext4_free_blocks: (block 158084 count 4) - ext4_mballoc_free (extent 1/6753/1) 5.4. Ext4 error message in dmesg: EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters In this case, the whole cluster 39521 is freed mistakenly when freeing pblock 158084~158086 (i.e., the first three blocks of this cluster), although pblock 158087 (the last remaining block of this cluster) has not been freed yet. The root cause of this isuue is that, the pclu of the partial cluster is calculated mistakenly in ext4_ext_remove_space(). The correct partial_cluster.pclu (i.e., the cluster number of the first block in the next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather than 39522. Fixes: f4226d9ea400 ("ext4: fix partial cluster initialization") Signed-off-by: Jeffle Xu Reviewed-by: Eric Whitney Cc: stable@kernel.org # v3.19+ Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit cd80735a43a9c8fd5e883f8313e3ba7b27167310 Author: Tom Rix Date: Wed Jun 10 14:57:13 2020 -0700 selinux: fix double free commit 65de50969a77509452ae590e9449b70a22b923bb upstream. Clang's static analysis tool reports these double free memory errors. security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc] kfree(bnames[i]); ^~~~~~~~~~~~~~~~ security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc] kfree(bvalues); ^~~~~~~~~~~~~~ So improve the security_get_bools error handling by freeing these variables and setting their return pointers to NULL and the return len to 0 Cc: stable@vger.kernel.org Signed-off-by: Tom Rix Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 9a20612e47796d0e74fa3a4397f8ba334b272ce6 Author: Sandeep Raghuraman Date: Thu Jun 11 01:36:26 2020 +0530 drm/amdgpu: Replace invalid device ID with a valid device ID commit 790243d3bf78f9830a3b2ffbca1ed0f528295d48 upstream. Initializes Powertune data for a specific Hawaii card by fixing what looks like a typo in the code. The device ID 66B1 is not a supported device ID for this driver, and is not mentioned elsewhere. 67B1 is a valid device ID, and is a Hawaii Pro GPU. I have tested on my R9 390 which has device ID 67B1, and it works fine without problems. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ed7db9838fe92127c59ba64bb55bb637e6fc029f Author: Huacai Chen Date: Tue Mar 31 14:18:08 2020 +0800 drm/qxl: Use correct notify port address when creating cursor ring commit 80e5f89da3ab949fbbf1cae01dfaea29f5483a75 upstream. The command ring and cursor ring use different notify port addresses definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring and cursor ring. This doesn't cause any problems now, because QEMU's behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same. However, QEMU's behavior may be change in future, so let's fix it. P.S.: In the X.org QXL driver, the notify port address of cursor ring is correct. Signed-off-by: Huacai Chen Cc: Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit f3f05971209d4742f1d972c23a614c7c06b6f80e Author: Lyude Paul Date: Fri Apr 3 14:08:32 2020 -0400 drm/dp_mst: Reformat drm_dp_check_act_status() a bit commit a5cb5fa6c3a5c2cf492db667b8670ee7b044b79f upstream. Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by: Lyude Paul [this isn't a fix, but it's needed for the fix that comes after this] Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul Cc: # v3.17+ Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-3-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit e5b20d0b14517d43cc1606590ce4d8ff15e148f6 Author: Wolfram Sang Date: Mon Jun 15 09:58:10 2020 +0200 drm: encoder_slave: fix refcouting error for modules [ Upstream commit f78d4032de60f50fd4afaa0fb68ea03b985f820a ] module_put() balances try_module_get(), not request_module(). Fix the error path to match that. Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.") Signed-off-by: Wolfram Sang Reviewed-by: Emil Velikov Acked-by: Daniel Vetter Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit edcb7efdbb96b80bb7ea86073f942e3c8f6a1605 Author: Kai-Heng Feng Date: Wed Jun 3 15:48:19 2020 +0800 libata: Use per port sync for detach [ Upstream commit b5292111de9bb70cba3489075970889765302136 ] Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before detach") may cause system freeze during suspend. Using async_synchronize_full() in PM callbacks is wrong, since async callbacks that are already scheduled may wait for not-yet-scheduled callbacks, causes a circular dependency. Instead of using big hammer like async_synchronize_full(), use async cookie to make sure port probe are synced, without affecting other scheduled PM callbacks. Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before detach") Suggested-by: John Garry Signed-off-by: Kai-Heng Feng Tested-by: John Garry BugLink: https://bugs.launchpad.net/bugs/1867983 Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a39340ab12b3234dc9b74cc878d1f6bc81dc97bd Author: Will Deacon Date: Fri May 29 14:12:18 2020 +0100 arm64: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints [ Upstream commit 24ebec25fb270100e252b19c288e21bd7d8cc7f7 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire unexpectedly if kernel debugging is enabled. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. (Fixes tag identifies the introduction of unprivileged memory accesses, which exposed this latent bug in the hw_breakpoint code) Cc: Catalin Marinas Cc: James Morse Fixes: 57f4959bad0a ("arm64: kernel: Add support for User Access Override") Reported-by: Luis Machado Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 49289b1fa5a67011c4010e4e9c801b9d565ce395 Author: Jason Yan Date: Tue Jun 16 20:16:55 2020 +0800 block: Fix use-after-free in blkdev_get() [ Upstream commit 2d3a8e2deddea6c89961c422ec0c5b851e648c14 ] In blkdev_get() we call __blkdev_get() to do some internal jobs and if there is some errors in __blkdev_get(), the bdput() is called which means we have released the refcount of the bdev (actually the refcount of the bdev inode). This means we cannot access bdev after that point. But acctually bdev is still accessed in blkdev_get() after calling __blkdev_get(). This results in use-after-free if the refcount is the last one we released in __blkdev_get(). Let's take a look at the following scenerio: CPU0 CPU1 CPU2 blkdev_open blkdev_open Remove disk bd_acquire blkdev_get __blkdev_get del_gendisk bdev_unhash_inode bd_acquire bdev_get_gendisk bd_forget failed because of unhashed bdput bdput (the last one) bdev_evict_inode access bdev => use after free [ 459.350216] BUG: KASAN: use-after-free in __lock_acquire+0x24c1/0x31b0 [ 459.351190] Read of size 8 at addr ffff88806c815a80 by task syz-executor.0/20132 [ 459.352347] [ 459.352594] CPU: 0 PID: 20132 Comm: syz-executor.0 Not tainted 4.19.90 #2 [ 459.353628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 459.354947] Call Trace: [ 459.355337] dump_stack+0x111/0x19e [ 459.355879] ? __lock_acquire+0x24c1/0x31b0 [ 459.356523] print_address_description+0x60/0x223 [ 459.357248] ? __lock_acquire+0x24c1/0x31b0 [ 459.357887] kasan_report.cold+0xae/0x2d8 [ 459.358503] __lock_acquire+0x24c1/0x31b0 [ 459.359120] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.359784] ? lockdep_hardirqs_on+0x37b/0x580 [ 459.360465] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.361123] ? finish_task_switch+0x125/0x600 [ 459.361812] ? finish_task_switch+0xee/0x600 [ 459.362471] ? mark_held_locks+0xf0/0xf0 [ 459.363108] ? __schedule+0x96f/0x21d0 [ 459.363716] lock_acquire+0x111/0x320 [ 459.364285] ? blkdev_get+0xce/0xbe0 [ 459.364846] ? blkdev_get+0xce/0xbe0 [ 459.365390] __mutex_lock+0xf9/0x12a0 [ 459.365948] ? blkdev_get+0xce/0xbe0 [ 459.366493] ? bdev_evict_inode+0x1f0/0x1f0 [ 459.367130] ? blkdev_get+0xce/0xbe0 [ 459.367678] ? destroy_inode+0xbc/0x110 [ 459.368261] ? mutex_trylock+0x1a0/0x1a0 [ 459.368867] ? __blkdev_get+0x3e6/0x1280 [ 459.369463] ? bdev_disk_changed+0x1d0/0x1d0 [ 459.370114] ? blkdev_get+0xce/0xbe0 [ 459.370656] blkdev_get+0xce/0xbe0 [ 459.371178] ? find_held_lock+0x2c/0x110 [ 459.371774] ? __blkdev_get+0x1280/0x1280 [ 459.372383] ? lock_downgrade+0x680/0x680 [ 459.373002] ? lock_acquire+0x111/0x320 [ 459.373587] ? bd_acquire+0x21/0x2c0 [ 459.374134] ? do_raw_spin_unlock+0x4f/0x250 [ 459.374780] blkdev_open+0x202/0x290 [ 459.375325] do_dentry_open+0x49e/0x1050 [ 459.375924] ? blkdev_get_by_dev+0x70/0x70 [ 459.376543] ? __x64_sys_fchdir+0x1f0/0x1f0 [ 459.377192] ? inode_permission+0xbe/0x3a0 [ 459.377818] path_openat+0x148c/0x3f50 [ 459.378392] ? kmem_cache_alloc+0xd5/0x280 [ 459.379016] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.379802] ? path_lookupat.isra.0+0x900/0x900 [ 459.380489] ? __lock_is_held+0xad/0x140 [ 459.381093] do_filp_open+0x1a1/0x280 [ 459.381654] ? may_open_dev+0xf0/0xf0 [ 459.382214] ? find_held_lock+0x2c/0x110 [ 459.382816] ? lock_downgrade+0x680/0x680 [ 459.383425] ? __lock_is_held+0xad/0x140 [ 459.384024] ? do_raw_spin_unlock+0x4f/0x250 [ 459.384668] ? _raw_spin_unlock+0x1f/0x30 [ 459.385280] ? __alloc_fd+0x448/0x560 [ 459.385841] do_sys_open+0x3c3/0x500 [ 459.386386] ? filp_open+0x70/0x70 [ 459.386911] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 459.387610] ? trace_hardirqs_off_caller+0x55/0x1c0 [ 459.388342] ? do_syscall_64+0x1a/0x520 [ 459.388930] do_syscall_64+0xc3/0x520 [ 459.389490] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.390248] RIP: 0033:0x416211 [ 459.390720] Code: 75 14 b8 02 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 19 00 00 c3 48 83 ec 08 e8 0a fa ff ff 48 89 04 24 b8 02 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fa ff ff 48 89 d0 48 83 c4 08 48 3d 01 [ 459.393483] RSP: 002b:00007fe45dfe9a60 EFLAGS: 00000293 ORIG_RAX: 0000000000000002 [ 459.394610] RAX: ffffffffffffffda RBX: 00007fe45dfea6d4 RCX: 0000000000416211 [ 459.395678] RDX: 00007fe45dfe9b0a RSI: 0000000000000002 RDI: 00007fe45dfe9b00 [ 459.396758] RBP: 000000000076bf20 R08: 0000000000000000 R09: 000000000000000a [ 459.397930] R10: 0000000000000075 R11: 0000000000000293 R12: 00000000ffffffff [ 459.399022] R13: 0000000000000bd9 R14: 00000000004cdb80 R15: 000000000076bf2c [ 459.400168] [ 459.400430] Allocated by task 20132: [ 459.401038] kasan_kmalloc+0xbf/0xe0 [ 459.401652] kmem_cache_alloc+0xd5/0x280 [ 459.402330] bdev_alloc_inode+0x18/0x40 [ 459.402970] alloc_inode+0x5f/0x180 [ 459.403510] iget5_locked+0x57/0xd0 [ 459.404095] bdget+0x94/0x4e0 [ 459.404607] bd_acquire+0xfa/0x2c0 [ 459.405113] blkdev_open+0x110/0x290 [ 459.405702] do_dentry_open+0x49e/0x1050 [ 459.406340] path_openat+0x148c/0x3f50 [ 459.406926] do_filp_open+0x1a1/0x280 [ 459.407471] do_sys_open+0x3c3/0x500 [ 459.408010] do_syscall_64+0xc3/0x520 [ 459.408572] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.409415] [ 459.409679] Freed by task 1262: [ 459.410212] __kasan_slab_free+0x129/0x170 [ 459.410919] kmem_cache_free+0xb2/0x2a0 [ 459.411564] rcu_process_callbacks+0xbb2/0x2320 [ 459.412318] __do_softirq+0x225/0x8ac Fix this by delaying bdput() to the end of blkdev_get() which means we have finished accessing bdev. Fixes: 77ea887e433a ("implement in-kernel gendisk events handling") Reported-by: Hulk Robot Signed-off-by: Jason Yan Tested-by: Sedat Dilek Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Reviewed-by: Dan Carpenter Cc: Christoph Hellwig Cc: Jens Axboe Cc: Ming Lei Cc: Jan Kara Cc: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2788511b09b7c1208836d5f6752e6ae0acc5b7b6 Author: David Howells Date: Fri Jun 12 23:58:51 2020 +0100 afs: afs_write_end() should change i_size under the right lock [ Upstream commit 1f32ef79897052ef7d3d154610d8d6af95abde83 ] Fix afs_write_end() to change i_size under vnode->cb_lock rather than ->wb_lock so that it doesn't race with afs_vnode_commit_status() and afs_getattr(). The ->wb_lock is only meant to guard access to ->wb_keys which isn't accessed by that piece of code. Fixes: 4343d00872e1 ("afs: Get rid of the afs_writeback record") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 08de5907c06ed7397930781244e066364708658d Author: David Howells Date: Fri Jun 12 00:15:13 2020 +0100 afs: Fix non-setting of mtime when writing into mmap [ Upstream commit bb413489288e4e457353bac513fddb6330d245ca ] The mtime on an inode needs to be updated when a write is made into an mmap'ed section. There are three ways in which this could be done: update it when page_mkwrite is called, update it when a page is changed from dirty to writeback or leave it to the server and fix the mtime up from the reply to the StoreData RPC. Found with the generic/215 xfstest. Fixes: 1cf7a1518aef ("afs: Implement shared-writeable mmap") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 2ee8f6e72269eb06649ebab3da6bbf59aed3eabe Author: Zhiqiang Liu Date: Mon Jun 15 00:53:30 2020 +0800 bcache: fix potential deadlock problem in btree_gc_coalesce [ Upstream commit be23e837333a914df3f24bf0b32e87b0331ab8d1 ] coccicheck reports: drivers/md//bcache/btree.c:1538:1-7: preceding lock on line 1417 In btree_gc_coalesce func, if the coalescing process fails, we will goto to out_nocoalesce tag directly without releasing new_nodes[i]->write_lock. Then, it will cause a deadlock when trying to acquire new_nodes[i]-> write_lock for freeing new_nodes[i] before return. btree_gc_coalesce func details as follows: if alloc new_nodes[i] fails: goto out_nocoalesce; // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock) // main coalescing process for (i = nodes - 1; i > 0; --i) [snipped] if coalescing process fails: // Here, directly goto out_nocoalesce // tag will cause a deadlock goto out_nocoalesce; [snipped] // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock) // coalesing succ, return return; out_nocoalesce: btree_node_free(new_nodes[i]) // free new_nodes[i] // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock); // set flag for reuse clear_bit(BTREE_NODE_dirty, &ew_nodes[i]->flags); // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock); To fix the problem, we add a new tag 'out_unlock_nocoalesce' for releasing new_nodes[i]->write_lock before out_nocoalesce tag. If coalescing process fails, we will go to out_unlock_nocoalesce tag for releasing new_nodes[i]->write_lock before free new_nodes[i] in out_nocoalesce tag. (Coly Li helps to clean up commit log format.) Fixes: 2a285686c109816 ("bcache: btree locking rework") Signed-off-by: Zhiqiang Liu Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b0873334bc7fa08eda686565df293e7d3901078f Author: yangerkun Date: Mon Jun 1 15:34:04 2020 +0800 ext4: stop overwrite the errcode in ext4_setup_super [ Upstream commit 5adaccac46ea79008d7b75f47913f1a00f91d0ce ] Now the errcode from ext4_commit_super will overwrite EROFS exists in ext4_setup_super. Actually, no need to call ext4_commit_super since we will return EROFS. Fix it by goto done directly. Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super") Signed-off-by: yangerkun Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20200601073404.3712492-1-yangerkun@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 8497c546f3346d7bb78e47aaf71fed881d36d7ad Author: Gaurav Singh Date: Mon Jun 8 13:18:17 2020 -0300 perf report: Fix NULL pointer dereference in hists__fprintf_nr_sample_events() [ Upstream commit 11b6e5482e178055ec1f2444b55f2518713809d1 ] The 'evname' variable can be NULL, as it is checked a few lines back, check it before using. Fixes: 9e207ddfa207 ("perf report: Show call graph from reference events") Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/ Signed-off-by: Gaurav Singh Signed-off-by: Sasha Levin commit 71f660a1a74b2eae7896f18f31b68e9c4f4eaea3 Author: Qais Yousef Date: Mon May 18 16:49:31 2020 +0100 usb/ehci-platform: Set PM runtime as active on resume [ Upstream commit 16bdc04cc98ab0c74392ceef2475ecc5e73fcf49 ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Acked-by: Alan Stern Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-3-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7178d9b7286185bebc8a6299b8d2bce9a5e9df9a Author: Yoshihiro Shimoda Date: Mon Jan 27 17:37:42 2020 +0900 usb: host: ehci-platform: add a quirk to avoid stuck [ Upstream commit cc7eac1e4afdd151085be4d0341a155760388653 ] Since EHCI/OHCI controllers on R-Car Gen3 SoCs are possible to be getting stuck very rarely after a full/low usb device was disconnected. To detect/recover from such a situation, the controllers require a special way which poll the EHCI PORTSC register and changes the OHCI functional state. So, this patch adds a polling timer into the ehci-platform driver, and if the ehci driver detects the issue by the EHCI PORTSC register, the ehci driver removes a companion device (= the OHCI controller) to change the OHCI functional state to USB Reset once. And then, the ehci driver adds the companion device again. Signed-off-by: Yoshihiro Shimoda Acked-by: Alan Stern Link: https://lore.kernel.org/r/1580114262-25029-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 661f5686a1c805e9b1bff65c312c38ef97faa91d Author: Qais Yousef Date: Mon May 18 16:49:30 2020 +0100 usb/xhci-plat: Set PM runtime as active on resume [ Upstream commit 79112cc3c29f4a8c73a21428fbcbcb0afb005e3e ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-2-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d10a69cadbf73f07cb555c260026d3ec9bf921b3 Author: Li RongQing Date: Thu Jun 11 13:11:06 2020 +0800 xdp: Fix xsk_generic_xmit errno [ Upstream commit aa2cad0600ed2ca6a0ab39948d4db1666b6c962b ] Propagate sock_alloc_send_skb error code, not set it to EAGAIN unconditionally, when fail to allocate skb, which might cause that user space unnecessary loops. Fixes: 35fcde7f8deb ("xsk: support for Tx") Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/1591852266-24017-1-git-send-email-lirongqing@baidu.com Signed-off-by: Sasha Levin commit d3265977519b2c3d1d1b42120076acc9356ac004 Author: YiFei Zhu Date: Wed Jun 10 13:41:39 2020 -0500 net/filter: Permit reading NET in load_bytes_relative when MAC not set [ Upstream commit 0f5d82f187e1beda3fe7295dfc500af266a5bd80 ] Added a check in the switch case on start_header that checks for the existence of the header, and in the case that MAC is not set and the caller requests for MAC, -EFAULT. If the caller requests for NET then MAC's existence is completely ignored. There is no function to check NET header's existence and as far as cgroup_skb/egress is concerned it should always be set. Removed for ptr >= the start of header, considering offset is bounded unsigned and should always be true. len <= end - mac is redundant to ptr + len <= end. Fixes: 3eee1f75f2b9 ("bpf: fix bpf_skb_load_bytes_relative pkt length check") Signed-off-by: YiFei Zhu Signed-off-by: Daniel Borkmann Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/76bb820ddb6a95f59a772ecbd8c8a336f646b362.1591812755.git.zhuyifei@google.com Signed-off-by: Sasha Levin commit 3cf0f4b9785089499435518c3ff1378314d730b2 Author: Vitaly Kuznetsov Date: Tue Apr 28 11:38:24 2020 +0200 x86/idt: Keep spurious entries unset in system_vectors [ Upstream commit 1f1fbc70c10e81f70e9fbe2102d439c883269811 ] With commit dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code") non assigned system vectors are also marked as used in 'used_vectors' (now 'system_vectors') bitmap. This makes checks in arch_show_interrupts() whether a particular system vector is allocated to always pass and e.g. 'Hyper-V reenlightenment interrupts' entry always shows up in /proc/interrupts. Another side effect of having all unassigned system vectors marked as used is that irq_matrix_debug_show() will wrongly count them among 'System' vectors. As it is now ensured that alloc_intr_gate() is not called after init, it is possible to leave unused entries in 'system_vectors' unset to fix these issues. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200428093824.1451532-4-vkuznets@redhat.com Signed-off-by: Sasha Levin commit 6d8ea16c999e10039b8db3ebebdd8be616678fb9 Author: Christophe JAILLET Date: Sat May 30 10:16:22 2020 +0200 scsi: acornscsi: Fix an error handling path in acornscsi_probe() [ Upstream commit 42c76c9848e13dbe0538d7ae0147a269dfa859cb ] 'ret' is known to be 0 at this point. Explicitly return -ENOMEM if one of the 'ecardm_iomap()' calls fail. Link: https://lore.kernel.org/r/20200530081622.577888-1-christophe.jaillet@wanadoo.fr Fixes: e95a1b656a98 ("[ARM] rpc: acornscsi: update to new style ecard driver") Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4d1cd8c145725ab27818616d545b8d1b5a14e8b6 Author: Jernej Skrabec Date: Mon Apr 13 11:54:57 2020 +0200 drm/sun4i: hdmi ddc clk: Fix size of m divider [ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ] m divider in DDC clock register is 4 bits wide. Fix that. Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skrabec@siol.net Signed-off-by: Sasha Levin commit e03b115d1847a0d47b046294142c949efb09ce96 Author: Hans de Goede Date: Mon Jun 8 22:46:34 2020 +0200 ASoC: rt5645: Add platform-data for Asus T101HA [ Upstream commit 79d4f823a06796656289f97b922493da5690e46c ] The Asus T101HA uses the default jack-detect mode 3, but instead of using an analog microphone it is using a DMIC on dmic-data-pin 1, like the Asus T100HA. Note unlike the T100HA its jack-detect is not inverted. Add a DMI quirk with the correct settings for this model. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200608204634.93407-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6aefbfe30b2202e1edd817eb3bb76e03be0fa6af Author: Hans de Goede Date: Mon Jun 8 22:46:33 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT10-A tablet [ Upstream commit 199a5e8fda54ab3c8c6f6bf980c004e97ebf5ccb ] The Toshiba Encore WT10-A tablet almost fully works with the default settings for Bay Trail CR devices. The only issue is that it uses a digital mic. connected the the DMIC1 input instead of an analog mic. Add a quirk for this model using the default settings with the input-map replaced with BYT_RT5640_DMIC1_MAP. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200608204634.93407-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7686229901bc76266a97f27ad79d8d98905f5fa0 Author: Bard Liao Date: Mon Jun 8 14:44:13 2020 -0500 ASoC: core: only convert non DPCM link to DPCM link [ Upstream commit 607fa205a7e4dfad28b8a67ab1c985756ddbccb0 ] Additional checks for valid DAIs expose a corner case, where existing BE dailinks get modified, e.g. HDMI links are tagged with dpcm_capture=1 even if the DAIs are for playback. This patch makes those changes conditional and flags configuration issues when a BE dailink is has no_pcm=0 but dpcm_playback or dpcm_capture=1 (which makes no sense). As discussed on the alsa-devel mailing list, there are redundant flags for dpcm_playback, dpcm_capture, playback_only, capture_only. This will have to be cleaned-up in a future update. For now only correct and flag problematic configurations. Fixes: 218fe9b7ec7f3 ("ASoC: soc-core: Set dpcm_playback / dpcm_capture") Suggested-by: Daniel Baluta Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Daniel Baluta Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20200608194415.4663-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 93e09f60e5942988a43bfe70543322baf4072bd8 Author: Zhihao Cheng Date: Tue Jun 2 09:30:45 2020 +0800 afs: Fix memory leak in afs_put_sysnames() [ Upstream commit 2ca068be09bf8e285036603823696140026dcbe7 ] Fix afs_put_sysnames() to actually free the specified afs_sysnames object after its reference count has been decreased to zero and its contents have been released. Fixes: 6f8880d8e681557 ("afs: Implement @sys substitution handling") Signed-off-by: Zhihao Cheng Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 06525464d716a5b1586a876a79b617fa18bb8b2a Author: tannerlove Date: Mon Jun 8 15:37:15 2020 -0400 selftests/net: in timestamping, strncpy needs to preserve null byte [ Upstream commit 8027bc0307ce59759b90679fa5d8b22949586d20 ] If user passed an interface option longer than 15 characters, then device.ifr_name and hwtstamp.ifr_name became non-null-terminated strings. The compiler warned about this: timestamping.c:353:2: warning: ‘strncpy’ specified bound 16 equals \ destination size [-Wstringop-truncation] 353 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name)); Fixes: cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets") Signed-off-by: Tanner Love Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5de587fd8437a85e663e2d5402605a96952152ed Author: Shaokun Zhang Date: Fri Jun 5 17:43:41 2020 +0800 drivers/perf: hisi: Fix wrong value for all counters enable [ Upstream commit 961abd78adcb4c72c343fcd9f9dc5e2ebbe9b448 ] In L3C uncore PMU drivers, bit16 is used to control all counters enable & disable. Wrong value is given in the driver and its default value is 1'b1, it can work because each PMU counter has its own control bits too. Let's fix the wrong value. Fixes: 2940bc433370 ("perf: hisi: Add support for HiSilicon SoC L3C PMU driver") Signed-off-by: Shaokun Zhang Cc: Will Deacon Cc: Mark Rutland Link: https://lore.kernel.org/r/1591350221-32275-1-git-send-email-zhangshaokun@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1b72133e8333b7b8b0d3c52bdcbc30bcf35ce4e8 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:33 2019 -0700 NTB: ntb_test: Fix bug when counting remote files [ Upstream commit 2130c0ba69d69bb21f5c52787f2587db00d13d8a ] When remote files are counted in get_files_count, without using SSH, the code returns 0 because there is a colon prepended to $LOC. $VPATH should have been used instead of $LOC. Fixes: 06bd0407d06c ("NTB: ntb_test: Update ntb_tool Scratchpad tests") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit db2fe2c502c78707872d3c4840176541ae47e765 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:32 2019 -0700 NTB: perf: Fix race condition when run with ntb_test [ Upstream commit 34d8673a01b053b6231a995a4eec9341163d63be ] When running ntb_test, the script tries to run the ntb_perf test immediately after probing the modules. Since adding multi-port support, this fails seeing the new initialization procedure in ntb_perf can not complete instantly. To fix this we add a completion which is waited on when a test is started. In this way, run can be written any time after the module is loaded and it will wait for the initialization to complete instead of sending an error. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit f16225d3452894bcdda77e01f43b67dbbca70531 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:31 2019 -0700 NTB: perf: Fix support for hardware that doesn't have port numbers [ Upstream commit b54369a248c2e033bfcf5d6917e08cf9d73d54a6 ] Legacy drivers do not have port numbers (but is reliably only two ports) and was broken by the recent commit that added mult-port support to ntb_perf. This is especially important to support the cross link topology which is perfectly symmetric and cannot assign unique port numbers easily. Hardware that returns zero for both the local port and the peer should just always use gidx=0 for the only peer. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit b3f110e16026f33dd2086ef66ce9ca0e99d27d4c Author: Logan Gunthorpe Date: Wed Jan 9 12:22:30 2019 -0700 NTB: perf: Don't require one more memory window than number of peers [ Upstream commit a9c4211ac918ade1522aced6b5acfbe824722f7d ] ntb_perf should not require more than one memory window per peer. This was probably an off-by-one error. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 8aeebb1a15776dabcc052567d4a75e5145fd0452 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:27 2019 -0700 NTB: Revert the change to use the NTB device dev for DMA allocations [ Upstream commit 40da7d9a93c8941737ef4a1208d32c13ce017fe1 ] Commit 417cf39cfea9 ("NTB: Set dma mask and dma coherent mask to NTB devices") started using the NTB device for DMA allocations which was turns out was wrong. If the IOMMU is enabled, such alloctanions will always fail with messages such as: DMAR: Allocating domain for 0000:02:00.1 failed This is because the IOMMU has not setup the device for such use. Change the tools back to using the PCI device for allocations seeing it doesn't make sense to add an IOMMU group for the non-physical NTB device. Also remove the code that sets the DMA mask as it no longer makes sense to do this. Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit fff524946f93f675ffc5f75f042be5e51c25b596 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:26 2019 -0700 NTB: ntb_tool: reading the link file should not end in a NULL byte [ Upstream commit 912e12813dd03c602e4922fc34709ec4d4380cf0 ] When running ntb_test this warning is issued: ./ntb_test.sh: line 200: warning: command substitution: ignored null byte in input This is caused by the kernel returning one more byte than is necessary when reading the link file. Reduce the number of bytes read back to 2 as it was before the commit that regressed this. Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 03a8dbf4f7386d5ce84c3633351e89d918a8ab81 Author: Sanjay R Mehta Date: Tue May 5 23:21:50 2020 -0500 ntb_tool: pass correct struct device to dma_alloc_coherent [ Upstream commit 433efe720674efd9fdbcef78be75793393cf05db ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Sanjay R Mehta Signed-off-by: Arindam Nath Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit b0eb9e87afec093036de8caec0b4604eabadedab Author: Sanjay R Mehta Date: Tue May 5 23:21:49 2020 -0500 ntb_perf: pass correct struct device to dma_alloc_coherent [ Upstream commit 98f4e140264eeb52f22ff05be6b6dd48237255ac ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Signed-off-by: Sanjay R Mehta Signed-off-by: Arindam Nath Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit c91cffd0fd010c06d67f3a9a528b858ce28c60fb Author: Bob Peterson Date: Thu Jun 4 14:28:58 2020 -0500 gfs2: fix use-after-free on transaction ail lists [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ] Before this patch, transactions could be merged into the system transaction by function gfs2_merge_trans(), but the transaction ail lists were never merged. Because the ail flushing mechanism can run separately, bd elements can be attached to the transaction's buffer list during the transaction (trans_add_meta, etc) but quickly moved to its ail lists. Later, in function gfs2_trans_end, the transaction can be freed (by gfs2_trans_end) while it still has bd elements queued to its ail lists, which can cause it to either lose track of the bd elements altogether (memory leak) or worse, reference the bd elements after the parent transaction has been freed. Although I've not seen any serious consequences, the problem becomes apparent with the previous patch's addition of: gfs2_assert_warn(sdp, list_empty(&tr->tr_ail1_list)); to function gfs2_trans_free(). This patch adds logic into gfs2_merge_trans() to move the merged transaction's ail lists to the sdp transaction. This prevents the use-after-free. To do this properly, we need to hold the ail lock, so we pass sdp into the function instead of the transaction itself. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit ea9c523635714542731c6466d5a1c7741822cc62 Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:30 2020 -0700 blktrace: fix endianness for blk_log_remap() [ Upstream commit 5aec598c456fe3c1b71a1202cbb42bdc2a643277 ] The function blk_log_remap() can be simplified by removing the call to get_pdu_remap() that copies the values into extra variable to print the data, which also fixes the endiannness warning reported by sparse. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f381b7b180a39add8b59d3bd12248a896e4b82ef Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:29 2020 -0700 blktrace: fix endianness in get_pdu_int() [ Upstream commit 71df3fd82e7cccec7b749a8607a4662d9f7febdd ] In function get_pdu_len() replace variable type from __u64 to __be64. This fixes sparse warning. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 48adb95b73616ed356406811159f0dd40be5b0ef Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:28 2020 -0700 blktrace: use errno instead of bi_status [ Upstream commit 48bc3cd3e07a1486f45d9971c75d6090976c3b1b ] In blk_add_trace_spliti() blk_add_trace_bio_remap() use blk_status_to_errno() to pass the error instead of pasing the bi_status. This fixes the sparse warning. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fb12a1a2108a94bb04381bd9717747d23e6de0a8 Author: Ram Pai Date: Thu Jun 4 16:52:05 2020 -0700 selftests/vm/pkeys: fix alloc_random_pkey() to make it really random [ Upstream commit 6e373263ce07eeaa6410843179535fbdf561fc31 ] alloc_random_pkey() was allocating the same pkey every time. Not all pkeys were geting tested. This fixes it. Signed-off-by: Ram Pai Signed-off-by: Sandipan Das Signed-off-by: Andrew Morton Acked-by: Dave Hansen Cc: Dave Hansen Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: "Aneesh Kumar K.V" Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Link: http://lkml.kernel.org/r/0162f55816d4e783a0d6e49e554d0ab9a3c9a23b.1585646528.git.sandipan@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 48486511bb634225e141d4a671489414c56917ce Author: Nick Desaulniers Date: Thu Jun 4 16:50:49 2020 -0700 elfnote: mark all .note sections SHF_ALLOC [ Upstream commit 51da9dfb7f20911ae4e79e9b412a9c2d4c373d4b ] ELFNOTE_START allows callers to specify flags for .pushsection assembler directives. All callsites but ELF_NOTE use "a" for SHF_ALLOC. For vdso's that explicitly use ELF_NOTE_START and BUILD_SALT, the same section is specified twice after preprocessing, once with "a" flag, once without. Example: .pushsection .note.Linux, "a", @note ; .pushsection .note.Linux, "", @note ; While GNU as allows this ordering, it warns for the opposite ordering, making these directives position dependent. We'd prefer not to precisely match this behavior in Clang's integrated assembler. Instead, the non __ASSEMBLY__ definition of ELF_NOTE uses __attribute__((section(".note.Linux"))) which is created with SHF_ALLOC, so let's make the __ASSEMBLY__ definition of ELF_NOTE consistent with C and just always use "a" flag. This allows Clang to assemble a working mainline (5.6) kernel via: $ make CC=clang AS=clang Signed-off-by: Nick Desaulniers Signed-off-by: Andrew Morton Reviewed-by: Nathan Chancellor Reviewed-by: Fangrui Song Cc: Jeremy Fitzhardinge Cc: Thomas Gleixner Cc: Vincenzo Frascino Link: https://github.com/ClangBuiltLinux/linux/issues/913 Link: http://lkml.kernel.org/r/20200325231250.99205-1-ndesaulniers@google.com Debugged-by: Ilie Halip Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit bd25811b055badd1c8b3d04c0a53ce7678e022ec Author: Arnd Bergmann Date: Thu Jun 4 16:50:30 2020 -0700 include/linux/bitops.h: avoid clang shift-count-overflow warnings [ Upstream commit bd93f003b7462ae39a43c531abca37fe7073b866 ] Clang normally does not warn about certain issues in inline functions when it only happens in an eliminated code path. However if something else goes wrong, it does tend to complain about the definition of hweight_long() on 32-bit targets: include/linux/bitops.h:75:41: error: shift count >= width of type [-Werror,-Wshift-count-overflow] return sizeof(w) == 4 ? hweight32(w) : hweight64(w); ^~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from macro 'hweight64' define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : __arch_hweight64(w)) ^~~~~~~~~~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:21:76: note: expanded from macro '__const_hweight64' define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32)) ^ ~~ include/asm-generic/bitops/const_hweight.h:20:49: note: expanded from macro '__const_hweight32' define __const_hweight32(w) (__const_hweight16(w) + __const_hweight16((w) >> 16)) ^ include/asm-generic/bitops/const_hweight.h:19:72: note: expanded from macro '__const_hweight16' define __const_hweight16(w) (__const_hweight8(w) + __const_hweight8((w) >> 8 )) ^ include/asm-generic/bitops/const_hweight.h:12:9: note: expanded from macro '__const_hweight8' (!!((w) & (1ULL << 2))) + \ Adding an explicit cast to __u64 avoids that warning and makes it easier to read other output. Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Acked-by: Christian Brauner Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Josh Poimboeuf Cc: Nick Desaulniers Link: http://lkml.kernel.org/r/20200505135513.65265-1-arnd@arndb.de Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c1d9c6995d83e63c41eb982d25cbc415e3f004f0 Author: Jann Horn Date: Thu Jun 4 16:50:17 2020 -0700 lib/zlib: remove outdated and incorrect pre-increment optimization [ Upstream commit acaab7335bd6f0c0b54ce3a00bd7f18222ce0f5f ] The zlib inflate code has an old micro-optimization based on the assumption that for pre-increment memory accesses, the compiler will generate code that fits better into the processor's pipeline than what would be generated for post-increment memory accesses. This optimization was already removed in upstream zlib in 2016: https://github.com/madler/zlib/commit/9aaec95e8211 This optimization causes UB according to C99, which says in section 6.5.6 "Additive operators": "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined". This UB is not only a theoretical concern, but can also cause trouble for future work on compiler-based sanitizers. According to the zlib commit, this optimization also is not optimal anymore with modern compilers. Replace uses of OFF, PUP and UP_UNALIGNED with their definitions in the POSTINC case, and remove the macro definitions, just like in the upstream patch. Signed-off-by: Jann Horn Signed-off-by: Andrew Morton Cc: Mikhail Zaslonko Link: http://lkml.kernel.org/r/20200507123112.252723-1-jannh@google.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 31a14e206d3c50c7603eac42cff6073a37c4ebf3 Author: Jiri Benc Date: Wed Jun 3 11:12:14 2020 +0200 geneve: change from tx_error to tx_dropped on missing metadata [ Upstream commit 9d149045b3c0e44c049cdbce8a64e19415290017 ] If the geneve interface is in collect_md (external) mode, it can't send any packets submitted directly to its net interface, as such packets won't have metadata attached. This is expected. However, the kernel itself sends some packets to the interface, most notably, IPv6 DAD, IPv6 multicast listener reports, etc. This is not wrong, as tunnel metadata can be specified in routing table (although technically, that has never worked for IPv6, but hopefully will be fixed eventually) and then the interface must correctly participate in IPv6 housekeeping. The problem is that any such attempt increases the tx_error counter. Just bringing up a geneve interface with IPv6 enabled is enough to see a number of tx_errors. That causes confusion among users, prompting them to find a network error where there is none. Change the counter used to tx_dropped. That better conveys the meaning (there's nothing wrong going on, just some packets are getting dropped) and hopefully will make admins panic less. Signed-off-by: Jiri Benc Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bad2ba840bd2a33e321db6f5be6ef60644238443 Author: Tero Kristo Date: Wed May 27 15:24:29 2020 +0300 crypto: omap-sham - add proper load balancing support for multicore [ Upstream commit 281c377872ff5d15d80df25fc4df02d2676c7cde ] The current implementation of the multiple accelerator core support for OMAP SHA does not work properly. It always picks up the first probed accelerator core if this is available, and rest of the book keeping also gets confused if there are two cores available. Add proper load balancing support for SHA, and also fix any bugs related to the multicore support while doing it. Signed-off-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 283bb2e42f76bb2164992526ad3ef22637124675 Author: Christophe JAILLET Date: Sat May 30 22:49:55 2020 +0200 pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()' [ Upstream commit 11d8da5cabf7c6c3263ba2cd9c00260395867048 ] 'pinctrl_unregister()' should not be called to undo 'devm_pinctrl_register_and_init()', it is already handled by the framework. This simplifies the error handling paths of the probe function. The 'imx_free_resources()' can be removed as well. Fixes: a51c158bf0f7 ("pinctrl: imx: use radix trees for groups and functions") Signed-off-by: Christophe JAILLET Reviewed-by: Dong Aisheng Link: https://lore.kernel.org/r/20200530204955.588962-1-christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 18210a33c3103144178529cf32e86d4c0eec62c3 Author: Christophe JAILLET Date: Sat May 30 22:19:52 2020 +0200 pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()' [ Upstream commit 9eb728321286c4b31e964d2377fca2368526d408 ] When 'pinctrl_register()' has been turned into 'devm_pinctrl_register()', an error handling path has not been updated. Axe a now unneeded 'pinctrl_unregister()'. Fixes: e55e025d1687 ("pinctrl: imxl: Use devm_pinctrl_register() for pinctrl registration") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20200530201952.585798-1-christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 762582dcb51898b278bec19f7e9a731721106245 Author: Can Guo Date: Wed May 27 19:24:42 2020 -0700 scsi: ufs: Don't update urgent bkops level when toggling auto bkops [ Upstream commit be32acff43800c87dc5c707f5d47cc607b76b653 ] Urgent bkops level is used to compare against actual bkops status read from UFS device. Urgent bkops level is set during initialization and might be updated in exception event handler during runtime. But it should not be updated to the actual bkops status every time when auto bkops is toggled. Otherwise, if urgent bkops level is updated to 0, auto bkops shall always be kept enabled. Link: https://lore.kernel.org/r/1590632686-17866-1-git-send-email-cang@codeaurora.org Fixes: 24366c2afbb0 ("scsi: ufs: Recheck bkops level if bkops is disabled") Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e46141f73e5f0dcebb09445a09a877ea4408d653 Author: Qiushi Wu Date: Thu May 28 15:13:53 2020 -0500 scsi: iscsi: Fix reference count leak in iscsi_boot_create_kobj [ Upstream commit 0267ffce562c8bbf9b57ebe0e38445ad04972890 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Link: https://lore.kernel.org/r/20200528201353.14849-1-wu000273@umn.edu Reviewed-by: Lee Duncan Signed-off-by: Qiushi Wu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 76d7a3fb0eac2c360d3b0080a93c81403369548b Author: Bob Peterson Date: Wed Apr 29 08:45:54 2020 -0500 gfs2: Allow lock_nolock mount to specify jid=X [ Upstream commit ea22eee4e6027d8927099de344f7fff43c507ef9 ] Before this patch, a simple typo accidentally added \n to the jid= string for lock_nolock mounts. This made it impossible to mount a gfs2 file system with a journal other than journal0. Thus: mount -tgfs2 -o hostdata="jid=1" Resulted in: mount: wrong fs type, bad option, bad superblock on In most cases this is not a problem. However, for debugging and testing purposes we sometimes want to test the integrity of other journals. This patch removes the unnecessary \n and thus allows lock_nolock users to specify an alternate journal. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 11805b60e23e74d8c8dd9d717cd9532eda006689 Author: Stafford Horne Date: Wed Apr 22 20:24:11 2020 +0900 openrisc: Fix issue with argument clobbering for clone/fork [ Upstream commit 6bd140e14d9aaa734ec37985b8b20a96c0ece948 ] Working on the OpenRISC glibc port I found that sometimes clone was working strange. That the tls data argument sent in r7 was always wrong. Further investigation revealed that the arguments were getting clobbered in the entry code. This patch removes the code that writes to the argument registers. This was likely due to some old code hanging around. This patch fixes this up for clone and fork. This fork clobber is harmless but also useless so remove. Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 8b4332c2785f534b6621c8f1fc101be80668a80f Author: David Howells Date: Sat May 2 13:38:23 2020 +0100 rxrpc: Adjust /proc/net/rxrpc/calls to display call->debug_id not user_ID [ Upstream commit 32f71aa497cfb23d37149c2ef16ad71fce2e45e2 ] The user ID value isn't actually much use - and leaks a kernel pointer or a userspace value - so replace it with the call debug ID, which appears in trace points. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 1a98e4ef324d4735b0a8240717b4e2d1bb9adfd8 Author: Qiushi Wu Date: Wed May 27 21:01:09 2020 -0500 vfio/mdev: Fix reference count leak in add_mdev_supported_type [ Upstream commit aa8ba13cae3134b8ef1c1b6879f66372531da738 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Thus, replace kfree() by kobject_put() to fix this issue. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 7b96953bc640 ("vfio: Mediated device Core driver") Signed-off-by: Qiushi Wu Reviewed-by: Cornelia Huck Reviewed-by: Kirti Wankhede Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit ad936c11d4574a52241bd56706a150375b970f42 Author: Xiyu Yang Date: Mon May 25 22:12:46 2020 +0800 ASoC: fsl_asrc_dma: Fix dma_chan leak when config DMA channel failed [ Upstream commit 36124fb19f1ae68a500cd76a76d40c6e81bee346 ] fsl_asrc_dma_hw_params() invokes dma_request_channel() or fsl_asrc_get_dma_channel(), which returns a reference of the specified dma_chan object to "pair->dma_chan[dir]" with increased refcnt. The reference counting issue happens in one exception handling path of fsl_asrc_dma_hw_params(). When config DMA channel failed for Back-End, the function forgets to decrease the refcnt increased by dma_request_channel() or fsl_asrc_get_dma_channel(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when config DMA channel failed. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1590415966-52416-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b74933661c68cbc9cead48817dd07bb8cdc579d0 Author: Christophe JAILLET Date: Sun May 10 11:53:03 2020 +0200 extcon: adc-jack: Fix an error handling path in 'adc_jack_probe()' [ Upstream commit bc84cff2c92ae5ccb2c37da73756e7174b1b430f ] In some error handling paths, a call to 'iio_channel_get()' is not balanced by a corresponding call to 'iio_channel_release()'. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function. Fixes: 19939860dcae ("extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices") Signed-off-by: Christophe JAILLET Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 50aabfa4d88d62be7cd948a68c6e8b56653b1940 Author: huhai Date: Thu May 21 17:26:48 2020 +1000 powerpc/4xx: Don't unmap NULL mbase [ Upstream commit bcec081ecc940fc38730b29c743bbee661164161 ] Signed-off-by: huhai Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200521072648.1254699-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 219ecf84fb0ba4f32bf3cb012b7723eaf55f38c7 Author: Dan Carpenter Date: Wed May 20 15:04:14 2020 +0300 of: Fix a refcounting bug in __of_attach_node_sysfs() [ Upstream commit 8a325dd06f2358ea0888e4ff1c9ca4bc23bd53f3 ] The problem in this code is that if kobject_add() fails, then it should call of_node_put(np) to drop the reference count. I've actually moved the of_node_get(np) later in the function to avoid needing to do clean up. Fixes: 5b2c2f5a0ea3 ("of: overlay: add missing of_node_get() in __of_attach_node_sysfs") Signed-off-by: Dan Carpenter Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit e80980e5f3b14455c196e414c6d9bf969228eba8 Author: Olga Kornievskaia Date: Sun Apr 26 11:30:00 2020 -0400 NFSv4.1 fix rpc_call_done assignment for BIND_CONN_TO_SESSION [ Upstream commit 1c709b766e73e54d64b1dde1b7cfbcf25bcb15b9 ] Fixes: 02a95dee8cf0 ("NFS add callback_ops to nfs4_proc_bind_conn_to_session_callback") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9d9547be1f97ae294e26244ed1b602ec30b5c78d Author: Fedor Tokarev Date: Sat Mar 28 14:56:55 2020 +0300 net: sunrpc: Fix off-by-one issues in 'rpc_ntop6' [ Upstream commit 118917d696dc59fd3e1741012c2f9db2294bed6f ] Fix off-by-one issues in 'rpc_ntop6': - 'snprintf' returns the number of characters which would have been written if enough space had been available, excluding the terminating null byte. Thus, a return value of 'sizeof(scopebuf)' means that the last character was dropped. - 'strcat' adds a terminating null byte to the string, thus if len == buflen, the null byte is written past the end of the buffer. Signed-off-by: Fedor Tokarev Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 66820e46384260f7c4ec863a804d6d44fca1b68d Author: Chunyan Zhang Date: Tue May 19 11:00:36 2020 +0800 clk: sprd: return correct type of value for _sprd_pll_recalc_rate [ Upstream commit c2f30986d418f26abefc2eec90ebf06716c970d2 ] The function _sprd_pll_recalc_rate() defines return value to unsigned long, but it would return a negative value when malloc fail, changing to return its parent_rate makes more sense, since if the callback .recalc_rate() is not set, the framework returns the parent_rate as well. Fixes: 3e37b005580b ("clk: sprd: add adjustable pll support") Signed-off-by: Chunyan Zhang Link: https://lkml.kernel.org/r/20200519030036.1785-2-zhang.lyra@gmail.com Reviewed-by: Baolin Wang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4e26171e9710c143d41b0e02fcfb5fc4f3756ca2 Author: Qian Cai Date: Wed May 13 09:39:15 2020 -0400 KVM: PPC: Book3S HV: Ignore kmemleak false positives [ Upstream commit 0aca8a5575544bd21b3363058afb8f1e81505150 ] kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then pud_populate() and pmd_populate() will use __pa() to reference the newly allocated memory. Since kmemleak is unable to track the physical memory resulting in false positives, silence those by using kmemleak_ignore(). unreferenced object 0xc000201c382a1000 (size 4096): comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s) hex dump (first 32 bytes): c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r... c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... ..... backtrace: [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv] kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366 (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590 [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv] [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv] [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv] [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv] [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm] [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm] [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm] [<0000000048155cd6>] ksys_ioctl+0xd8/0x130 [<0000000041ffeaa7>] sys_ioctl+0x28/0x40 [<000000004afc4310>] system_call_exception+0x114/0x1e0 [<00000000fb70a873>] system_call_common+0xf0/0x278 unreferenced object 0xc0002001f0c03900 (size 256): comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s) hex dump (first 32 bytes): c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... ..... c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... ..... backtrace: [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv] kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356 (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593 [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv] [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv] [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv] [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv] [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm] [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm] [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm] [<0000000048155cd6>] ksys_ioctl+0xd8/0x130 [<0000000041ffeaa7>] sys_ioctl+0x28/0x40 [<000000004afc4310>] system_call_exception+0x114/0x1e0 [<00000000fb70a873>] system_call_common+0xf0/0x278 Signed-off-by: Qian Cai Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 8c9f4d5034e5ffbb7185bdaedcd7f5c80a364216 Author: Jeffrey Hugo Date: Mon May 25 13:41:25 2020 -0700 scsi: ufs-qcom: Fix scheduling while atomic issue [ Upstream commit 3be60b564de49875e47974c37fabced893cd0931 ] ufs_qcom_dump_dbg_regs() uses usleep_range, a sleeping function, but can be called from atomic context in the following flow: ufshcd_intr -> ufshcd_sl_intr -> ufshcd_check_errors -> ufshcd_print_host_regs -> ufshcd_vops_dbg_register_dump -> ufs_qcom_dump_dbg_regs This causes a boot crash on the Lenovo Miix 630 when the interrupt is handled on the idle thread. Fix the issue by switching to udelay(). Link: https://lore.kernel.org/r/20200525204125.46171-1-jeffrey.l.hugo@gmail.com Fixes: 9c46b8676271 ("scsi: ufs-qcom: dump additional testbus registers") Reviewed-by: Bean Huo Reviewed-by: Avri Altman Signed-off-by: Jeffrey Hugo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 92d1e76a60bb9f97ce2d6d8f8adab70c60a12a9e Author: Nathan Chancellor Date: Sat May 16 01:08:06 2020 -0700 clk: bcm2835: Fix return type of bcm2835_register_gate [ Upstream commit f376c43bec4f8ee8d1ba5c5c4cfbd6e84fb279cb ] bcm2835_register_gate is used as a callback for the clk_register member of bcm2835_clk_desc, which expects a struct clk_hw * return type but bcm2835_register_gate returns a struct clk *. This discrepancy is hidden by the fact that bcm2835_register_gate is cast to the typedef bcm2835_clk_register by the _REGISTER macro. This turns out to be a control flow integrity violation, which is how this was noticed. Change the return type of bcm2835_register_gate to be struct clk_hw * and use clk_hw_register_gate to do so. This should be a non-functional change as clk_register_gate calls clk_hw_register_gate anyways but this is needed to avoid issues with further changes. Fixes: b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and OF APIs") Link: https://github.com/ClangBuiltLinux/linux/issues/1028 Signed-off-by: Nathan Chancellor Link: https://lkml.kernel.org/r/20200516080806.1459784-1-natechancellor@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6fe7d86271789c7ab89fcbb475ed50b32a15c4b6 Author: Dan Carpenter Date: Sat May 23 13:11:29 2020 +0300 scsi: target: tcmu: Fix a use after free in tcmu_check_expired_queue_cmd() [ Upstream commit 9d7464b18892332e35ff37f0b024429a1a9835e6 ] The pr_debug() dereferences "cmd" after we already freed it by calling tcmu_free_cmd(cmd). The debug printk needs to be done earlier. Link: https://lore.kernel.org/r/20200523101129.GB98132@mwanda Fixes: 61fb24822166 ("scsi: target: tcmu: Userspace must not complete queued commands") Reviewed-by: Mike Christie Reviewed-by: David Disseldorp Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 04ed30388c9f9aec4608c5bc5938d023597a5772 Author: Qiushi Wu Date: Mon May 25 00:50:11 2020 -0500 ASoC: fix incomplete error-handling in img_i2s_in_probe. [ Upstream commit 25bf943e4e7b47282bd86ae7d39e039217ebb007 ] Function "pm_runtime_get_sync()" is not handled by "pm_runtime_put()" if "PTR_ERR(rst) == -EPROBE_DEFER". Fix this issue by adding "pm_runtime_put()" into this error path. Fixes: f65bb92ca12e ("ASoC: img-i2s-in: Add runtime PM") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200525055011.31925-1-wu000273@umn.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bad579b96bf1929964d5446adc32b627b4962ae8 Author: Borislav Petkov Date: Mon May 25 12:38:39 2020 +0200 x86/apic: Make TSC deadline timer detection message visible [ Upstream commit de308d1815c9e8fe602a958c5c76142ff6501d75 ] The commit c84cb3735fd5 ("x86/apic: Move TSC deadline timer debug printk") removed the message which said that the deadline timer was enabled. It added a pr_debug() message which is issued when deadline timer validation succeeds. Well, issued only when CONFIG_DYNAMIC_DEBUG is enabled - otherwise pr_debug() calls get optimized away if DEBUG is not defined in the compilation unit. Therefore, make the above message pr_info() so that it is visible in dmesg. Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200525104218.27018-1-bp@alien8.de Signed-off-by: Sasha Levin commit 98fa991017981b52dcc4dc3924fc8e1e83e41bf4 Author: Potnuri Bharat Teja Date: Mon May 25 00:38:14 2020 +0530 RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove [ Upstream commit 49ea0c036ede81f126f1a9389d377999fdf5c5a1 ] Remove device specific debugfs entries immediately if LLD detaches a particular ULD device in case of fatal PCI errors. Link: https://lore.kernel.org/r/20200524190814.17599-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 483269952a96fcc544b906dee1f5d8d1c947f4d9 Author: Pawel Laszczak Date: Mon May 18 12:08:45 2020 +0200 usb: gadget: Fix issue with config_ep_by_speed function [ Upstream commit 5d363120aa548ba52d58907a295eee25f8207ed2 ] This patch adds new config_ep_by_speed_and_alt function which extends the config_ep_by_speed about alt parameter. This additional parameter allows to find proper usb_ss_ep_comp_descriptor. Problem has appeared during testing f_tcm (BOT/UAS) driver function. f_tcm function for SS use array of headers for both BOT/UAS alternate setting: static struct usb_descriptor_header *uasp_ss_function_desc[] = { (struct usb_descriptor_header *) &bot_intf_desc, (struct usb_descriptor_header *) &uasp_ss_bi_desc, (struct usb_descriptor_header *) &bot_bi_ep_comp_desc, (struct usb_descriptor_header *) &uasp_ss_bo_desc, (struct usb_descriptor_header *) &bot_bo_ep_comp_desc, (struct usb_descriptor_header *) &uasp_intf_desc, (struct usb_descriptor_header *) &uasp_ss_bi_desc, (struct usb_descriptor_header *) &uasp_bi_ep_comp_desc, (struct usb_descriptor_header *) &uasp_bi_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_bo_desc, (struct usb_descriptor_header *) &uasp_bo_ep_comp_desc, (struct usb_descriptor_header *) &uasp_bo_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_status_desc, (struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc, (struct usb_descriptor_header *) &uasp_status_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_cmd_desc, (struct usb_descriptor_header *) &uasp_cmd_comp_desc, (struct usb_descriptor_header *) &uasp_cmd_pipe_desc, NULL, }; The first 5 descriptors are associated with BOT alternate setting, and others are associated with UAS. During handling UAS alternate setting f_tcm driver invokes config_ep_by_speed and this function sets incorrect companion endpoint descriptor in usb_ep object. Instead setting ep->comp_desc to uasp_bi_ep_comp_desc function in this case set ep->comp_desc to uasp_ss_bi_desc. This is due to the fact that it searches endpoint based on endpoint address: for_each_ep_desc(speed_desc, d_spd) { chosen_desc = (struct usb_endpoint_descriptor *)*d_spd; if (chosen_desc->bEndpoitAddress == _ep->address) goto ep_found; } And in result it uses the descriptor from BOT alternate setting instead UAS. Finally, it causes that controller driver during enabling endpoints detect that just enabled endpoint for bot. Signed-off-by: Jayshri Pawar Signed-off-by: Pawel Laszczak Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 1a17c51d910b6b89825f1d22083e48ebc2da26e4 Author: Qiushi Wu Date: Fri May 22 23:06:25 2020 -0500 usb: gadget: fix potential double-free in m66592_probe. [ Upstream commit 44734a594196bf1d474212f38fe3a0d37a73278b ] m66592_free_request() is called under label "err_add_udc" and "clean_up", and m66592->ep0_req is not set to NULL after first free, leading to a double-free. Fix this issue by setting m66592->ep0_req to NULL after the first free. Fixes: 0f91349b89f3 ("usb: gadget: convert all users to the new udc infrastructure") Signed-off-by: Qiushi Wu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 8124abb2f825c444f1e02b243bd37cca25dad222 Author: Colin Ian King Date: Thu May 21 16:13:00 2020 +0100 usb: gadget: lpc32xx_udc: don't dereference ep pointer before null check [ Upstream commit eafa80041645cd7604c4357b1a0cd4a3c81f2227 ] Currently pointer ep is being dereferenced before it is null checked leading to a null pointer dereference issue. Fix this by only assigning pointer udc once ep is known to be not null. Also remove a debug message that requires a valid udc which may not be possible at that point. Addresses-Coverity: ("Dereference before null check") Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx") Signed-off-by: Colin Ian King Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 3ff5039699e89232f8ae5ea974d0e31936f0820a Author: Nathan Chancellor Date: Thu Apr 23 09:29:24 2020 -0700 USB: gadget: udc: s3c2410_udc: Remove pointless NULL check in s3c2410_udc_nuke [ Upstream commit 7a0fbcf7c308920bc6116b3a5fb21c8cc5fec128 ] Clang warns: drivers/usb/gadget/udc/s3c2410_udc.c:255:11: warning: comparison of address of 'ep->queue' equal to a null pointer is always false [-Wtautological-pointer-compare] if (&ep->queue == NULL) ~~~~^~~~~ ~~~~ 1 warning generated. It is not wrong, queue is not a pointer so if ep is not NULL, the address of queue cannot be NULL. No other driver does a check like this and this check has been around since the driver was first introduced, presumably with no issues so it does not seem like this check should be something else. Just remove it. Commit afe956c577b2d ("kbuild: Enable -Wtautological-compare") exposed this but it is not the root cause of the warning. Fixes: 3fc154b6b8134 ("USB Gadget driver for Samsung s3c2410 ARM SoC") Link: https://github.com/ClangBuiltLinux/linux/issues/1004 Reviewed-by: Nick Desaulniers Reported-by: kbuild test robot Signed-off-by: Nathan Chancellor Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit b601b5dc4084a75b722ebf8fdbc8c0ce5bc9249c Author: Fabrice Gasnier Date: Thu Apr 23 13:55:53 2020 +0200 usb: dwc2: gadget: move gadget resume after the core is in L0 state [ Upstream commit 8c935deacebb8fac8f41378701eb79d12f3c2e2d ] When the remote wakeup interrupt is triggered, lx_state is resumed from L2 to L0 state. But when the gadget resume is called, lx_state is still L2. This prevents the resume callback to queue any request. Any attempt to queue a request from resume callback will result in: - "submit request only in active state" debug message to be issued - dwc2_hsotg_ep_queue() returns -EAGAIN Call the gadget resume routine after the core is in L0 state. Fixes: f81f46e1f530 ("usb: dwc2: implement hibernation during bus suspend/resume") Acked-by: Minas Harutyunyan Signed-off-by: Fabrice Gasnier Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 6fe93f52ad991f9e637476acd1ce96ab8488290b Author: Stefan Riedmueller Date: Fri Apr 3 15:07:28 2020 +0200 watchdog: da9062: No need to ping manually before setting timeout [ Upstream commit a0948ddba65f4f6d3cfb5e2b84685485d0452966 ] There is actually no need to ping the watchdog before disabling it during timeout change. Disabling the watchdog already takes care of resetting the counter. This fixes an issue during boot when the userspace watchdog handler takes over and the watchdog is already running. Opening the watchdog in this case leads to the first ping and directly after that without the required heartbeat delay a second ping issued by the set_timeout call. Due to the missing delay this resulted in a reset. Signed-off-by: Stefan Riedmueller Reviewed-by: Guenter Roeck Reviewed-by: Adam Thomson Link: https://lore.kernel.org/r/20200403130728.39260-3-s.riedmueller@phytec.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 4053198b37f663e94540455310f97602261e517e Author: Maor Gottlieb Date: Thu May 21 10:26:50 2020 +0300 IB/cma: Fix ports memory leak in cma_configfs [ Upstream commit 63a3345c2d42a9b29e1ce2d3a4043689b3995cea ] The allocated ports structure in never freed. The free function should be called by release_cma_ports_group, but the group is never released since we don't remove its default group. Remove default groups when device group is deleted. Fixes: 045959db65c6 ("IB/cma: Add configfs for rdma_cm") Link: https://lore.kernel.org/r/20200521072650.567908-1-leon@kernel.org Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ff6136914a9b0704f3495d22624571dd9de162bd Author: Marc Zyngier Date: Fri May 1 12:39:21 2020 +0100 PCI: dwc: Fix inner MSI IRQ domain registration [ Upstream commit 0414b93e78d87ecc24ae1a7e61fe97deb29fa2f4 ] On a system that uses the internal DWC MSI widget, I get this warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected: debugfs: File ':soc:pcie@fc000000' in directory 'domains' already present! This is due to the fact that the DWC MSI code tries to register two IRQ domains for the same firmware node, without telling the low level code how to distinguish them (by setting a bus token). This further confuses debugfs which tries to create corresponding files for each domain. Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is the closest thing we have as to "generic MSI". Link: https://lore.kernel.org/r/20200501113921.366597-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Lorenzo Pieralisi Acked-by: Jingoo Han Signed-off-by: Sasha Levin commit 78cf33ae0e9d3875f2735f2386b2a9c1246748c0 Author: Bjorn Helgaas Date: Thu May 21 15:40:07 2020 -0500 PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream Port [ Upstream commit 7b38fd9760f51cc83d80eed2cfbde8b5ead9e93a ] Except for Endpoints, we enable PTM at enumeration-time. Previously we did not account for the fact that Switch Downstream Ports are not permitted to have a PTM capability; their PTM behavior is controlled by the Upstream Port (PCIe r5.0, sec 7.9.16). Since Downstream Ports don't have a PTM capability, we did not mark them as "ptm_enabled", which meant that pci_enable_ptm() on an Endpoint failed because there was no PTM path to it. Mark Downstream Ports as "ptm_enabled" if their Upstream Port has PTM enabled. Fixes: eec097d43100 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints") Reported-by: Aditya Paluri Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 4ad7add5077880f232190962f309907d4f8e74f3 Author: Hannes Reinecke Date: Tue May 19 10:14:19 2020 +0200 dm zoned: return NULL if dmz_get_zone_for_reclaim() fails to find a zone [ Upstream commit 489dc0f06a5837f87482c0ce61d830d24e17082e ] The only case where dmz_get_zone_for_reclaim() cannot return a zone is if the respective lists are empty. So we should just return a simple NULL value here as we really don't have an error code which would make sense. Signed-off-by: Hannes Reinecke Reviewed-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 080fcec7b9086b3981c07a72f567a1fdda9d1b43 Author: Qian Cai Date: Thu Mar 5 23:48:52 2020 -0500 powerpc/64s/pgtable: fix an undefined behaviour [ Upstream commit c2e929b18cea6cbf71364f22d742d9aad7f4677a ] Booting a power9 server with hash MMU could trigger an undefined behaviour because pud_offset(p4d, 0) will do, 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10) Fix it by converting pud_index() and friends to static inline functions. UBSAN: shift-out-of-bounds in arch/powerpc/mm/ptdump/ptdump.c:282:15 shift exponent 34 is too large for 32-bit type 'int' CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-20200303+ #13 Call Trace: dump_stack+0xf4/0x164 (unreliable) ubsan_epilogue+0x18/0x78 __ubsan_handle_shift_out_of_bounds+0x160/0x21c walk_pagetables+0x2cc/0x700 walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282 (inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311 ptdump_check_wx+0x8c/0xf0 mark_rodata_ro+0x48/0x80 kernel_init+0x74/0x194 ret_from_kernel_thread+0x5c/0x74 Suggested-by: Christophe Leroy Signed-off-by: Qian Cai Signed-off-by: Michael Ellerman Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/r/20200306044852.3236-1-cai@lca.pw Signed-off-by: Sasha Levin commit c9004fb171857bd6622bc4686122b0892e561aeb Author: Jon Hunter Date: Fri May 1 08:27:56 2020 +0100 arm64: tegra: Fix ethernet phy-mode for Jetson Xavier [ Upstream commit bba25915b172c72f6fa635f091624d799e3c9cae ] The 'phy-mode' property is currently defined as 'rgmii' for Jetson Xavier. This indicates that the RGMII RX and TX delays are set by the MAC and the internal delays set by the PHY are not used. If the Marvell PHY driver is enabled, such that it is used and not the generic PHY, ethernet failures are seen (DHCP is failing to obtain an IP address) and this is caused because the Marvell PHY driver is disabling the internal RX and TX delays. For Jetson Xavier the internal PHY RX and TX delay should be used and so fix this by setting the 'phy-mode' to 'rgmii-id' and not 'rgmii'. Fixes: f89b58ce71a9 ("arm64: tegra: Add ethernet controller on Tegra194") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 0a562db7c43f64a0f2a8dd2983b87871dba37f95 Author: Bodo Stroesser Date: Mon May 18 18:48:33 2020 +0200 scsi: target: tcmu: Userspace must not complete queued commands [ Upstream commit 61fb2482216679b9e1e797440c148bb143a5040a ] When tcmu queues a new command - no matter whether in command ring or in qfull_queue - a cmd_id from IDR udev->commands is assigned to the command. If userspace sends a wrong command completion containing the cmd_id of a command on the qfull_queue, tcmu_handle_completions() finds the command in the IDR and calls tcmu_handle_completion() for it. This might do some nasty things because commands in qfull_queue do not have a valid dbi list. To fix this bug, we no longer add queued commands to the idr. Instead the cmd_id is assign when a command is written to the command ring. Due to this change I had to adapt the source code at several places where up to now an idr_for_each had been done. [mkp: fix checkpatch warnings] Link: https://lore.kernel.org/r/20200518164833.12775-1-bstroesser@ts.fujitsu.com Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 34d68f5c1d9f00714ee96f235b5de82a1dbea430 Author: Marek Szyprowski Date: Tue May 19 12:26:52 2020 +0200 clk: samsung: exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1 [ Upstream commit 25bdae0f1c6609ceaf55fe6700654f0be2253d8e ] Mark the SCLK clock for Exynos5433 I2S1 device with IGNORE_UNUSED flag to match its behaviour with SCLK clock for AUD_I2S (I2S0) device until a proper fix for Exynos I2S driver is ready. This fixes the following synchronous abort issue revealed by the probe order change caused by the commit 93d2e4322aa7 ("of: platform: Batch fwnode parsing when adding all top level devices") Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701 Hardware name: Samsung TM2E board (DT) Workqueue: events deferred_probe_work_func pstate: 60000005 (nZCv daif -PAN -UAO) pc : samsung_i2s_probe+0x768/0x8f0 lr : samsung_i2s_probe+0x688/0x8f0 ... Call trace: samsung_i2s_probe+0x768/0x8f0 platform_drv_probe+0x50/0xa8 really_probe+0x108/0x370 driver_probe_device+0x54/0xb8 __device_attach_driver+0x90/0xc0 bus_for_each_drv+0x70/0xc8 __device_attach+0xdc/0x140 device_initial_probe+0x10/0x18 bus_probe_device+0x94/0xa0 deferred_probe_work_func+0x70/0xa8 process_one_work+0x2a8/0x718 worker_thread+0x48/0x470 kthread+0x134/0x160 ret_from_fork+0x10/0x1c Code: 17ffffaf d503201f f94086c0 91003000 (88dffc00) ---[ end trace ccf721c9400ddbd6 ]--- Signed-off-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 23abe47ce23a9698eeeec2d92f27b4fb045535fd Author: Souptick Joarder Date: Mon May 18 23:49:51 2020 +0530 fpga: dfl: afu: Corrected error handling levels [ Upstream commit c9d7e3da1f3c4cf5dddfc5d7ce4d76d013aba1cc ] Corrected error handling goto sequnece. Level put_pages should be called when pinned pages >= 0 && pinned != npages. Level free_pages should be called when pinned pages < 0. Fixes: fa8dda1edef9 ("fpga: dfl: afu: add DFL_FPGA_PORT_DMA_MAP/UNMAP ioctls support") Signed-off-by: Souptick Joarder Acked-by: Wu Hao Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/1589825991-3545-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2783eb90f5a17fc523bf8e9389d978f1562eaba3 Author: Gregory CLEMENT Date: Mon May 18 10:45:13 2020 +0200 tty: n_gsm: Fix bogus i++ in gsm_data_kick [ Upstream commit 4dd31f1ffec6c370c3c2e0c605628bf5e16d5c46 ] When submitting the previous fix "tty: n_gsm: Fix waking up upper tty layer when room available". It was suggested to switch from a while to a for loop, but when doing it, there was a remaining bogus i++. This patch removes this i++ and also reorganizes the code making it more compact. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200518084517.2173242-3-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 549ff843327f39584499b25c6caa044507771bbf Author: Tang Bin Date: Wed May 13 21:26:47 2020 +0800 USB: host: ehci-mxc: Add error handling in ehci_mxc_drv_probe() [ Upstream commit d49292025f79693d3348f8e2029a8b4703be0f0a ] The function ehci_mxc_drv_probe() does not perform sufficient error checking after executing platform_get_irq(), thus fix it. Fixes: 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based boards") Signed-off-by: Zhang Shengju Signed-off-by: Tang Bin Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20200513132647.5456-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit efe7880ed249fae582e10b993f97a9bb6e9e6bf9 Author: Hans de Goede Date: Mon May 18 09:24:16 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT8-A tablet [ Upstream commit 0e0e10fde0e9808d1991268f5dca69fb36c025f7 ] The Toshiba Encore WT8-A tablet almost fully works with the default settings for non-CR Bay Trail devices. The only problem is that its jack-detect switch is not inverted (it is active high instead of the normal active low). Add a quirk for this model using the default settings + BYT_RT5640_JD_NOT_INV. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200518072416.5348-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ccfdc9952c8211d49cc3303b947e13f448a22364 Author: Roy Spliet Date: Tue Apr 7 18:07:37 2020 +0100 drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit c83258a757687ffccce37ed73dba56cc6d4b8a1b Author: Qais Yousef Date: Mon May 18 16:49:29 2020 +0100 usb/ohci-platform: Fix a warning when hibernating [ Upstream commit 1cb3b0095c3d0bb96912bfbbce4fc006d41f367c ] The following warning was observed when attempting to suspend to disk using a USB flash as a swap device. [ 111.779649] ------------[ cut here ]------------ [ 111.788382] URB (____ptrval____) submitted while active [ 111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590 [ 111.805417] Modules linked in: [ 111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545 [ 111.817796] Hardware name: ARM Juno development board (r2) (DT) [ 111.823896] Workqueue: usb_hub_wq hub_event [ 111.828217] pstate: 60000005 (nZCv daif -PAN -UAO) [ 111.833156] pc : usb_submit_urb+0x3d8/0x590 [ 111.837471] lr : usb_submit_urb+0x3d8/0x590 [ 111.841783] sp : ffff800018de38b0 [ 111.845205] x29: ffff800018de38b0 x28: 0000000000000003 [ 111.850682] x27: ffff000970530b20 x26: ffff8000133fd000 [ 111.856159] x25: ffff8000133fd000 x24: ffff800018de3b38 [ 111.861635] x23: 0000000000000004 x22: 0000000000000c00 [ 111.867112] x21: 0000000000000000 x20: 00000000fffffff0 [ 111.872589] x19: ffff0009704e7a00 x18: ffffffffffffffff [ 111.878065] x17: 00000000a7c8f4bc x16: 000000002af33de8 [ 111.883542] x15: ffff8000133fda88 x14: 0720072007200720 [ 111.889019] x13: 0720072007200720 x12: 0720072007200720 [ 111.894496] x11: 0000000000000000 x10: 00000000a5286134 [ 111.899973] x9 : 0000000000000002 x8 : ffff000970c837a0 [ 111.905449] x7 : 0000000000000000 x6 : ffff800018de3570 [ 111.910926] x5 : 0000000000000001 x4 : 0000000000000003 [ 111.916401] x3 : 0000000000000000 x2 : ffff800013427118 [ 111.921879] x1 : 9d4e965b4b7d7c00 x0 : 0000000000000000 [ 111.927356] Call trace: [ 111.929892] usb_submit_urb+0x3d8/0x590 [ 111.933852] hub_activate+0x108/0x7f0 [ 111.937633] hub_resume+0xac/0x148 [ 111.941149] usb_resume_interface.isra.10+0x60/0x138 [ 111.946265] usb_resume_both+0xe4/0x140 [ 111.950225] usb_runtime_resume+0x24/0x30 [ 111.954365] __rpm_callback+0xdc/0x138 [ 111.958236] rpm_callback+0x34/0x98 [ 111.961841] rpm_resume+0x4a8/0x720 [ 111.965445] rpm_resume+0x50c/0x720 [ 111.969049] __pm_runtime_resume+0x4c/0xb8 [ 111.973276] usb_autopm_get_interface+0x28/0x60 [ 111.977948] hub_event+0x80/0x16d8 [ 111.981466] process_one_work+0x2a4/0x748 [ 111.985604] worker_thread+0x48/0x498 [ 111.989387] kthread+0x13c/0x140 [ 111.992725] ret_from_fork+0x10/0x18 [ 111.996415] irq event stamp: 354 [ 111.999756] hardirqs last enabled at (353): [] console_unlock+0x504/0x5b8 [ 112.008441] hardirqs last disabled at (354): [] do_debug_exception+0x1a8/0x258 [ 112.017479] softirqs last enabled at (350): [] __do_softirq+0x4bc/0x568 [ 112.025984] softirqs last disabled at (343): [] irq_exit+0x144/0x150 [ 112.034129] ---[ end trace dc96030b9cf6c8a3 ]--- The problem was tracked down to a missing call to pm_runtime_set_active() on resume in ohci-platform. Link: https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Acked-by: Alan Stern Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-1-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e9aaff2b5f0351c5beefd633afe11b8dbcd73905 Author: Alex Williamson Date: Wed Apr 8 11:45:28 2020 -0600 vfio-pci: Mask cap zero [ Upstream commit bc138db1b96264b9c1779cf18d5a3b186aa90066 ] The PCI Code and ID Assignment Specification changed capability ID 0 from reserved to a NULL capability in the v1.1 revision. The NULL capability is defined to include only the 16-bit capability header, ie. only the ID and next pointer. Unfortunately vfio-pci creates a map of config space, where ID 0 is used to reserve the standard type 0 header. Finding an actual capability with this ID therefore results in a bogus range marked in that map and conflicts with subsequent capabilities. As this seems to be a dummy capability anyway and we already support dropping capabilities, let's hide this one rather than delving into the potentially subtle dependencies within our map. Seen on an NVIDIA Tesla T4. Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 020d0e3730308ecd718974bcd557b020b0b04798 Author: Geoff Levand Date: Sat May 9 18:58:32 2020 +0000 powerpc/ps3: Fix kexec shutdown hang [ Upstream commit 126554465d93b10662742128918a5fc338cda4aa ] The ps3_mm_region_destroy() and ps3_mm_vas_destroy() routines are called very late in the shutdown via kexec's mmu_cleanup_all routine. By the time mmu_cleanup_all runs it is too late to use udbg_printf, and calling it will cause PS3 systems to hang. Remove all debugging statements from ps3_mm_region_destroy() and ps3_mm_vas_destroy() and replace any error reporting with calls to lv1_panic. With this change builds with 'DEBUG' defined will not cause kexec reboots to hang, and builds with 'DEBUG' defined or not will end in lv1_panic if an error is encountered. Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/7325c4af2b4c989c19d6a26b90b1fec9c0615ddf.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin commit 45a4f5d392f8308652695f7e24b9697a09e2964b Author: Nicholas Piggin Date: Fri May 8 14:33:58 2020 +1000 powerpc/pseries/ras: Fix FWNMI_VALID off by one [ Upstream commit deb70f7a35a22dffa55b2c3aac71bc6fb0f486ce ] This was discovered developing qemu fwnmi sreset support. This off-by-one bug means the last 16 bytes of the rtas area can not be used for a 16 byte save area. It's not a serious bug, and QEMU implementation has to retain a workaround for old kernels, but it's good to tighten it. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Acked-by: Mahesh Salgaonkar Link: https://lore.kernel.org/r/20200508043408.886394-7-npiggin@gmail.com Signed-off-by: Sasha Levin commit 1d9c47a329a3045fbb761d10aa2930f8811011dc Author: Feng Tang Date: Fri Apr 17 12:48:28 2020 +0800 ipmi: use vzalloc instead of kmalloc for user creation [ Upstream commit 7c47a219b95d0e06b5ef5fcc7bad807895015eac ] We met mulitple times of failure of staring bmc-watchdog, due to the runtime memory allocation failure of order 4. bmc-watchdog: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 1 PID: 2571 Comm: bmc-watchdog Not tainted 5.5.0-00045-g7d6bb61d6188c #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0015.110720180833 11/07/2018 Call Trace: dump_stack+0x66/0x8b warn_alloc+0xfe/0x160 __alloc_pages_slowpath+0xd3e/0xd80 __alloc_pages_nodemask+0x2f0/0x340 kmalloc_order+0x18/0x70 kmalloc_order_trace+0x1d/0xb0 ipmi_create_user+0x55/0x2c0 [ipmi_msghandler] ipmi_open+0x72/0x110 [ipmi_devintf] chrdev_open+0xcb/0x1e0 do_dentry_open+0x1ce/0x380 path_openat+0x305/0x14f0 do_filp_open+0x9b/0x110 do_sys_open+0x1bd/0x250 do_syscall_64+0x5b/0x1f0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using vzalloc/vfree for creating ipmi_user heals the problem Thanks to Stephen Rothwell for finding the vmalloc.h inclusion issue. Signed-off-by: Feng Tang Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 5a5b485c22890bac947969c5ae0a3c79e064fa55 Author: Cristian Klein Date: Fri May 8 17:26:04 2020 +0200 HID: Add quirks for Trust Panora Graphic Tablet [ Upstream commit fb68ada81e65d593b51544fa43c284322107a742 ] The Trust Panora Graphic Tablet has two interfaces. Interface zero reports pen movement, pen pressure and pen buttons. Interface one reports tablet buttons and tablet scroll. Both use the mouse protocol. Without these quirks, libinput gets confused about what device it talks to. For completeness, here is the usbhid-dump: ``` $ sudo usbhid-dump -d 145f:0212 003:013:001:DESCRIPTOR 1588949402.559961 05 0D 09 01 A1 01 85 07 A1 02 09 00 75 08 95 07 81 02 C0 C0 09 0E A1 01 85 05 09 23 A1 02 09 52 09 53 25 0A 75 08 95 02 B1 02 C0 C0 05 0C 09 36 A1 00 85 06 05 09 19 01 29 20 15 00 25 01 95 20 75 01 81 02 C0 003:013:000:DESCRIPTOR 1588949402.563942 05 01 09 02 A1 01 85 08 09 01 A1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01 05 01 09 30 09 31 09 38 09 00 15 81 25 7F 75 08 95 04 81 06 C0 C0 05 01 09 02 A1 01 85 09 09 01 A1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01 05 01 09 30 09 31 26 FF 7F 95 02 75 10 81 02 05 0D 09 30 26 FF 03 95 01 75 10 81 02 C0 C0 05 01 09 00 A1 01 85 04 A1 00 26 FF 00 09 00 75 08 95 07 B1 02 C0 C0 ``` Signed-off-by: Cristian Klein Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit d1ceda6fa63be0f9c8e1b5133da87f6ced3a4723 Author: Gregory CLEMENT Date: Tue May 12 13:53:23 2020 +0200 tty: n_gsm: Fix waking up upper tty layer when room available [ Upstream commit 01dbb362f0a114fbce19c8abe4cd6f4710e934d5 ] Warn the upper layer when n_gms is ready to receive data again. Without this the associated virtual tty remains blocked indefinitely. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200512115323.1447922-4-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 56e3912e8ad5a41d3d325d5ff10c106e16d3bb15 Author: Gregory CLEMENT Date: Tue May 12 13:53:22 2020 +0200 tty: n_gsm: Fix SOF skipping [ Upstream commit 84d6f81c1fb58b56eba81ff0a36cf31946064b40 ] For at least some modems like the TELIT LE910, skipping SOF makes transfers blocking indefinitely after a short amount of data transferred. Given the small improvement provided by skipping the SOF (just one byte on about 100 bytes), it seems better to completely remove this "feature" than make it optional. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200512115323.1447922-3-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 615e2d0bd598c553c5ffd383cccd9ac7d00f76a2 Author: Michael Ellerman Date: Tue Apr 28 22:31:30 2020 +1000 powerpc/64: Don't initialise init_task->thread.regs [ Upstream commit 7ffa8b7dc11752827329e4e84a574ea6aaf24716 ] Aneesh increased the size of struct pt_regs by 16 bytes and started seeing this WARN_ON: smp: Bringing up secondary CPUs ... ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/powerpc/kernel/process.c:455 giveup_all+0xb4/0x110 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+ #318 NIP: c00000000001a2b4 LR: c00000000001a29c CTR: c0000000031d0000 REGS: c0000000026d3980 TRAP: 0700 Not tainted (5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+) MSR: 800000000282b033 CR: 48048224 XER: 00000000 CFAR: c000000000019cc8 IRQMASK: 1 GPR00: c00000000001a264 c0000000026d3c20 c0000000026d7200 800000000280b033 GPR04: 0000000000000001 0000000000000000 0000000000000077 30206d7372203164 GPR08: 0000000000002000 0000000002002000 800000000280b033 3230303030303030 GPR12: 0000000000008800 c0000000031d0000 0000000000800050 0000000002000066 GPR16: 000000000309a1a0 000000000309a4b0 000000000309a2d8 000000000309a890 GPR20: 00000000030d0098 c00000000264da40 00000000fd620000 c0000000ff798080 GPR24: c00000000264edf0 c0000001007469f0 00000000fd620000 c0000000020e5e90 GPR28: c00000000264edf0 c00000000264d200 000000001db60000 c00000000264d200 NIP [c00000000001a2b4] giveup_all+0xb4/0x110 LR [c00000000001a29c] giveup_all+0x9c/0x110 Call Trace: [c0000000026d3c20] [c00000000001a264] giveup_all+0x64/0x110 (unreliable) [c0000000026d3c90] [c00000000001ae34] __switch_to+0x104/0x480 [c0000000026d3cf0] [c000000000e0b8a0] __schedule+0x320/0x970 [c0000000026d3dd0] [c000000000e0c518] schedule_idle+0x38/0x70 [c0000000026d3df0] [c00000000019c7c8] do_idle+0x248/0x3f0 [c0000000026d3e70] [c00000000019cbb8] cpu_startup_entry+0x38/0x40 [c0000000026d3ea0] [c000000000011bb0] rest_init+0xe0/0xf8 [c0000000026d3ed0] [c000000002004820] start_kernel+0x990/0x9e0 [c0000000026d3f90] [c00000000000c49c] start_here_common+0x1c/0x400 Which was unexpected. The warning is checking the thread.regs->msr value of the task we are switching from: usermsr = tsk->thread.regs->msr; ... WARN_ON((usermsr & MSR_VSX) && !((usermsr & MSR_FP) && (usermsr & MSR_VEC))); ie. if MSR_VSX is set then both of MSR_FP and MSR_VEC are also set. Dumping tsk->thread.regs->msr we see that it's: 0x1db60000 Which is not a normal looking MSR, in fact the only valid bit is MSR_VSX, all the other bits are reserved in the current definition of the MSR. We can see from the oops that it was swapper/0 that we were switching from when we hit the warning, ie. init_task. So its thread.regs points to the base (high addresses) in init_stack. Dumping the content of init_task->thread.regs, with the members of pt_regs annotated (the 16 bytes larger version), we see: 0000000000000000 c000000002780080 gpr[0] gpr[1] 0000000000000000 c000000002666008 gpr[2] gpr[3] c0000000026d3ed0 0000000000000078 gpr[4] gpr[5] c000000000011b68 c000000002780080 gpr[6] gpr[7] 0000000000000000 0000000000000000 gpr[8] gpr[9] c0000000026d3f90 0000800000002200 gpr[10] gpr[11] c000000002004820 c0000000026d7200 gpr[12] gpr[13] 000000001db60000 c0000000010aabe8 gpr[14] gpr[15] c0000000010aabe8 c0000000010aabe8 gpr[16] gpr[17] c00000000294d598 0000000000000000 gpr[18] gpr[19] 0000000000000000 0000000000001ff8 gpr[20] gpr[21] 0000000000000000 c00000000206d608 gpr[22] gpr[23] c00000000278e0cc 0000000000000000 gpr[24] gpr[25] 000000002fff0000 c000000000000000 gpr[26] gpr[27] 0000000002000000 0000000000000028 gpr[28] gpr[29] 000000001db60000 0000000004750000 gpr[30] gpr[31] 0000000002000000 000000001db60000 nip msr 0000000000000000 0000000000000000 orig_r3 ctr c00000000000c49c 0000000000000000 link xer 0000000000000000 0000000000000000 ccr softe 0000000000000000 0000000000000000 trap dar 0000000000000000 0000000000000000 dsisr result 0000000000000000 0000000000000000 ppr kuap 0000000000000000 0000000000000000 pad[2] pad[3] This looks suspiciously like stack frames, not a pt_regs. If we look closely we can see return addresses from the stack trace above, c000000002004820 (start_kernel) and c00000000000c49c (start_here_common). init_task->thread.regs is setup at build time in processor.h: #define INIT_THREAD { \ .ksp = INIT_SP, \ .regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \ The early boot code where we setup the initial stack is: LOAD_REG_ADDR(r3,init_thread_union) /* set up a stack pointer */ LOAD_REG_IMMEDIATE(r1,THREAD_SIZE) add r1,r3,r1 li r0,0 stdu r0,-STACK_FRAME_OVERHEAD(r1) Which creates a stack frame of size 112 bytes (STACK_FRAME_OVERHEAD). Which is far too small to contain a pt_regs. So the result is init_task->thread.regs is pointing at some stack frames on the init stack, not at a pt_regs. We have gotten away with this for so long because with pt_regs at its current size the MSR happens to point into the first frame, at a location that is not written to by the early asm. With the 16 byte expansion the MSR falls into the second frame, which is used by the compiler, and collides with a saved register that tends to be non-zero. As far as I can see this has been wrong since the original merge of 64-bit ppc support, back in 2002. Conceptually swapper should have no regs, it never entered from userspace, and in fact that's what we do on 32-bit. It's also presumably what the "bogus" comment is referring to. So I think the right fix is to just not-initialise regs at all. I'm slightly worried this will break some code that isn't prepared for a NULL regs, but we'll have to see. Remove the comment in head_64.S which refers to us setting up the regs (even though we never did), and is otherwise not really accurate any more. Reported-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200428123130.73078-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 5d78c4a343f4e89b47b27d382b117ce70a1138a5 Author: Rob Herring Date: Wed May 13 17:38:58 2020 -0500 PCI: Fix pci_register_host_bridge() device_register() error handling [ Upstream commit 1b54ae8327a4d630111c8d88ba7906483ec6010b ] If device_register() has an error, we should bail out of pci_register_host_bridge() rather than continuing on. Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Link: https://lore.kernel.org/r/20200513223859.11295-1-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Bjorn Helgaas Reviewed-by: Lorenzo Pieralisi Reviewed-by: Arnd Bergmann Signed-off-by: Sasha Levin commit aee22d36810edc6a94be7d099d6831821dc897e6 Author: Tero Kristo Date: Wed Apr 29 16:13:39 2020 +0300 clk: ti: composite: fix memory leak [ Upstream commit c7c1cbbc9217ebb5601b88d138d4a5358548de9d ] The parent_names is never released for a component clock definition, causing some memory leak. Fix by releasing it once it is no longer needed. Reported-by: Tomi Valkeinen Signed-off-by: Tero Kristo Link: https://lkml.kernel.org/r/20200429131341.4697-2-t-kristo@ti.com Acked-by: Tony Lindgren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 68728008569cc364cdb52a1d7ea6d61c6f23ddc8 Author: Arnd Bergmann Date: Thu May 7 23:34:28 2020 +0200 dlm: remove BUG() before panic() [ Upstream commit fe204591cc9480347af7d2d6029b24a62e449486 ] Building a kernel with clang sometimes fails with an objtool error in dlm: fs/dlm/lock.o: warning: objtool: revert_lock_pc()+0xbd: can't find jump dest instruction at .text+0xd7fc The problem is that BUG() never returns and the compiler knows that anything after it is unreachable, however the panic still emits some code that does not get fully eliminated. Having both BUG() and panic() is really pointless as the BUG() kills the current process and the subsequent panic() never hits. In most cases, we probably don't really want either and should replace the DLM_ASSERT() statements with WARN_ON(), as has been done for some of them. Remove the BUG() here so the user at least sees the panic message and we can reliably build randconfig kernels. Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM") Cc: Josh Poimboeuf Cc: clang-built-linux@googlegroups.com Signed-off-by: Arnd Bergmann Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit c13d46272684666790f897fa08a37ecab647d183 Author: Dafna Hirschfeld Date: Wed May 6 12:09:03 2020 +0200 pinctrl: rockchip: fix memleak in rockchip_dt_node_to_map [ Upstream commit d7faa8ffb6be57bf8233a4b5a636d76b83c51ce7 ] In function rockchip_dt_node_to_map, a new_map variable is allocated by: new_map = devm_kcalloc(pctldev->dev, map_num, sizeof(*new_map), GFP_KERNEL); This uses devres and attaches new_map to the pinctrl driver. This cause a leak since new_map is not released when the probed driver is removed. Fix it by using kcalloc to allocate new_map and free it in `rockchip_dt_free_map` Signed-off-by: Dafna Hirschfeld Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200506100903.15420-1-dafna.hirschfeld@collabora.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fc3dce348b9bca238540c5fc237ba37bc9bc8a57 Author: Suganath Prabu S Date: Fri May 8 07:07:38 2020 -0400 scsi: mpt3sas: Fix double free warnings [ Upstream commit cbbfdb2a2416c9f0cde913cf09670097ac281282 ] Fix following warning from Smatch static analyser: drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->hpr_lookup' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->internal_lookup' double freed Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.com Reported-by: Dan Carpenter Signed-off-by: Suganath Prabu S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 99545a110a49788225535991f654a565945a61db Author: Dmitry Osipenko Date: Sun Mar 29 18:15:44 2020 +0200 power: supply: smb347-charger: IRQSTAT_D is volatile [ Upstream commit c32ea07a30630ace950e07ffe7a18bdcc25898e1 ] Fix failure when USB cable is connected: smb347 2-006a: reading IRQSTAT_D failed Fixes: 1502cfe19bac ("smb347-charger: Fix battery status reporting logic for charger faults") Tested-by: David Heidelberg Signed-off-by: Dmitry Osipenko Signed-off-by: David Heidelberg Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 39e092685670ab5fb30a039210ca665c833b604e Author: Christophe JAILLET Date: Sat May 9 10:23:23 2020 +0200 power: supply: lp8788: Fix an error handling path in 'lp8788_charger_probe()' [ Upstream commit 934ed3847a4ebc75b655659c4d2349ba4337941c ] In the probe function, in case of error, resources allocated in 'lp8788_setup_adc_channel()' must be released. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function and to axe the 'lp8788_release_adc_channel()' function which is now useless. Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Christophe JAILLET Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 9d10dbdcc280bc9309668e0845441b3c4fa0fa72 Author: Viacheslav Dubeyko Date: Fri Apr 10 11:07:08 2020 +0300 scsi: qla2xxx: Fix warning after FC target reset [ Upstream commit f839544ccff60cbe534282aac68858fc3fb278ca ] Currently, FC target reset finishes with the warning message: [84010.596893] ------------[ cut here ]------------ [84010.596917] WARNING: CPU: 238 PID: 279973 at ../drivers/scsi/qla2xxx/qla_target.c:6644 qlt_enable_vha+0x1d0/0x260 [qla2xxx] [84010.596918] Modules linked in: vrf af_packet 8021q garp mrp stp llc netlink_diag target_tatlin_tblock(OEX) dm_ec(OEX) ttln_rdma(OEX) dm_frontend(OEX) nvme_rdma nvmet tcm_qla2xxx iscsi_target_mod target_core_mod at24 nvmem_core pnv_php ipmi_watchdog ipmi_ssif vmx_crypto gf128mul crct10dif_vpmsum qla2xxx rpcrdma nvme_fc powernv_flash(X) nvme_fabrics uio_pdrv_genirq mtd rtc_opal(X) ibmpowernv(X) opal_prd(X) uio scsi_transport_fc i2c_opal(X) ses enclosure ipmi_poweroff ast i2c_algo_bit ttm bmc_mcu(OEX) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks agpgart nfsd auth_rpcgss nfs_acl ipmi_powernv(X) lockd ipmi_devintf ipmi_msghandler grace dummy ext4 crc16 jbd2 mbcache sd_mod rdma_ucm ib_iser rdma_cm ib_umad iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm [84010.596975] configfs mlx5_ib ib_uverbs ib_core mlx5_core crc32c_vpmsum xhci_pci xhci_hcd mpt3sas(OEX) tg3 usbcore mlxfw tls raid_class libphy scsi_transport_sas devlink ptp pps_core nvme nvme_core sunrpc dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4 [84010.597001] Supported: Yes, External [84010.597004] CPU: 238 PID: 279973 Comm: bash Tainted: G OE 4.12.14-197.29-default #1 SLE15-SP1 [84010.597006] task: c000000a104c0000 task.stack: c000000b52188000 [84010.597007] NIP: d00000001ffd7f78 LR: d00000001ffd7f6c CTR: c0000000001676c0 [84010.597008] REGS: c000000b5218b910 TRAP: 0700 Tainted: G OE (4.12.14-197.29-default) [84010.597008] MSR: 900000010282b033 [84010.597015] CR: 48242424 XER: 00000000 [84010.597016] CFAR: d00000001ff45d08 SOFTE: 1 GPR00: d00000001ffd7f6c c000000b5218bb90 d00000002001b228 0000000000000102 GPR04: 0000000000000001 0000000000000001 00013d91ed0a5e2d 0000000000000000 GPR08: c000000007793300 0000000000000000 0000000000000000 c000000a086e7818 GPR12: 0000000000002200 c000000007793300 0000000000000000 000000012bc937c0 GPR16: 000000012bbf7ed0 0000000000000000 000000012bc3dd10 0000000000000000 GPR20: 000000012bc4db28 0000010036442810 000000012bc97828 000000012bc96c70 GPR24: 00000100365b1550 0000000000000000 00000100363f3d80 c000000be20d3080 GPR28: c000000bda7eae00 c000000be20db7e8 c000000be20d3778 c000000be20db7e8 [84010.597042] NIP [d00000001ffd7f78] qlt_enable_vha+0x1d0/0x260 [qla2xxx] [84010.597051] LR [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] [84010.597051] Call Trace: [84010.597061] [c000000b5218bb90] [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] (unreliable) [84010.597064] [c000000b5218bc20] [d000000009820b6c] tcm_qla2xxx_tpg_enable_store+0xc4/0x130 [tcm_qla2xxx] [84010.597067] [c000000b5218bcb0] [d0000000185d0e68] configfs_write_file+0xd0/0x190 [configfs] [84010.597072] [c000000b5218bd00] [c0000000003d0edc] __vfs_write+0x3c/0x1e0 [84010.597074] [c000000b5218bd90] [c0000000003d2ea8] vfs_write+0xd8/0x220 [84010.597076] [c000000b5218bde0] [c0000000003d4ddc] SyS_write+0x6c/0x110 [84010.597079] [c000000b5218be30] [c00000000000b188] system_call+0x3c/0x130 [84010.597080] Instruction dump: [84010.597082] 7d0050a8 7d084b78 7d0051ad 40c2fff4 7fa3eb78 4bf73965 60000000 7fa3eb78 [84010.597086] 4bf6dcd9 60000000 2fa30000 419eff40 <0fe00000> 4bffff38 e95f0058 a12a0180 [84010.597090] ---[ end trace e32abaf6e6fee826 ]--- To reproduce: echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging modprobe target_core_mod modprobe tcm_qla2xxx mkdir /sys/kernel/config/target/qla2xxx mkdir /sys/kernel/config/target/qla2xxx/ mkdir /sys/kernel/config/target/qla2xxx//tpgt_1 echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 0 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable SYSTEM START kernel: pid 327:drivers/scsi/qla2xxx/qla_init.c:2174 qla2x00_initialize_adapter(): vha->flags.online 0x0 <...> kernel: pid 327:drivers/scsi/qla2xxx/qla_os.c:3444 qla2x00_probe_one(): vha->flags.online 0x1 echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0 <...> kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6998 qla2x00_restart_isp(): vha->flags.online 0x0 echo 0 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0 <...> kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0 echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0 kernel: -----------[ cut here ]----------- kernel: WARNING: CPU: 1 PID: 1404 at drivers/scsi/qla2xxx/qla_target.c:6654 qlt_enable_vha+0x1e0/0x280 [qla2xxx] The issue happens because no real ISP reset is executed. The qla2x00_abort_isp(scsi_qla_host_t *vha) function expects that vha->flags.online will be not zero for ISP reset procedure. This patch sets vha->flags.online to 1 before calling ->abort_isp() for starting the ISP reset. Link: https://lore.kernel.org/r/1d7b21bf9f7676643239eb3d60eaca7cfa505cf0.camel@yadro.com Reviewed-by: Roman Bolshakov Signed-off-by: Viacheslav Dubeyko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 34d2c84c676fd10eade69d7bec8f4b447b29d968 Author: Kai-Heng Feng Date: Wed May 6 01:34:21 2020 +0800 PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges [ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ] 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for Linux to enable ASPM, but for some undocumented reason, it didn't enable ASPM on links where the downstream component is a PCIe-to-PCI/PCI-X Bridge. Remove this exclusion so we can enable ASPM on these links. The Dell OptiPlex 7080 mentioned in the bugzilla has a TI XIO2001 PCIe-to-PCI Bridge. Enabling ASPM on the link leading to it allows the Intel SoC to enter deeper Package C-states, which is a significant power savings. [bhelgaas: commit log] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Link: https://lore.kernel.org/r/20200505173423.26968-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit 2b0248669ce2c27f4d7baa96a305bbc893d280dc Author: Andrew Murray Date: Fri Oct 4 14:29:41 2019 +0100 PCI: rcar: Fix incorrect programming of OB windows [ Upstream commit 2b9f217433e31d125fb697ca7974d3de3ecc3e92 ] The outbound windows (PCIEPAUR(x), PCIEPALR(x)) describe a mapping between a CPU address (which is determined by the window number 'x') and a programmed PCI address - Thus allowing the controller to translate CPU accesses into PCI accesses. However the existing code incorrectly writes the CPU address - lets fix this by writing the PCI address instead. For memory transactions, existing DT users describe a 1:1 identity mapping and thus this change should have no effect. However the same isn't true for I/O. Link: https://lore.kernel.org/r/20191004132941.6660-1-andrew.murray@arm.com Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver") Tested-by: Marek Vasut Signed-off-by: Andrew Murray Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Vasut Signed-off-by: Sasha Levin commit cd74de676af119f4110be9f828f22da953dd94b0 Author: Kuppuswamy Sathyanarayanan Date: Wed Apr 8 14:40:03 2020 -0700 drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish [ Upstream commit 388bcc6ecc609fca1b4920de7dc3806c98ec535e ] If platform bus driver registration is failed then, accessing platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock) in __platform_driver_probe() without verifying the return value __platform_driver_register() can lead to NULL pointer exception. So check the return value before attempting the spin lock. One such example is below: For a custom usecase, I have intentionally failed the platform bus registration and I expected all the platform device/driver registrations to fail gracefully. But I came across this panic issue. [ 1.331067] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 1.331118] #PF: supervisor write access in kernel mode [ 1.331163] #PF: error_code(0x0002) - not-present page [ 1.331208] PGD 0 P4D 0 [ 1.331233] Oops: 0002 [#1] PREEMPT SMP [ 1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-00049-g670d35fb0144 #165 [ 1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30 [ 1.331588] RSP: 0000:ffffc9000001be70 EFLAGS: 00010246 [ 1.331632] RAX: 0000000000000000 RBX: 00000000000000c8 RCX: 0000000000000001 [ 1.331696] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000000 [ 1.331754] RBP: 00000000ffffffed R08: 0000000000000501 R09: 0000000000000001 [ 1.331817] R10: ffff88817abcc520 R11: 0000000000000670 R12: 00000000ffffffed [ 1.331881] R13: ffffffff82dbc268 R14: ffffffff832f070a R15: 0000000000000000 [ 1.331945] FS: 0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000 [ 1.332008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.332062] CR2: 00000000000000c8 CR3: 000000000681e001 CR4: 00000000003606e0 [ 1.332126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.332189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.332252] Call Trace: [ 1.332281] __platform_driver_probe+0x92/0xee [ 1.332323] ? rtc_dev_init+0x2b/0x2b [ 1.332358] cmos_init+0x37/0x67 [ 1.332396] do_one_initcall+0x7d/0x168 [ 1.332428] kernel_init_freeable+0x16c/0x1c9 [ 1.332473] ? rest_init+0xc0/0xc0 [ 1.332508] kernel_init+0x5/0x100 [ 1.332543] ret_from_fork+0x1f/0x30 [ 1.332579] CR2: 00000000000000c8 [ 1.332616] ---[ end trace 3bd87f12e9010b87 ]--- [ 1.333549] note: swapper/0[1] exited with preempt_count 1 [ 1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 1.333736] Kernel Offset: disabled Note, this can only be triggered if a driver errors out from this call, which should never happen. If it does, the driver needs to be fixed. Signed-off-by: Kuppuswamy Sathyanarayanan Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5d2195b7b6c12f69557aec631cafcabc87b98691 Author: John Stultz Date: Tue Apr 28 18:40:50 2020 +0000 serial: amba-pl011: Make sure we initialize the port.lock spinlock [ Upstream commit 8508f4cba308f785b2fd4b8c38849c117b407297 ] Valentine reported seeing: [ 3.626638] INFO: trying to register non-static key. [ 3.626639] the code is fine but needs lockdep annotation. [ 3.626640] turning off the locking correctness validator. [ 3.626644] CPU: 7 PID: 51 Comm: kworker/7:1 Not tainted 5.7.0-rc2-00115-g8c2e9790f196 #116 [ 3.626646] Hardware name: HiKey960 (DT) [ 3.626656] Workqueue: events deferred_probe_work_func [ 3.632476] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes) [ 3.640220] Call trace: [ 3.640225] dump_backtrace+0x0/0x1b8 [ 3.640227] show_stack+0x20/0x30 [ 3.640230] dump_stack+0xec/0x158 [ 3.640234] register_lock_class+0x598/0x5c0 [ 3.640235] __lock_acquire+0x80/0x16c0 [ 3.640236] lock_acquire+0xf4/0x4a0 [ 3.640241] _raw_spin_lock_irqsave+0x70/0xa8 [ 3.640245] uart_add_one_port+0x388/0x4b8 [ 3.640248] pl011_register_port+0x70/0xf0 [ 3.640250] pl011_probe+0x184/0x1b8 [ 3.640254] amba_probe+0xdc/0x180 [ 3.640256] really_probe+0xe0/0x338 [ 3.640257] driver_probe_device+0x60/0xf8 [ 3.640259] __device_attach_driver+0x8c/0xd0 [ 3.640260] bus_for_each_drv+0x84/0xd8 [ 3.640261] __device_attach+0xe4/0x140 [ 3.640263] device_initial_probe+0x1c/0x28 [ 3.640265] bus_probe_device+0xa4/0xb0 [ 3.640266] deferred_probe_work_func+0x7c/0xb8 [ 3.640269] process_one_work+0x2c0/0x768 [ 3.640271] worker_thread+0x4c/0x498 [ 3.640272] kthread+0x14c/0x158 [ 3.640275] ret_from_fork+0x10/0x1c Which seems to be due to the fact that after allocating the uap structure, nothing initializes the spinlock. Its a little confusing, as uart_port_spin_lock_init() is one place where the lock is supposed to be initialized, but it has an exception for the case where the port is a console. This makes it seem like a deeper fix is needed to properly register the console, but I'm not sure what that entails, and Andy suggested that this approach is less invasive. Thus, this patch resolves the issue by initializing the spinlock in the driver, and resolves the resulting warning. Cc: Andy Shevchenko Cc: Russell King Cc: Jiri Slaby Cc: linux-serial@vger.kernel.org Reported-by: Valentin Schneider Reviewed-by: Andy Shevchenko Signed-off-by: John Stultz Reviewed-and-tested-by: Valentin Schneider Link: https://lore.kernel.org/r/20200428184050.6501-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2025b6fc10dc9e7b86fd7a5631a345e6e7b126bd Author: Russell King Date: Mon Apr 27 19:49:22 2020 +0100 i2c: pxa: fix i2c_pxa_scream_blue_murder() debug output [ Upstream commit 88b73ee7ca4c90baf136ed5a8377fc5a9b73ac08 ] The IRQ log output is supposed to appear on a single line. However, commit 3a2dc1677b60 ("i2c: pxa: Update debug function to dump more info on error") resulted in it being printed one-entry-per-line, which is excessively long. Fixing this is not a trivial matter; using pr_cont() doesn't work as the previous dev_dbg() may not have been compiled in, or may be dynamic. Since the rest of this function output is at error level, and is also debug output, promote this to error level as well to avoid this problem. Reduce the number of always zero prefix digits to save screen real- estate. Signed-off-by: Russell King Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7014edf8c077a0fb87933eb6336ba97c51cf8562 Author: Christophe JAILLET Date: Sat Apr 18 10:16:37 2020 +0200 PCI: v3-semi: Fix a memory leak in v3_pci_probe() error handling paths [ Upstream commit bca718988b9008d0d5f504e2d318178fc84958c1 ] If we fails somewhere in 'v3_pci_probe()', we need to free 'host'. Use the managed version of 'pci_alloc_host_bridge()' to do that easily. The use of managed resources is already widely used in this driver. Link: https://lore.kernel.org/r/20200418081637.1585-1-christophe.jaillet@wanadoo.fr Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver") Signed-off-by: Christophe JAILLET [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Linus Walleij Signed-off-by: Sasha Levin commit a3b8b0a13068e47af7df11c13dde094950bea8b5 Author: Matej Dujava Date: Thu Apr 30 22:09:24 2020 +0200 staging: sm750fb: add missing case while setting FB_VISUAL [ Upstream commit fa90133377f4a7f15a937df6ad55133bb57c5665 ] Switch statement does not contain all cases: 8, 16, 24, 32. This patch will add missing one (24) Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging") Signed-off-by: Matej Dujava Link: https://lore.kernel.org/r/1588277366-19354-2-git-send-email-mdujava@kocurkovo.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8aafbcb3eadd218fe19af00d3a828771bc189e1f Author: Thinh Nguyen Date: Sun Mar 29 16:12:57 2020 -0700 usb: dwc3: gadget: Properly handle failed kick_transfer [ Upstream commit 8d99087c2db863c5fa3a4a1f3cb82b3a493705ca ] If dwc3 fails to issue START_TRANSFER/UPDATE_TRANSFER command, then we should properly end an active transfer and give back all the started requests. However if it's for an isoc endpoint, the failure maybe due to bus-expiry status. In this case, don't give back the requests and wait for the next retry. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 57ac786bae9645c5bce51f3516450601d994ea3b Author: Sudip Mukherjee Date: Fri Apr 24 17:19:44 2020 +0100 thermal/drivers/ti-soc-thermal: Avoid dereferencing ERR_PTR [ Upstream commit 7440f518dad9d861d76c64956641eeddd3586f75 ] On error the function ti_bandgap_get_sensor_data() returns the error code in ERR_PTR() but we only checked if the return value is NULL or not. And, so we can dereference an error code inside ERR_PTR. While at it, convert a check to IS_ERR_OR_NULL. Signed-off-by: Sudip Mukherjee Reviewed-by: Amit Kucheria Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200424161944.6044-1-sudipm.mukherjee@gmail.com Signed-off-by: Sasha Levin commit ea02b848093e254859f2989acbeb078ae02ac3a7 Author: Srinivas Kandagatla Date: Fri Apr 17 10:36:18 2020 +0100 slimbus: ngd: get drvdata from correct device [ Upstream commit b58c663059b484f7ff547d076a34cf6d7a302e56 ] Get drvdata directly from parent instead of ngd dev, as ngd dev can probe defer and previously set drvdata will become null. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200417093618.7929-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 229e16468f7df226c2c2f57018011cf74519ca84 Author: Raghavendra Rao Ananta Date: Mon Apr 27 20:26:01 2020 -0700 tty: hvc: Fix data abort due to race in hvc_open [ Upstream commit e2bd1dcbe1aa34ff5570b3427c530e4332ecf0fe ] Potentially, hvc_open() can be called in parallel when two tasks calls open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add() callback in the function fails, where it sets the tty->driver_data to NULL, the parallel hvc_open() can see this NULL and cause a memory abort. Hence, serialize hvc_open and check if tty->private_data is NULL before proceeding ahead. The issue can be easily reproduced by launching two tasks simultaneously that does nothing but open() and close() on /dev/hvcX. For example: $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 & Signed-off-by: Raghavendra Rao Ananta Link: https://lore.kernel.org/r/20200428032601.22127-1-rananta@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f7199b98f5f7ab4d2cbfaeb4c5a6a0f8afa3d714 Author: Julian Wiedmann Date: Thu Apr 9 09:59:39 2020 +0200 s390/qdio: put thinint indicator after early error [ Upstream commit 75e82bec6b2622c6f455b7a543fb5476a5d0eed7 ] qdio_establish() calls qdio_setup_thinint() via qdio_setup_irq(). If the subsequent qdio_establish_thinint() fails, we miss to put the DSCI again. Thus the DSCI isn't available for re-use. Given enough of such errors, we could end up with having only the shared DSCI available. Merge qdio_setup_thinint() into qdio_establish_thinint(), and deal with such an error internally. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit d3a9803bc7be4e553720367bbbc1f9bd912cc47c Author: Takashi Iwai Date: Fri Apr 24 09:40:16 2020 +0200 ALSA: usb-audio: Fix racy list management in output queue [ Upstream commit 5b6cc38f3f3f37109ce72b60bda215a5f6892c0b ] The linked list entry from FIFO is peeked at queue_pending_output_urbs() but the actual element pop-out is performed outside the spinlock, and it's potentially racy. Do delete the link at the right place inside the spinlock. Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model") Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2d50acd7dbd0682a56968ad9551341d7fc5b6eaf Author: Alexander Tsoy Date: Fri Apr 24 05:24:48 2020 +0300 ALSA: usb-audio: Improve frames size computation [ Upstream commit f0bd62b64016508938df9babe47f65c2c727d25c ] For computation of the the next frame size current value of fs/fps and accumulated fractional parts of fs/fps are used, where values are stored in Q16.16 format. This is quite natural for computing frame size for asynchronous endpoints driven by explicit feedback, since in this case fs/fps is a value provided by the feedback endpoint and it's already in the Q format. If an error is accumulated over time, the device can adjust fs/fps value to prevent buffer overruns/underruns. But for synchronous endpoints the accuracy provided by these computations is not enough. Due to accumulated error the driver periodically produces frames with incorrect size (+/- 1 audio sample). This patch fixes this issue by implementing a different algorithm for frame size computation. It is based on accumulating of the remainders from division fs/fps and it doesn't accumulate errors over time. This new method is enabled for synchronous and adaptive playback endpoints. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f35713ba67d07e974d141d7891cfc5509672c0da Author: Xiyu Yang Date: Thu Apr 23 13:15:40 2020 +0800 staging: gasket: Fix mapping refcnt leak when register/store fails [ Upstream commit e3436ce60cf5f5eaedda2b8c622f69feb97595e2 ] gasket_sysfs_register_store() invokes get_mapping(), which returns a reference of the specified gasket_sysfs_mapping object to "mapping" with increased refcnt. When gasket_sysfs_register_store() returns, local variable "mapping" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of gasket_sysfs_register_store(). When gasket_dev is NULL, the function forgets to decrease the refcnt increased by get_mapping(), causing a refcnt leak. Fix this issue by calling put_mapping() when gasket_dev is NULL. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1587618941-13718-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c42581d2eb3909000b79e2c6c0f450f0f76377c5 Author: Xiyu Yang Date: Thu Apr 23 13:14:55 2020 +0800 staging: gasket: Fix mapping refcnt leak when put attribute fails [ Upstream commit 57a66838e1494cd881b7f4e110ec685736e8e3ca ] gasket_sysfs_put_attr() invokes get_mapping(), which returns a reference of the specified gasket_sysfs_mapping object to "mapping" with increased refcnt. When gasket_sysfs_put_attr() returns, local variable "mapping" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one path of gasket_sysfs_put_attr(). When mapping attribute is unknown, the function forgets to decrease the refcnt increased by get_mapping(), causing a refcnt leak. Fix this issue by calling put_mapping() when put attribute fails due to unknown attribute. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1587618895-13660-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce7d4a0e2b77ed8227478191bbebabe87edf3acc Author: Christoph Hellwig Date: Tue Apr 14 14:31:36 2020 +0200 firmware: qcom_scm: fix bogous abuse of dma-direct internals [ Upstream commit 459b1f86f1cba7de813fbc335df476c111feec22 ] As far as the device is concerned the dma address is the physical address. There is no need to convert it to a physical address, especially not using dma-direct internals that are not available to drivers and which will interact badly with IOMMUs. Last but not least the commit introducing it claimed to just fix a type issue, but actually changed behavior. Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings") Reviewed-by: Bjorn Andersson Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 089e03e18d6577c358df02e04ebe643ecf317586 Author: Jason Yan Date: Fri Apr 17 19:16:04 2020 +0800 pinctrl: rza1: Fix wrong array assignment of rza1l_swio_entries [ Upstream commit 4b4e8e93eccc2abc4209fe226ec89e7fbe9f3c61 ] The rza1l_swio_entries referred to the wrong array rza1h_swio_pins, which was intended to be rza1l_swio_pins. So let's fix it. This is detected by the following gcc warning: drivers/pinctrl/pinctrl-rza1.c:401:35: warning: ‘rza1l_swio_pins’ defined but not used [-Wunused-const-variable=] static const struct rza1_swio_pin rza1l_swio_pins[] = { ^~~~~~~~~~~~~~~ Fixes: 039bc58e73b77723 ("pinctrl: rza1: Add support for RZ/A1L") Reported-by: Hulk Robot Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20200417111604.19143-1-yanaijie@huawei.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit af59f7fdfa38b0da063bd2a1ce626e18d100ea3f Author: Chad Dupuis Date: Thu Apr 16 01:43:13 2020 -0700 scsi: qedf: Fix crash when MFW calls for protocol stats while function is still probing [ Upstream commit ad40f5256095c68dc17c991eb976261d5ea2daaa ] The MFW may make a call to qed and then to qedf for protocol statistics while the function is still probing. If this happens it's possible that some members of the struct qedf_ctx may not be fully initialized which can result in a NULL pointer dereference or general protection fault. To prevent this, add a new flag call QEDF_PROBING and set it when the __qedf_probe() function is active. Then in the qedf_get_protocol_tlv_data() function we can check if the function is still probing and return immediantely before any uninitialized structures can be touched. Link: https://lore.kernel.org/r/20200416084314.18851-9-skashyap@marvell.com Signed-off-by: Chad Dupuis Signed-off-by: Saurav Kashyap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e81df5b30ef1fcb506c52daf0352d2f3af54a507 Author: Andy Shevchenko Date: Wed Apr 15 17:15:21 2020 +0300 gpio: dwapb: Append MODULE_ALIAS for platform driver [ Upstream commit c58220cba2e03618659fa7d5dfae31f5ad4ae9d0 ] The commit 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") introduced a use of the platform driver but missed to add the following line to it: MODULE_ALIAS("platform:gpio-dwapb"); Add this to get driver loaded automatically if platform device is registered. Fixes: 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") Signed-off-by: Andy Shevchenko Tested-by: Serge Semin Reviewed-by: Serge Semin Link: https://lore.kernel.org/r/20200415141534.31240-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 98ea71efec551e71d99ee173ab30647c624e10f1 Author: Vincent Stehlé Date: Sat Apr 11 19:48:43 2020 +0200 ARM: dts: sun8i-h2-plus-bananapi-m2-zero: Fix led polarity [ Upstream commit 34b6826df7462c541752cf8b1de2691b26d78ae0 ] The PWR-LED on the bananapi m2 zero board is on when gpio PL10 is low. This has been verified on a board and in the schematics [1]. [1]: http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO#Documents Fixes: 8b8061fcbfae ("ARM: dts: sun8i: h2+: add support for Banana Pi M2 Zero board") Signed-off-by: Vincent Stehlé Cc: Icenowy Zheng Cc: Maxime Ripard Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 2f9687727ca5e356bbfc00fac4f9c0c064598c7b Author: Nilesh Javali Date: Tue Apr 7 23:43:30 2020 -0700 scsi: qedi: Do not flush offload work if ARP not resolved [ Upstream commit 927527aea0e2a9c1d336c7d33f77f1911481d008 ] For an unreachable target, offload_work is not initialized and the endpoint state is set to OFLDCONN_NONE. This results in a WARN_ON due to the check of the work function field being set to zero. ------------[ cut here ]------------ WARNING: CPU: 24 PID: 18587 at ../kernel/workqueue.c:3037 __flush_work+0x1c1/0x1d0 : Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 02/01/2020 RIP: 0010:__flush_work+0x1c1/0x1d0 Code: ba 6d 00 03 80 c9 f0 eb b6 48 c7 c7 20 ee 6c a4 e8 52 d3 04 00 0f 0b 31 c0 e9 d1 fe ff ff 48 c7 c7 20 ee 6c a4 e8 3d d3 04 00 <0f> 0b 31 c0 e9 bc fe ff ff e8 11 f3 f 00 31 f6 RSP: 0018:ffffac5a8cd47a80 EFLAGS: 00010282 RAX: 0000000000000024 RBX: ffff98d68c1fcaf0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff98ce9fd99898 RDI: ffff98ce9fd99898 RBP: ffff98d68c1fcbc0 R08: 00000000000006fa R09: 0000000000000001 R10: ffffac5a8cd47b50 R11: 0000000000000001 R12: 0000000000000000 R13: 000000000000489b R14: ffff98d68c1fc800 R15: ffff98d692132c00 FS: 00007f65f7f62280(0000) GS:ffff98ce9fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd2435e880 CR3: 0000000809334003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? class_create_release+0x40/0x40 ? klist_put+0x2c/0x80 qedi_ep_disconnect+0xdd/0x400 [qedi] iscsi_if_ep_disconnect.isra.20+0x59/0x70 [scsi_transport_iscsi] iscsi_if_rx+0x129b/0x1670 [scsi_transport_iscsi] ? __netlink_lookup+0xe7/0x160 netlink_unicast+0x21d/0x300 netlink_sendmsg+0x30f/0x430 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1e2/0x240 ? copy_msghdr_from_user+0xd9/0x160 ___sys_sendmsg+0x88/0xd0 ? ___sys_recvmsg+0xa2/0xe0 ? hrtimer_try_to_cancel+0x25/0x100 ? do_nanosleep+0x9c/0x170 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 do_syscall_64+0x60/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f65f6f16107 Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 aa d2 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 8 0 00 00 00 00 53 48 89 f3 48 RSP: 002b:00007ffd24367ca8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a7aeaaf110 RCX: 00007f65f6f16107 RDX: 0000000000000000 RSI: 00007ffd24367cc0 RDI: 0000000000000003 RBP: 0000000000000070 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000075c R11: 0000000000000246 R12: 00007ffd24367cc0 R13: 000055a7ae560008 R14: 00007ffd24367db0 R15: 0000000000000000 ---[ end trace 54f499c05d41f8bb ]--- Only flush if the connection endpoint state if different from OFLDCONN_NONE. [mkp: clarified commit desc] Link: https://lore.kernel.org/r/20200408064332.19377-5-mrangankar@marvell.com Reviewed-by: Lee Duncan Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 46d29305c78d6f055a827c51456958d04184da98 Author: Hsin-Yi Wang Date: Mon Feb 10 14:35:22 2020 +0800 arm64: dts: mt8173: fix unit name warnings [ Upstream commit 72b29215aced394d01ca25e432963b619daa0098 ] Fixing several unit name warnings: Warning (unit_address_vs_reg): /oscillator@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /oscillator@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /oscillator@2: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/cpu_crit@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /reserved-memory/vpu_dma_mem_region: node has a reg or ranges property, but no unit name Warning (simple_bus_reg): /soc/pinctrl@10005000: simple-bus unit address format error, expected "1000b000" Warning (simple_bus_reg): /soc/interrupt-controller@10220000: simple-bus unit address format error, expected "10221000" Signed-off-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20200210063523.133333-4-hsinyi@chromium.org [mb: drop fixes for '_' in property name] Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit d485ba3c8f98272cc324f149c1c5f613efa7c203 Author: Chen Zhou Date: Wed Apr 1 11:00:17 2020 +0800 staging: greybus: fix a missing-check bug in gb_lights_light_config() [ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou Acked-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d85760a6b0f9a970b5869116c69dddfebcea2500 Author: Hans de Goede Date: Tue Mar 17 14:08:40 2020 +0100 x86/purgatory: Disable various profiling and sanitizing options [ Upstream commit e2ac07c06058ae2d58b45bbf2a2a352771d76fcb ] Since the purgatory is a special stand-alone binary, various profiling and sanitizing options must be disabled. Having these options enabled typically will cause dependencies on various special symbols exported by special libs / stubs used by these frameworks. Since the purgatory is special, it is not linked against these stubs causing missing symbols in the purgatory if these options are not disabled. Sync the set of disabled profiling and sanitizing options with that from drivers/firmware/efi/libstub/Makefile, adding -DDISABLE_BRANCH_PROFILING to the CFLAGS and setting: GCOV_PROFILE := n UBSAN_SANITIZE := n This fixes broken references to ftrace_likely_update() when CONFIG_TRACE_BRANCH_PROFILING is enabled and to __gcov_init() and __gcov_exit() when CONFIG_GCOV_KERNEL is enabled. Signed-off-by: Hans de Goede Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200317130841.290418-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 3cc2aec68e7db2df9f053d4548c57e3bf1e3ebf9 Author: John Johansen Date: Wed Sep 25 08:02:48 2019 -0700 apparmor: fix nnp subset test for unconfined [ Upstream commit 3ed4aaa94fc07db3cd0c91be95e3e1b9782a2710 ] The subset test is not taking into account the unconfined exception which will cause profile transitions in the stacked confinement case to fail when no_new_privs is applied. This fixes a regression introduced in the fix for https://bugs.launchpad.net/bugs/1839037 BugLink: https://bugs.launchpad.net/bugs/1844186 Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 890775dc6a96e39e1e29836af579d9b269e34ce4 Author: Tyrel Datwyler Date: Wed Jun 3 15:36:32 2020 -0500 scsi: ibmvscsi: Don't send host info in adapter info MAD after LPM [ Upstream commit 4919b33b63c8b69d8dcf2b867431d0e3b6dc6d28 ] The adapter info MAD is used to send the client info and receive the host info as a response. A persistent buffer is used and as such the client info is overwritten after the response. During the course of a normal adapter reset the client info is refreshed in the buffer in preparation for sending the adapter info MAD. However, in the special case of LPM where we reenable the CRQ instead of a full CRQ teardown and reset we fail to refresh the client info in the adapter info buffer. As a result, after Live Partition Migration (LPM) we erroneously report the host's info as our own. [mkp: typos] Link: https://lore.kernel.org/r/20200603203632.18426-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5d41879d2ea51b1dd37798d5fdb597d55359caed Author: Simon Arlott Date: Sat May 30 18:59:44 2020 +0100 scsi: sr: Fix sr_probe() missing deallocate of device minor [ Upstream commit 6555781b3fdec5e94e6914511496144241df7dee ] If the cdrom fails to be registered then the device minor should be deallocated. Link: https://lore.kernel.org/r/072dac4b-8402-4de8-36bd-47e7588969cd@0882a8b5-c6c3-11e9-b005-00805fc181fe Signed-off-by: Simon Arlott Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e6fe402ebdad720de8d533b9c78de2f1877d7647 Author: Pavel Machek (CIP) Date: Sat Jun 6 17:31:03 2020 +0200 ASoC: meson: add missing free_irq() in error path [ Upstream commit 3b8a299a58b2afce464ae11324b59dcf0f1d10a7 ] free_irq() is missing in case of error, fix that. Signed-off-by: Pavel Machek (CIP) Reviewed-by: Jerome Brunet Link: https://lore.kernel.org/r/20200606153103.GA17905@amd Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 70fa5992352642a30e0e871f3343fa3c393c91c9 Author: Mauricio Faria de Oliveira Date: Tue Jun 2 18:15:16 2020 -0300 apparmor: check/put label on apparmor_sk_clone_security() [ Upstream commit 3b646abc5bc6c0df649daea4c2c976bd4d47e4c8 ] Currently apparmor_sk_clone_security() does not check for existing label/peer in the 'new' struct sock; it just overwrites it, if any (with another reference to the label of the source sock.) static void apparmor_sk_clone_security(const struct sock *sk, struct sock *newsk) { struct aa_sk_ctx *ctx = SK_CTX(sk); struct aa_sk_ctx *new = SK_CTX(newsk); new->label = aa_get_label(ctx->label); new->peer = aa_get_label(ctx->peer); } This might leak label references, which might overflow under load. Thus, check for and put labels, to prevent such errors. Note this is similarly done on: static int apparmor_socket_post_create(struct socket *sock, ...) ... if (sock->sk) { struct aa_sk_ctx *ctx = SK_CTX(sock->sk); aa_put_label(ctx->label); ctx->label = aa_get_label(label); } ... Context: ------- The label reference count leak is observed if apparmor_sock_graft() is called previously: this sets the 'ctx->label' field by getting a reference to the current label (later overwritten, without put.) static void apparmor_sock_graft(struct sock *sk, ...) { struct aa_sk_ctx *ctx = SK_CTX(sk); if (!ctx->label) ctx->label = aa_get_current_label(); } And that is the case on crypto/af_alg.c:af_alg_accept(): int af_alg_accept(struct sock *sk, struct socket *newsock, ...) ... struct sock *sk2; ... sk2 = sk_alloc(...); ... security_sock_graft(sk2, newsock); security_sk_clone(sk, sk2); ... Apparently both calls are done on their own right, especially for other LSMs, being introduced in 2010/2014, before apparmor socket mediation in 2017 (see commits [1,2,3,4]). So, it looks OK there! Let's fix the reference leak in apparmor. Test-case: --------- Exercise that code path enough to overflow label reference count. $ cat aa-refcnt-af_alg.c #include #include #include #include #include int main() { int sockfd; struct sockaddr_alg sa; /* Setup the crypto API socket */ sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0); if (sockfd < 0) { perror("socket"); return 1; } memset(&sa, 0, sizeof(sa)); sa.salg_family = AF_ALG; strcpy((char *) sa.salg_type, "rng"); strcpy((char *) sa.salg_name, "stdrng"); if (bind(sockfd, (struct sockaddr *) &sa, sizeof(sa)) < 0) { perror("bind"); return 1; } /* Accept a "connection" and close it; repeat. */ while (!close(accept(sockfd, NULL, 0))); return 0; } $ gcc -o aa-refcnt-af_alg aa-refcnt-af_alg.c $ ./aa-refcnt-af_alg [ 9928.475953] refcount_t overflow at apparmor_sk_clone_security+0x37/0x70 in aa-refcnt-af_alg[1322], uid/euid: 1000/1000 ... [ 9928.507443] RIP: 0010:apparmor_sk_clone_security+0x37/0x70 ... [ 9928.514286] security_sk_clone+0x33/0x50 [ 9928.514807] af_alg_accept+0x81/0x1c0 [af_alg] [ 9928.516091] alg_accept+0x15/0x20 [af_alg] [ 9928.516682] SYSC_accept4+0xff/0x210 [ 9928.519609] SyS_accept+0x10/0x20 [ 9928.520190] do_syscall_64+0x73/0x130 [ 9928.520808] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Note that other messages may be seen, not just overflow, depending on the value being incremented by kref_get(); on another run: [ 7273.182666] refcount_t: saturated; leaking memory. ... [ 7273.185789] refcount_t: underflow; use-after-free. Kprobes: ------- Using kprobe events to monitor sk -> sk_security -> label -> count (kref): Original v5.7 (one reference leak every iteration) ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd2 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd4 ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd3 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd5 ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd4 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd6 Patched v5.7 (zero reference leak per iteration) ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 Commits: ------- [1] commit 507cad355fc9 ("crypto: af_alg - Make sure sk_security is initialized on accept()ed sockets") [2] commit 4c63f83c2c2e ("crypto: af_alg - properly label AF_ALG socket") [3] commit 2acce6aa9f65 ("Networking") a.k.a ("crypto: af_alg - Avoid sock_graft call warning) [4] commit 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Reported-by: Brian Moyles Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 86396a494e79f32f05da31d189db74fd0c228000 Author: John Johansen Date: Fri Jun 5 18:12:21 2020 -0700 apparmor: fix introspection of of task mode for unconfined tasks [ Upstream commit dd2569fbb053719f7df7ef8fdbb45cf47156a701 ] Fix two issues with introspecting the task mode. 1. If a task is attached to a unconfined profile that is not the ns->unconfined profile then. Mode the mode is always reported as - $ ps -Z LABEL PID TTY TIME CMD unconfined 1287 pts/0 00:00:01 bash test (-) 1892 pts/0 00:00:00 ps instead of the correct value of (unconfined) as shown below $ ps -Z LABEL PID TTY TIME CMD unconfined 2483 pts/0 00:00:01 bash test (unconfined) 3591 pts/0 00:00:00 ps 2. if a task is confined by a stack of profiles that are unconfined the output of label mode is again the incorrect value of (-) like above, instead of (unconfined). This is because the visibile profile count increment is skipped by the special casing of unconfined. Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit e71c1098a9a2ff0be7210c3b5138902c511e2358 Author: ashimida Date: Tue Jun 2 15:45:17 2020 +0800 mksysmap: Fix the mismatch of '.L' symbols in System.map [ Upstream commit 72d24accf02add25e08733f0ecc93cf10fcbd88c ] When System.map was generated, the kernel used mksysmap to filter the kernel symbols, but all the symbols with the second letter 'L' in the kernel were filtered out, not just the symbols starting with 'dot + L'. For example: ashimida@ubuntu:~/linux$ cat System.map |grep ' .L' ashimida@ubuntu:~/linux$ nm -n vmlinux |grep ' .L' ffff0000088028e0 t bLength_show ...... ffff0000092e0408 b PLLP_OUTC_lock ffff0000092e0410 b PLLP_OUTA_lock The original intent should be to filter out all local symbols starting with '.L', so the dot should be escaped. Fixes: 00902e984732 ("mksysmap: Add h8300 local symbol pattern") Signed-off-by: ashimida Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit f6328a0b31ee9335274d37ecc30241d7ac152b02 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:28 2019 -0700 NTB: Fix the default port and peer numbers for legacy drivers [ Upstream commit fc8b086d9dbd57458d136c4fa70ee26f832c3a2e ] When the commit adding ntb_default_port_number() and ntb_default_peer_port_number() entered the kernel there was no users of it so it was impossible to tell what the API needed. When a user finally landed a year later (ntb_pingpong) there were more NTB topologies were created and no consideration was considered to how other drivers had changed. Now that there is a user it can be fixed to provide a sensible default for the legacy drivers that do not implement ntb_{peer_}port_number(). Seeing ntb_pingpong doesn't check error codes returning EINVAL was also not sensible. Patches for ntb_pingpong and ntb_perf follow (which are broken otherwise) to support hardware that doesn't have port numbers. This is important not only to not break support with existing drivers but for the cross link topology which, due to its perfect symmetry, cannot assign unique port numbers to each side. Fixes: 1e5301196a88 ("NTB: Add indexed ports NTB API") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit ce8280b1818a0ebe95d9ba3a425769dffcea9801 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:29 2019 -0700 NTB: ntb_pingpong: Choose doorbells based on port number [ Upstream commit ca93c45755da98302c93abdd788fc09113baf9e0 ] This commit fixes pingpong support for existing drivers that do not implement ntb_default_port_number() and ntb_default_peer_port_number(). This is required for hardware (like the crosslink topology of switchtec) which cannot assign reasonable port numbers to each port due to its perfect symmetry. Instead of picking the doorbell to use based on the the index of the peer, we use the peer's port number. This is a bit clearer and easier to understand. Fixes: c7aeb0afdcc2 ("NTB: ntb_pp: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 2c75b5c33d407833541e93ac1b6e7e312d07be3c Author: Wang Hai Date: Thu Jun 4 20:18:51 2020 +0800 yam: fix possible memory leak in yam_init_driver [ Upstream commit 98749b7188affbf2900c2aab704a8853901d1139 ] If register_netdev(dev) fails, free_netdev(dev) needs to be called, otherwise a memory leak will occur. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 97c36deb218cc1d166a92a766130a05b11194b0b Author: Navid Emamdoost Date: Mon Jun 1 02:11:16 2020 -0500 pwm: img: Call pm_runtime_put() in pm_runtime_get_sync() failed case [ Upstream commit ca162ce98110b98e7d97b7157328d34dcfdd40a9 ] Even in failed case of pm_runtime_get_sync(), the usage_count is incremented. In order to keep the usage_count with correct value call appropriate pm_runtime_put(). Signed-off-by: Navid Emamdoost Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 78c131f604de76306d8b150bc526889ca1710eee Author: Pingfan Liu Date: Wed Apr 1 22:00:44 2020 +0800 powerpc/crashkernel: Take "mem=" option into account [ Upstream commit be5470e0c285a68dc3afdea965032f5ddc8269d7 ] 'mem=" option is an easy way to put high pressure on memory during some test. Hence after applying the memory limit, instead of total mem, the actual usable memory should be considered when reserving mem for crashkernel. Otherwise the boot up may experience OOM issue. E.g. it would reserve 4G prior to the change and 512M afterward, if passing crashkernel="2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G", and mem=5G on a 256G machine. This issue is powerpc specific because it puts higher priority on fadump and kdump reservation than on "mem=". Referring the following code: if (fadump_reserve_mem() == 0) reserve_crashkernel(); ... /* Ensure that total memory size is page-aligned. */ limit = ALIGN(memory_limit ?: memblock_phys_mem_size(), PAGE_SIZE); memblock_enforce_memory_limit(limit); While on other arches, the effect of "mem=" takes a higher priority and pass through memblock_phys_mem_size() before calling reserve_crashkernel(). Signed-off-by: Pingfan Liu Reviewed-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1585749644-4148-1-git-send-email-kernelfans@gmail.com Signed-off-by: Sasha Levin commit 8861d95c653c4150ad92505e7d287ba23bf69d15 Author: Jon Derrick Date: Wed May 27 23:02:39 2020 -0400 PCI: vmd: Filter resource type bits from shadow register [ Upstream commit 3e5095eebe015d5a4d566aa5e03c8621add5f0a7 ] Versions of VMD with the Host Physical Address shadow register use this register to calculate the bus address offset needed to do guest passthrough of the domain. This register shadows the Host Physical Address registers including the resource type bits. After calculating the offset, the extra resource type bits lead to the VMD resources being over-provisioned at the front and under-provisioned at the back. Example: pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit] Expected: pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit] If other devices are mapped in the over-provisioned front, it could lead to resource conflict issues with VMD or those devices. Link: https://lore.kernel.org/r/20200528030240.16024-3-jonathan.derrick@intel.com Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes") Signed-off-by: Jon Derrick Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 22c721560ef24003bcb9c3d9c358841dcfa4e212 Author: Xiyu Yang Date: Mon May 25 22:15:41 2020 +0800 nfsd: Fix svc_xprt refcnt leak when setup callback client failed [ Upstream commit a4abc6b12eb1f7a533c2e7484cfa555454ff0977 ] nfsd4_process_cb_update() invokes svc_xprt_get(), which increases the refcount of the "c->cn_xprt". The reference counting issue happens in one exception handling path of nfsd4_process_cb_update(). When setup callback client failed, the function forgets to decrease the refcnt increased by svc_xprt_get(), causing a refcnt leak. Fix this issue by calling svc_xprt_put() when setup callback client failed. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 4b2f2a38ede683b1d19a352639776238a907d920 Author: Kajol Jain Date: Mon May 25 16:13:03 2020 +0530 powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run [ Upstream commit b4ac18eead28611ff470d0f47a35c4e0ac080d9c ] Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter values")' added to print _change_ in the counter value rather then raw value for 24x7 counters. Incase of transactions, the event count is set to 0 at the beginning of the transaction. It also sets the event's prev_count to the raw value at the time of initialization. Because of setting event count to 0, we are seeing some weird behaviour, whenever we run multiple 24x7 events at a time. For example: command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/, hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}" -C 0 -I 1000 sleep 100 1.000121704 120 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 1.000121704 5 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 2.000357733 8 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 2.000357733 10 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.000641884 56 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 4.000641884 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 5.000791887 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ Getting these large values in case we do -I. As we are setting event_count to 0, for interval case, overall event_count is not coming in incremental order. As we may can get new delta lesser then previous count. Because of which when we print intervals, we are getting negative value which create these large values. This patch removes part where we set event_count to 0 in function 'h_24x7_event_read'. There won't be much impact as we do set event->hw.prev_count to the raw value at the time of initialization to print change value. With this patch In power9 platform command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/, hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}" -C 0 -I 1000 sleep 100 1.000117685 93 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 1.000117685 1 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 2.000349331 98 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 2.000349331 2 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 3.000495900 131 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 3.000495900 4 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.000645920 204 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 4.000645920 61 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.284169997 22 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ Suggested-by: Sukadev Bhattiprolu Signed-off-by: Kajol Jain Tested-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200525104308.9814-2-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit f59c4d14155b7b4dfb4605f32da2659798becaaf Author: Alain Volmat Date: Sun Mar 22 15:07:40 2020 +0100 clk: clk-flexgen: fix clock-critical handling [ Upstream commit a403bbab1a73d798728d76931cab3ff0399b9560 ] Fixes an issue leading to having all clocks following a critical clocks marked as well as criticals. Fixes: fa6415affe20 ("clk: st: clk-flexgen: Detect critical clocks") Signed-off-by: Alain Volmat Link: https://lkml.kernel.org/r/20200322140740.3970-1-avolmat@me.com Reviewed-by: Patrice Chotard Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b3cad8afd5770d7ac8fd2b1c724da26be56d336c Author: Xiyu Yang Date: Mon May 25 22:16:24 2020 +0800 scsi: lpfc: Fix lpfc_nodelist leak when processing unsolicited event [ Upstream commit 7217e6e694da3aae6d17db8a7f7460c8d4817ebf ] In order to create or activate a new node, lpfc_els_unsol_buffer() invokes lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), all of them will return a reference of the specified lpfc_nodelist object to "ndlp" with increased refcnt. When lpfc_els_unsol_buffer() returns, local variable "ndlp" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of lpfc_els_unsol_buffer(). When "ndlp" in DEV_LOSS, the function forgets to decrease the refcnt increased by lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), causing a refcnt leak. Fix this issue by calling lpfc_nlp_put() when "ndlp" in DEV_LOSS. Link: https://lore.kernel.org/r/1590416184-52592-1-git-send-email-xiyuyang19@fudan.edu.cn Reviewed-by: Daniel Wagner Reviewed-by: James Smart Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e3f5b9a3f4e4e69a0f6e56f13e2c404ffc70431f Author: Marek Szyprowski Date: Mon Apr 27 09:48:29 2020 +0200 mfd: wm8994: Fix driver operation if loaded as modules [ Upstream commit d4f9b5428b53dd67f49ee8deed8d4366ed6b1933 ] WM8994 chip has built-in regulators, which might be used for chip operation. They are controlled by a separate wm8994-regulator driver, which should be loaded before this driver calls regulator_get(), because that driver also provides consumer-supply mapping for the them. If that driver is not yet loaded, regulator core substitute them with dummy regulator, what breaks chip operation, because the built-in regulators are never enabled. Fix this by annotating this driver with MODULE_SOFTDEP() "pre" dependency to "wm8994_regulator" module. Signed-off-by: Marek Szyprowski Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3bb97b7db003034728a5cc22f19f3ccb49b817c3 Author: Andy Shevchenko Date: Tue May 19 16:12:30 2020 +0300 gpio: dwapb: Call acpi_gpiochip_free_interrupts() on GPIO chip de-registration [ Upstream commit 494a94e38dcf62543a32a4424d646ff80b4b28bd ] Add missed acpi_gpiochip_free_interrupts() call when unregistering ports. While at it, drop extra check to call acpi_gpiochip_request_interrupts(). There is no need to have an additional check to call acpi_gpiochip_request_interrupts(). Even without any interrupts available the registered ACPI Event handlers can be useful for debugging purposes. Fixes: e6cb3486f5a1 ("gpio: dwapb: add gpio-signaled acpi event support") Signed-off-by: Andy Shevchenko Tested-by: Serge Semin Acked-by: Serge Semin Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1bcf97491242ca0a1cefbd50509198ea4f5c4a9a Author: Christophe JAILLET Date: Sat Apr 18 09:07:51 2020 +0200 m68k/PCI: Fix a memory leak in an error handling path [ Upstream commit c3f4ec050f56eeab7c1f290321f9b762c95bd332 ] If 'ioremap' fails, we must free 'bridge', as done in other error handling path bellow. Fixes: 19cc4c843f40 ("m68k/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: Christophe JAILLET Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit e70fd099044460542d790b272f73da0ad7bb97d9 Author: Aharon Landau Date: Wed May 13 12:55:50 2020 +0300 RDMA/mlx5: Add init2init as a modify command [ Upstream commit 819f7427bafd494ef7ca4942ec6322db20722d7b ] Missing INIT2INIT entry in the list of modify commands caused DEVX applications to be unable to modify_qp for this transition state. Add the MLX5_CMD_OP_INIT2INIT_QP opcode to the list of allowed DEVX opcodes. Fixes: e662e14d801b ("IB/mlx5: Add DEVX support for modify and query commands") Link: https://lore.kernel.org/r/20200513095550.211345-1-leon@kernel.org Signed-off-by: Aharon Landau Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 78914f1689701e997a17891644117539d6c103cf Author: Qian Cai Date: Sun May 10 12:16:56 2020 -0400 vfio/pci: fix memory leaks in alloc_perm_bits() [ Upstream commit 3e63b94b6274324ff2e7d8615df31586de827c4e ] vfio_pci_disable() calls vfio_config_free() but forgets to call free_perm_bits() resulting in memory leaks, unreferenced object 0xc000000c4db2dee0 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 00 ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<00000000a6a4552d>] alloc_perm_bits+0x58/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] init_pci_cap_msi_perm at drivers/vfio/pci/vfio_pci_config.c:1125 (inlined by) vfio_msi_cap_len at drivers/vfio/pci/vfio_pci_config.c:1180 (inlined by) vfio_cap_len at drivers/vfio/pci/vfio_pci_config.c:1241 (inlined by) vfio_cap_init at drivers/vfio/pci/vfio_pci_config.c:1468 (inlined by) vfio_config_init at drivers/vfio/pci/vfio_pci_config.c:1707 [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 unreferenced object 0xc000000c4db2e330 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 ff ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<000000004c71914f>] alloc_perm_bits+0x44/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver") Signed-off-by: Qian Cai [aw: rolled in follow-up patch] Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 302f0c5eeeddb10b097233a1e2d997c74b7f91de Author: Emmanuel Nicolet Date: Sat May 9 18:58:32 2020 +0000 ps3disk: use the default segment boundary [ Upstream commit 720bc316690bd27dea9d71510b50f0cd698ffc32 ] Since commit dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count"), the kernel will bug_on on the PS3 because bio_split() is called with sectors == 0: kernel BUG at block/bio.c:1853! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3 Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \ ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1 NIP: c00000000027d0d0 LR: c00000000027d0b0 CTR: 0000000000000000 REGS: c00000000135ae90 TRAP: 0700 Not tainted (5.3.0-rc4) MSR: 8000000000028032 CR: 44008240 XER: 20000000 IRQMASK: 0 GPR00: c000000000289368 c00000000135b120 c00000000084a500 c000000004ff8300 GPR04: 0000000000000c00 c000000004c905e0 c000000004c905e0 000000000000ffff GPR08: 0000000000000000 0000000000000001 0000000000000000 000000000000ffff GPR12: 0000000000000000 c0000000008ef000 000000000000003e 0000000000080001 GPR16: 0000000000000100 000000000000ffff 0000000000000000 0000000000000004 GPR20: c00000000062fd7e 0000000000000001 000000000000ffff 0000000000000080 GPR24: c000000000781788 c00000000135b350 0000000000000080 c000000004c905e0 GPR28: c00000000135b348 c000000004ff8300 0000000000000000 c000000004c90000 NIP [c00000000027d0d0] .bio_split+0x28/0xac LR [c00000000027d0b0] .bio_split+0x8/0xac Call Trace: [c00000000135b120] [c00000000027d130] .bio_split+0x88/0xac (unreliable) [c00000000135b1b0] [c000000000289368] .__blk_queue_split+0x11c/0x53c [c00000000135b2d0] [c00000000028f614] .blk_mq_make_request+0x80/0x7d4 [c00000000135b3d0] [c000000000283a8c] .generic_make_request+0x118/0x294 [c00000000135b4b0] [c000000000283d34] .submit_bio+0x12c/0x174 [c00000000135b580] [c000000000205a44] .mpage_bio_submit+0x3c/0x4c [c00000000135b600] [c000000000206184] .mpage_readpages+0xa4/0x184 [c00000000135b750] [c0000000001ff8fc] .blkdev_readpages+0x24/0x38 [c00000000135b7c0] [c0000000001589f0] .read_pages+0x6c/0x1a8 [c00000000135b8b0] [c000000000158c74] .__do_page_cache_readahead+0x118/0x184 [c00000000135b9b0] [c0000000001591a8] .force_page_cache_readahead+0xe4/0xe8 [c00000000135ba50] [c00000000014fc24] .generic_file_read_iter+0x1d8/0x830 [c00000000135bb50] [c0000000001ffadc] .blkdev_read_iter+0x40/0x5c [c00000000135bbc0] [c0000000001b9e00] .new_sync_read+0x144/0x1a0 [c00000000135bcd0] [c0000000001bc454] .vfs_read+0xa0/0x124 [c00000000135bd70] [c0000000001bc7a4] .ksys_read+0x70/0xd8 [c00000000135be20] [c00000000000a524] system_call+0x5c/0x70 Instruction dump: 7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0 7c7d1b78 79290fe0 7cc53378 69290001 <0b090000> 81230028 7bca0020 7929ba62 [ end trace 313fec760f30aa1f ]--- The problem originates from setting the segment boundary of the request queue to -1UL. This makes get_max_segment_size() return zero when offset is zero, whatever the max segment size. The test with BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows to zero in the return statement. Not setting the segment boundary and using the default value (BLK_SEG_BOUNDARY_MASK) fixes the problem. Signed-off-by: Emmanuel Nicolet Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin commit bee54028cec2202183ecc5a2418fd763d0147be0 Author: Pali Rohár Date: Thu Apr 30 10:06:15 2020 +0200 PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register [ Upstream commit 90c6cb4a355e7befcb557d217d1d8b8bd5875a05 ] Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense. In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register. Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory. Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect. Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly. Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.: https://bugzilla.kernel.org/show_bug.cgi?id=196339 If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards. Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin commit 49306a3e9dd05f5c60042aff9628b5ebc570cdbf Author: Martin Wilck Date: Mon Apr 20 22:29:09 2020 +0200 dm mpath: switch paths in dm_blk_ioctl() code path [ Upstream commit 2361ae595352dec015d14292f1b539242d8446d6 ] SCSI LUN passthrough code such as qemu's "scsi-block" device model pass every IO to the host via SG_IO ioctls. Currently, dm-multipath calls choose_pgpath() only in the block IO code path, not in the ioctl code path (unless current_pgpath is NULL). This has the effect that no path switching and thus no load balancing is done for SCSI-passthrough IO, unless the active path fails. Fix this by using the same logic in multipath_prepare_ioctl() as in multipath_clone_and_map(). Note: The allegedly best path selection algorithm, service-time, still wouldn't work perfectly, because the io size of the current request is always set to 0. Changing that for the IO passthrough case would require the ioctl cmd and arg to be passed to dm's prepare_ioctl() method. Signed-off-by: Martin Wilck Reviewed-by: Hannes Reinecke Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 0eeaf62981ecc79e8395ca8caa1570eaf3a12257 Author: Serge Semin Date: Thu May 7 02:31:32 2020 +0300 serial: 8250: Fix max baud limit in generic 8250 port [ Upstream commit 7b668c064ec33f3d687c3a413d05e355172e6c92 ] Standard 8250 UART ports are designed in a way so they can communicate with baud rates up to 1/16 of a reference frequency. It's expected from most of the currently supported UART controllers. That's why the former version of serial8250_get_baud_rate() method called uart_get_baud_rate() with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX) and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like it was suggested in commit ("serial: 8250_mtk: support big baud rate."), caused acceptance of bauds, which was higher than the normal UART controllers actually supported. As a result if some user-space program requested to set a baud greater than (uartclk / 16) it would have been permitted without truncation, but then serial8250_get_divisor(baud) (which calls uart_get_divisor() to get the reference clock divisor) would have returned a zero divisor. Setting zero divisor will cause an unpredictable effect varying from chip to chip. In case of DW APB UART the communications just stop. Lets fix this problem by getting back the limitation of (uartclk + tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek 8250 UART ports driver developer shouldn't have touched it in the first place notably seeing he already provided a custom version of set_termios() callback in that glue-driver which took into account the extended baud rate values and accordingly updated the standard and vendor-specific divisor latch registers anyway. Fixes: 81bb549fdf14 ("serial: 8250_mtk: support big baud rate.") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Long Cheng Cc: Andy Shevchenko Cc: Maxime Ripard Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Cc: linux-mips@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://lore.kernel.org/r/20200506233136.11842-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 045198546b912d99b39a55337921c49d02af4232 Author: Oliver Neukum Date: Thu May 7 10:58:06 2020 +0200 usblp: poison URBs upon disconnect [ Upstream commit 296a193b06120aa6ae7cf5c0d7b5e5b55968026e ] syzkaller reported an URB that should have been killed to be active. We do not understand it, but this should fix the issue if it is real. Signed-off-by: Oliver Neukum Reported-by: syzbot+be5b5f86a162a6c281e6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200507085806.5793-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aba4a5072debde62c87cd13f68f878de835057ea Author: Marek Szyprowski Date: Wed May 6 15:26:58 2020 +0200 clk: samsung: Mark top ISP and CAM clocks on Exynos542x as critical [ Upstream commit e47bd937e602bb4379546095d1bd0b9871fa60c2 ] The TOP 'aclk*_isp', 'aclk550_cam', 'gscl_wa' and 'gscl_wb' clocks must be kept enabled all the time to allow proper access to power management control for the ISP and CAM power domains. The last two clocks, although related to GScaler device and GSCL power domain, provides also the I_WRAP_CLK signal to MIPI CSIS0/1 devices, which are a part of CAM power domain and are needed for proper power on/off sequence. Currently there are no drivers for the devices, which are part of CAM and ISP power domains yet. This patch only fixes the race between disabling the unused power domains and disabling unused clocks, which randomly resulted in the following error during boot: Power domain CAM disable failed Power domain ISP disable failed Fixes: 318fa46cc60d ("clk/samsung: exynos542x: mark some clocks as critical") Signed-off-by: Marek Szyprowski Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 3018d81cd983ca1d2497b13d1a2b39706db53bbf Author: Russell King Date: Wed May 6 10:36:38 2020 +0100 i2c: pxa: clear all master action bits in i2c_pxa_stop_message() [ Upstream commit e81c979f4e071d516aa27cf5a0c3939da00dc1ca ] If we timeout during a message transfer, the control register may contain bits that cause an action to be set. Read-modify-writing the register leaving these bits set may trigger the hardware to attempt one of these actions unintentionally. Always clear these bits when cleaning up after a message or after a timeout. Signed-off-by: Russell King Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 9ecdbfee2dc2cd78d078652db115d43565a728f8 Author: Konstantin Khlebnikov Date: Mon May 11 09:15:18 2020 +0300 f2fs: report delalloc reserve as non-free in statfs for project quota [ Upstream commit baaa7ebf25c78c5cb712fac16b7f549100beddd3 ] This reserved space isn't committed yet but cannot be used for allocations. For userspace it has no difference from used space. See the same fix in ext4 commit f06925c73942 ("ext4: report delalloc reserve as non-free in statfs for project quota"). Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project") Signed-off-by: Konstantin Khlebnikov Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 89d3d21b0e888f9d63ddb70255879693c2f6b044 Author: Andreas Klinger Date: Mon May 4 20:10:34 2020 +0200 iio: bmp280: fix compensation of humidity [ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ] Limit the output of humidity compensation to the range between 0 and 100 percent. Depending on the calibration parameters of the individual sensor it happens, that a humidity above 100 percent or below 0 percent is calculated, which don't make sense in terms of relative humidity. Add a clamp to the compensation formula as described in the datasheet of the sensor in chapter 4.2.3. Although this clamp is documented, it was never in the driver of the kernel. It depends on the circumstances (calibration parameters, temperature, humidity) if one can see a value above 100 percent without the clamp. The writer of this patch was working with this type of sensor without noting this error. So it seems to be a rare event when this bug occures. Signed-off-by: Andreas Klinger Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 63ec23f6b88be1fd983e6f8ae8e61722ccc93dff Author: Viacheslav Dubeyko Date: Wed Apr 22 13:55:52 2020 +0300 scsi: qla2xxx: Fix issue with adapter's stopping state [ Upstream commit 803e45550b11c8e43d89812356fe6f105adebdf9 ] The goal of the following command sequence is to restart the adapter. However, the tgt_stop flag remains set, indicating that the adapter is still in stopping state even after re-enabling it. echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging modprobe target_core_mod modprobe tcm_qla2xxx mkdir /sys/kernel/config/target/qla2xxx mkdir /sys/kernel/config/target/qla2xxx/ mkdir /sys/kernel/config/target/qla2xxx//tpgt_1 echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 0 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable kernel: PID 1396:qla_target.c:1555 qlt_stop_phase1(): tgt_stop 0x0, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-e803:1: PID 1396:qla_target.c:1567: Stopping target for host 1(c0000000033557e8) kernel: PID 1396:qla_target.c:1579 qlt_stop_phase1(): tgt_stop 0x1, tgt_stopped 0x0 kernel: PID 1396:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-e801:1: PID 1396:qla_target.c:1316: Scheduling sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7 kernel: qla2xxx [0001:00:02.0]-290a:1: PID 340:qla_target.c:1187: qlt_unreg_sess sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7 kernel: qla2xxx [0001:00:02.0]-f801:1: PID 340:qla_target.c:1145: Unregistration of sess c00000002d5cd800 21:00:00:24:ff:7f:35:c7 finished fcp_cnt 0 kernel: PID 340:qla_target.c:1155 qlt_free_session_done(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled. kernel: qla2xxx [0001:00:02.0]-28f1:1: PID 346:qla_os.c:3956: Mark all dev lost kernel: PID 346:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end. kernel: PID 1396:qla_target.c:6812 qlt_enable_vha(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled. kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end. qlt_handle_cmd_for_atio() rejects the request to send commands because the adapter is in the stopping state: kernel: PID 0:qla_target.c:4442 qlt_handle_cmd_for_atio(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-3861:1: PID 0:qla_target.c:4447: New command while device c000000005314600 is shutting down kernel: qla2xxx [0001:00:02.0]-e85f:1: PID 0:qla_target.c:5728: qla_target: Unable to send command to target This patch calls qla_stop_phase2() in addition to qlt_stop_phase1() in tcm_qla2xxx_tpg_enable_store() and tcm_qla2xxx_npiv_tpg_enable_store(). The qlt_stop_phase1() marks adapter as stopping (tgt_stop == 0x1, tgt_stopped == 0x0) but qlt_stop_phase2() marks adapter as stopped (tgt_stop == 0x0, tgt_stopped == 0x1). Link: https://lore.kernel.org/r/52be1e8a3537f6c5407eae3edd4c8e08a9545ea5.camel@yadro.com Reviewed-by: Roman Bolshakov Reviewed-by: Himanshu Madhani Signed-off-by: Viacheslav Dubeyko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f7ec605600a3cbed562049600d9a668cb34f6978 Author: Ard Biesheuvel Date: Tue Apr 21 18:22:56 2020 +0200 PCI: Allow pci_resize_resource() for devices on root bus [ Upstream commit d09ddd8190fbdc07696bf34b548ae15aa1816714 ] When resizing a BAR, pci_reassign_bridge_resources() is invoked to bring the bridge windows of parent bridges in line with the new BAR assignment. This assumes the device whose BAR is being resized lives on a subordinate bus, but this is not necessarily the case. A device may live on the root bus, in which case dev->bus->self is NULL, and passing a NULL pci_dev pointer to pci_reassign_bridge_resources() will cause it to crash. So let's make the call to pci_reassign_bridge_resources() conditional on whether dev->bus->self is non-NULL in the first place. Fixes: 8bb705e3e79d84e7 ("PCI: Add pci_resize_resource() for resizing BARs") Link: https://lore.kernel.org/r/20200421162256.26887-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Bjorn Helgaas Reviewed-by: Christian König Signed-off-by: Sasha Levin commit f2ad530b4f328e42ad180cf4729fd55514f32b58 Author: Dan Carpenter Date: Fri May 1 12:40:11 2020 +0300 ALSA: isa/wavefront: prevent out of bounds write in ioctl [ Upstream commit 7f0d5053c5a9d23fe5c2d337495a9d79038d267b ] The "header->number" comes from the ioctl and it needs to be clamped to prevent out of bounds writes. Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c33ee0a0091ed079a2d74c3c43ae46541a9b4838 Author: Kai-Heng Feng Date: Thu Apr 30 16:32:51 2020 +0800 ALSA: hda/realtek - Introduce polarity for micmute LED GPIO [ Upstream commit dbd13179780555ecd3c992dea1222ca31920e892 ] Currently mute LED and micmute LED share the same GPIO polarity. So split the polarity for mute and micmute, in case they have different polarities. Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 84ef0da8910c97d733fa682198da2f501b3e89e9 Author: Dan Carpenter Date: Tue Apr 28 16:19:39 2020 +0300 scsi: qedi: Check for buffer overflow in qedi_set_path() [ Upstream commit 4a4c0cfb4be74e216dd4446b254594707455bfc6 ] Smatch complains that the "path_data->handle" variable is user controlled. It comes from iscsi_set_path() so that seems possible. It's harmless to add a limit check. The qedi->ep_tbl[] array has qedi->max_active_conns elements (which is always ISCSI_MAX_SESS_PER_HBA (4096) elements). The array is allocated in the qedi_cm_alloc_mem() function. Link: https://lore.kernel.org/r/20200428131939.GA696531@mwanda Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b9e3114f7d0c4b1ea4b42fc3a0d06638151087b6 Author: Linus Walleij Date: Thu Feb 13 15:27:54 2020 +0100 ARM: integrator: Add some Kconfig selections [ Upstream commit d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ] The CMA and DMA_CMA Kconfig options need to be selected by the Integrator in order to produce boot console on some Integrator systems. The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be selected in order to boot the system from an external MMC card when using MMCI/PL181 from the device tree probe path. Select these things directly from the Kconfig so we are sure to be able to bring the systems up with console from any device tree. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 49aa5538c547cd4e296cc88e7e2c646bcf0464f7 Author: Xiyu Yang Date: Sat Apr 25 20:48:35 2020 +0800 ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type [ Upstream commit a697ae6ea56e23397341b027098c1b11d9ab13da ] davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a reference of the specified dma_chan object to "chan" with increased refcnt. When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of davinci_mcasp_get_dma_type(). When chan device is NULL, the function forgets to decrease the refcnt increased by dma_request_chan(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when chan device is NULL. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/1587818916-38730-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5970f0c994ef71213d997b95c987dffa1114ef33 Author: Jon Hunter Date: Mon Feb 24 14:07:48 2020 +0000 backlight: lp855x: Ensure regulators are disabled on probe failure [ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ] If probing the LP885x backlight fails after the regulators have been enabled, then the following warning is seen when releasing the regulators ... WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051 _regulator_put.part.28+0x158/0x160 Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables ipv6 nf_defrag_ipv6 CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1 Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) ... Call trace: _regulator_put.part.28+0x158/0x160 regulator_put+0x34/0x50 devm_regulator_release+0x10/0x18 release_nodes+0x12c/0x230 devres_release_all+0x34/0x50 really_probe+0x1c0/0x370 driver_probe_device+0x58/0x100 device_driver_attach+0x6c/0x78 __driver_attach+0xb0/0xf0 bus_for_each_dev+0x68/0xc8 driver_attach+0x20/0x28 bus_add_driver+0x160/0x1f0 driver_register+0x60/0x110 i2c_register_driver+0x40/0x80 lp855x_driver_init+0x20/0x1000 [lp855x_bl] do_one_initcall+0x58/0x1a0 do_init_module+0x54/0x1d0 load_module+0x1d80/0x21c8 __do_sys_finit_module+0xe8/0x100 __arm64_sys_finit_module+0x18/0x20 el0_svc_common.constprop.3+0xb0/0x168 do_el0_svc+0x20/0x98 el0_sync_handler+0xf4/0x1b0 el0_sync+0x140/0x180 Fix this by ensuring that the regulators are disabled, if enabled, on probe failure. Finally, ensure that the vddio regulator is disabled in the driver remove handler. Signed-off-by: Jon Hunter Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 4dfedcd4573104a8e574129d0be3c7f28a078900 Author: Bryan O'Donoghue Date: Sun Mar 29 13:41:16 2020 +0100 clk: qcom: msm8916: Fix the address location of pll->config_reg [ Upstream commit f47ab3c2f5338828a67e89d5f688d2cef9605245 ] During the process of debugging a processor derived from the msm8916 which we found the new processor was not starting one of its PLLs. After tracing the addresses and writes that downstream was doing and comparing to upstream it became obvious that we were writing to a different register location than downstream when trying to configure the PLL. This error is also present in upstream msm8916. As an example clk-pll.c::clk_pll_recalc_rate wants to write to pll->config_reg updating the bit-field POST_DIV_RATIO. That bit-field is defined in PLL_USER_CTL not in PLL_CONFIG_CTL. Taking the BIMC PLL as an example lm80-p0436-13_c_qc_snapdragon_410_processor_hrd.pdf 0x01823010 GCC_BIMC_PLL_USER_CTL 0x01823014 GCC_BIMC_PLL_CONFIG_CTL This pattern is repeated for gpll0, gpll1, gpll2 and bimc_pll. This error is likely not apparent since the bootloader will already have initialized these PLLs. This patch corrects the location of config_reg from PLL_CONFIG_CTL to PLL_USER_CTL for all relevant PLLs on msm8916. Fixes commit 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Cc: Georgi Djakov Cc: Andy Gross Cc: Bjorn Andersson Cc: Michael Turquette Cc: Stephen Boyd Signed-off-by: Bryan O'Donoghue Link: https://lkml.kernel.org/r/20200329124116.4185447-1-bryan.odonoghue@linaro.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit ef3b105643fef94d86a0d2e4b2fed1e149b69594 Author: Alex Elder Date: Wed Apr 15 14:48:52 2020 -0600 remoteproc: Fix IDR initialisation in rproc_alloc() [ Upstream commit 6442df49400b466431979e7634849a464a5f1861 ] If ida_simple_get() returns an error when called in rproc_alloc(), put_device() is called to clean things up. By this time the rproc device type has been assigned, with rproc_type_release() as the release function. The first thing rproc_type_release() does is call: idr_destroy(&rproc->notifyids); But at the time the ida_simple_get() call is made, the notifyids field in the remoteproc structure has not been initialized. I'm not actually sure this case causes an observable problem, but it's incorrect. Fix this by initializing the notifyids field before calling ida_simple_get() in rproc_alloc(). Fixes: b5ab5e24e960 ("remoteproc: maintain a generic child device for each rproc") Signed-off-by: Alex Elder Reviewed-by: Mathieu Poirier Reviewed-by: Suman Anna Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200415204858.2448-2-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c4f970c1a2d394b120171a57af3d9bdc09ec7270 Author: Andy Shevchenko Date: Mon Mar 23 12:41:25 2020 +0200 iio: pressure: bmp280: Tolerate IRQ before registering [ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ] With DEBUG_SHIRQ enabled we have a kernel crash [ 116.482696] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 116.606571] Call Trace: [ 116.609023] [ 116.611047] complete+0x34/0x50 [ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280] because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers ought to be able to handle an interrupt happening before request_irq() returns. Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt") Signed-off-by: Andy Shevchenko Acked-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 75add7b248406bcb46997093793b8fbac3109e95 Author: Adam Honse Date: Fri Apr 10 15:48:44 2020 -0500 i2c: piix4: Detect secondary SMBus controller on AMD AM4 chipsets [ Upstream commit f27237c174fd9653033330e4e532cd9d153ce824 ] The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper equivalents have a secondary SMBus controller at I/O port address 0x0B20. This bus is used by several manufacturers to control motherboard RGB lighting via embedded controllers. I have been using this bus in my OpenRGB project to control the Aura RGB on many motherboards and ASRock also uses this bus for their Polychrome RGB controller. I am not aware of any CZ-compatible platforms which do not have the second SMBus channel. All of AMD's AM4- and Threadripper- series chipsets that OpenRGB users have tested appear to have this secondary bus. I also noticed this secondary bus is present on older AMD platforms including my FM1 home server. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587 Signed-off-by: Adam Honse Reviewed-by: Jean Delvare Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 02c96cc74544ae1c6aafdbb2e70003fa37061b8e Author: Dmitry Osipenko Date: Mon Mar 30 23:40:11 2020 +0300 ASoC: tegra: tegra_wm8903: Support nvidia, headset property [ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ] The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted. Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20200330204011.18465-3-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 613e2436f956a4f7e6662205b01b7fdbb1e83854 Author: Rikard Falkeborn Date: Tue Mar 17 22:13:32 2020 +0100 clk: sunxi: Fix incorrect usage of round_down() [ Upstream commit ee25d9742dabed3fd18158b518f846abeb70f319 ] round_down() can only round to powers of 2. If round_down() is asked to round to something that is not a power of 2, incorrect results are produced. The incorrect results can be both too large and too small. Instead, use rounddown() which can round to any number. Fixes: 6a721db180a2 ("clk: sunxi: Add A31 clocks support") Signed-off-by: Rikard Falkeborn Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 62e015da0070fba9c79215d5c805976a86ce18b6 Author: Enric Balletbo i Serra Date: Mon Apr 13 16:10:51 2020 +0200 power: supply: bq24257_charger: Replace depends on REGMAP_I2C with select [ Upstream commit 87c3d579c8ed0eaea6b1567d529a8daa85a2bc6c ] regmap is a library function that gets selected by drivers that need it. No driver modules should depend on it. Depending on REGMAP_I2C makes this driver only build if another driver already selected REGMAP_I2C, as the symbol can't be selected through the menu kernel configuration. Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver") Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin