user/sven/linux.git, branch v5.16.19

Linux 5.16.19

2022-04-08T12:06:58Z

Link: https://lore.kernel.org/r/20220405070354.155796697@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Fox Chen Tested-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220406133109.570377390@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

PCI: xgene: Revert "PCI: xgene: Use inbound resources for setup"

2022-04-08T12:06:58Z

commit 1874b6d7ab1bdc900e8398026350313ac29caddb upstream. Commit 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") killed PCIe on my XGene-1 box (a Mustang board). The machine itself is still alive, but half of its storage (over NVMe) is gone, and the NVMe driver just times out. Note that this machine boots with a device tree provided by the UEFI firmware (2016 vintage), which could well be non conformant with the spec, hence the breakage. With the patch reverted, the box boots 5.17-rc8 with flying colors. Link: https://lore.kernel.org/all/Yf2wTLjmcRj+AbDv@xps13.dannf Link: https://lore.kernel.org/r/20220321104843.949645-2-maz@kernel.org Fixes: 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") Signed-off-by: Marc Zyngier Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Cc: Rob Herring Cc: Toan Le Cc: Lorenzo Pieralisi Cc: Krzysztof Wilczyński Cc: Bjorn Helgaas Cc: Stéphane Graber Cc: dann frazier [dannf: minor context adjustment] Signed-off-by: dann frazier Signed-off-by: Greg Kroah-Hartman

coredump: Use the vma snapshot in fill_files_note

2022-04-08T12:06:58Z

commit 390031c942116d4733310f0684beb8db19885fe6 upstream. Matthew Wilcox reported that there is a missing mmap_lock in file_files_note that could possibly lead to a user after free. Solve this by using the existing vma snapshot for consistency and to avoid the need to take the mmap_lock anywhere in the coredump code except for dump_vma_snapshot. Update the dump_vma_snapshot to capture vm_pgoff and vm_file that are neeeded by fill_files_note. Add free_vma_snapshot to free the captured values of vm_file. Reported-by: Matthew Wilcox Link: https://lkml.kernel.org/r/20220131153740.2396974-1-willy@infradead.org Cc: stable@vger.kernel.org Fixes: a07279c9a8cd ("binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot") Fixes: 2aa362c49c31 ("coredump: extend core dump note section to contain file names of mapped files") Reviewed-by: Kees Cook Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman

coredump/elf: Pass coredump_params into fill_note_info

2022-04-08T12:06:58Z

commit 9ec7d3230717b4fe9b6c7afeb4811909c23fa1d7 upstream. Instead of individually passing cprm->siginfo and cprm->regs into fill_note_info pass all of struct coredump_params. This is preparation to allow fill_files_note to use the existing vma snapshot. Reviewed-by: Jann Horn Reviewed-by: Kees Cook Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman

coredump: Remove the WARN_ON in dump_vma_snapshot

2022-04-08T12:06:58Z

commit 49c1866348f364478a0c4d3dd13fd08bb82d3a5b upstream. The condition is impossible and to the best of my knowledge has never triggered. We are in deep trouble if that conditions happens and we walk past the end of our allocated array. So delete the WARN_ON and the code that makes it look like the kernel can handle the case of walking past the end of it's vma_meta array. Reviewed-by: Jann Horn Reviewed-by: Kees Cook Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman

coredump: Snapshot the vmas in do_coredump

2022-04-08T12:06:58Z

commit 95c5436a4883841588dae86fb0b9325f47ba5ad3 upstream. Move the call of dump_vma_snapshot and kvfree(vma_meta) out of the individual coredump routines into do_coredump itself. This makes the code less error prone and easier to maintain. Make the vma snapshot available to the coredump routines in struct coredump_params. This makes it easier to change and update what is captures in the vma snapshot and will be needed for fixing fill_file_notes. Reviewed-by: Jann Horn Reviewed-by: Kees Cook Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman

KVM: x86/mmu: do compare-and-exchange of gPTE via the user address

2022-04-08T12:06:58Z

commit 2a8859f373b0a86f0ece8ec8312607eacf12485d upstream. FNAME(cmpxchg_gpte) is an inefficient mess. It is at least decent if it can go through get_user_pages_fast(), but if it cannot then it tries to use memremap(); that is not just terribly slow, it is also wrong because it assumes that the VM_PFNMAP VMA is contiguous. The right way to do it would be to do the same thing as hva_to_pfn_remapped() does since commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults before giving up", 2016-07-05), using follow_pte() and fixup_user_fault() to determine the correct address to use for memremap(). To do this, one could for example extract hva_to_pfn() for use outside virt/kvm/kvm_main.c. But really there is no reason to do that either, because there is already a perfectly valid address to do the cmpxchg() on, only it is a userspace address. That means doing user_access_begin()/user_access_end() and writing the code in assembly to handle exceptions correctly. Worse, the guest PTE can be 8-byte even on i686 so there is the extra complication of using cmpxchg8b to account for. But at least it is an efficient mess. (Thanks to Linus for suggesting improvement on the inline assembly). Reported-by: Qiuhao Li Reported-by: Gaoning Pan Reported-by: Yongkang Jia Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com Debugged-by: Tadeusz Struk Tested-by: Maxim Levitsky Cc: stable@vger.kernel.org Fixes: bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs") Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman

mmc: rtsx: Fix build errors/warnings for unused variable

2022-04-08T12:06:58Z

commit 3dd9a926ec2308e49445f22abef149fc64e9332e upstream. The struct device *dev, is no longer needed at various functions, let's therefore drop it to fix the build errors/warnings. Fixes: 7570fb41e450 ("mmc: rtsx: Let MMC core handle runtime PM") Cc: Kai-Heng Feng Reported-by: kernel test robot Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20220301115300.64332-1-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman

mmc: rtsx: Let MMC core handle runtime PM

2022-04-08T12:06:58Z

commit 7570fb41e450ba37bf9335fe3751fa9f502c30fa upstream. Since MMC core handles runtime PM reference counting, we can avoid doing redundant runtime PM work in the driver. That means the only thing commit 5b4258f6721f ("misc: rtsx: rts5249 support runtime PM") misses is to always enable runtime PM, to let its parent driver enable ASPM in the runtime idle routine. Fixes: 7499b529d97f ("mmc: rtsx: Use pm_runtime_{get,put}() to handle runtime PM") Reviewed-by: Ulf Hansson Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20220216055435.2335297-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman

Revert "nbd: fix possible overflow on 'first_minor' in nbd_dev_add()"

2022-04-08T12:06:57Z

commit 7198bfc2017644c6b92d2ecef9b8b8e0363bb5fd upstream. This reverts commit 6d35d04a9e18990040e87d2bbf72689252669d54. Both Gabriel and Borislav report that this commit casues a regression with nbd: sysfs: cannot create duplicate filename '/dev/block/43:0' Revert it before 5.18-rc1 and we'll investigage this separately in due time. Link: https://lore.kernel.org/all/YkiJTnFOt9bTv6A2@zn.tnic/ Reported-by: Gabriel L. Somlo Reported-by: Borislav Petkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman