aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-05-05mm/hugetlb: optimize the surplus state transfer code in move_hugetlb_state()Miaohe Lin1-0/+6
We should not transfer the per-node surplus state when we do not cross the node in order to save some cpu cycles Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Miaohe Lin <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm/hugetlb: use some helper functions to cleanup codeMiaohe Lin2-4/+4
Patch series "Some cleanups for hugetlb". This series contains cleanups to remove unnecessary VM_BUG_ON_PAGE, use helper function and so on. I also collect some previous patches into this series in case they are forgotten. This patch (of 5): We could use pages_per_huge_page to get the number of pages per hugepage, use get_hstate_idx to calculate hstate index, and use hstate_is_gigantic to check if a hstate is gigantic to make code more succinct. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Miaohe Lin <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm: generalize HUGETLB_PAGE_SIZE_VARIABLEAnshuman Khandual3-10/+9
HUGETLB_PAGE_SIZE_VARIABLE need not be defined for each individual platform subscribing it. Instead just make it generic. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Anshuman Khandual <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Michael Ellerman <[email protected]> [powerpc] Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Mike Kravetz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm/hugetlb: remove redundant reservation check condition in alloc_huge_page()Miaohe Lin1-1/+1
vma_resv_map(vma) checks if a reserve map is associated with the vma. The routine vma_needs_reservation() will check vma_resv_map(vma) and return 1 if no reserv map is present. map_chg is set to the return value of vma_needs_reservation(). Therefore, !vma_resv_map(vma) is redundant in the expression: map_chg || avoid_reserve || !vma_resv_map(vma); Remove the redundant check. [Thanks Mike Kravetz for reshaping this commit message!] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Miaohe Lin <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05hugetlb/userfaultfd: unshare all pmds for hugetlbfs when register wpPeter Xu3-0/+58
Huge pmd sharing for hugetlbfs is racy with userfaultfd-wp because userfaultfd-wp is always based on pgtable entries, so they cannot be shared. Walk the hugetlb range and unshare all such mappings if there is, right before UFFDIO_REGISTER will succeed and return to userspace. This will pair with want_pmd_share() in hugetlb code so that huge pmd sharing is completely disabled for userfaultfd-wp registered range. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Cc: Peter Xu <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Axel Rasmussen <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Adam Ruprecht <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Anshuman Khandual <[email protected]> Cc: Cannon Matthews <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Lokesh Gidra <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Michal Koutn" <[email protected]> Cc: Michel Lespinasse <[email protected]> Cc: Mina Almasry <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Shawn Anastasio <[email protected]> Cc: Steven Price <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm/hugetlb: move flush_hugetlb_tlb_range() into hugetlb.hPeter Xu2-8/+8
Prepare for it to be called outside of mm/hugetlb.c. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Reviewed-by: Axel Rasmussen <[email protected]> Cc: Adam Ruprecht <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Anshuman Khandual <[email protected]> Cc: Cannon Matthews <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Lokesh Gidra <[email protected]> Cc: "Matthew Wilcox (Oracle)" <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Michal Koutn" <[email protected]> Cc: Michel Lespinasse <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Mina Almasry <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Shawn Anastasio <[email protected]> Cc: Steven Price <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05hugetlb/userfaultfd: forbid huge pmd sharing when uffd enabledPeter Xu4-8/+28
Huge pmd sharing could bring problem to userfaultfd. The thing is that userfaultfd is running its logic based on the special bits on page table entries, however the huge pmd sharing could potentially share page table entries for different address ranges. That could cause issues on either: - When sharing huge pmd page tables for an uffd write protected range, the newly mapped huge pmd range will also be write protected unexpectedly, or, - When we try to write protect a range of huge pmd shared range, we'll first do huge_pmd_unshare() in hugetlb_change_protection(), however that also means the UFFDIO_WRITEPROTECT could be silently skipped for the shared region, which could lead to data loss. While at it, a few other things are done altogether: - Move want_pmd_share() from mm/hugetlb.c into linux/hugetlb.h, because that's definitely something that arch code would like to use too - ARM64 currently directly check against CONFIG_ARCH_WANT_HUGE_PMD_SHARE when trying to share huge pmd. Switch to the want_pmd_share() helper. - Move vma_shareable() from huge_pmd_share() into want_pmd_share(). [[email protected]: fix build with !ARCH_WANT_HUGE_PMD_SHARE] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Reviewed-by: Axel Rasmussen <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Cc: Adam Ruprecht <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Anshuman Khandual <[email protected]> Cc: Cannon Matthews <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Lokesh Gidra <[email protected]> Cc: "Matthew Wilcox (Oracle)" <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Michal Koutn" <[email protected]> Cc: Michel Lespinasse <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Mina Almasry <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Shawn Anastasio <[email protected]> Cc: Steven Price <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05hugetlb: pass vma into huge_pte_alloc() and huge_pmd_share()Peter Xu11-20/+24
Patch series "hugetlb: Disable huge pmd unshare for uffd-wp", v4. This series tries to disable huge pmd unshare of hugetlbfs backed memory for uffd-wp. Although uffd-wp of hugetlbfs is still during rfc stage, the idea of this series may be needed for multiple tasks (Axel's uffd minor fault series, and Mike's soft dirty series), so I picked it out from the larger series. This patch (of 4): It is a preparation work to be able to behave differently in the per architecture huge_pte_alloc() according to different VMA attributes. Pass it deeper into huge_pmd_share() so that we can avoid the find_vma() call. [[email protected]: build fix] Link: https://lkml.kernel.org/r/20210304164653.GB397383@xz-x1Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Peter Xu <[email protected]> Suggested-by: Mike Kravetz <[email protected]> Cc: Adam Ruprecht <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Anshuman Khandual <[email protected]> Cc: Axel Rasmussen <[email protected]> Cc: Cannon Matthews <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: David Rientjes <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Huang Ying <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jann Horn <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Lokesh Gidra <[email protected]> Cc: "Matthew Wilcox (Oracle)" <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: "Michal Koutn" <[email protected]> Cc: Michel Lespinasse <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Mina Almasry <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Oliver Upton <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Shawn Anastasio <[email protected]> Cc: Steven Price <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm: remove nrexceptional from inode: remove BUG_ONHugh Dickins1-1/+8
clear_inode()'s BUG_ON(!mapping_empty(&inode->i_data)) is unsafe: we know of two ways in which nodes can and do (on rare occasions) get left behind. Until those are fixed, do not BUG_ON() nor even WARN_ON(). Yes, this will then leak those nodes (or the next user of the struct inode may use them); but this has been happening for years, and the new BUG_ON(!mapping_empty) was only guilty of revealing that. A proper fix will follow, but no hurry. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Hugh Dickins <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm: remove nrexceptional from inodeMatthew Wilcox (Oracle)2-3/+1
We no longer track anything in nrexceptional, so remove it, saving 8 bytes per inode. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Tested-by: Vishal Verma <[email protected]> Acked-by: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05dax: account DAX entries as nrpagesMatthew Wilcox (Oracle)2-6/+3
Simplify mapping_needs_writeback() by accounting DAX entries as pages instead of exceptional entries. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Tested-by: Vishal Verma <[email protected]> Acked-by: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm: stop accounting shadow entriesMatthew Wilcox (Oracle)4-19/+0
We no longer need to keep track of how many shadow entries are present in a mapping. This saves a few writes to the inode and memory barriers. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Tested-by: Vishal Verma <[email protected]> Acked-by: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05mm: introduce and use mapping_empty()Matthew Wilcox (Oracle)5-19/+11
Patch series "Remove nrexceptional tracking", v2. We actually use nrexceptional for very little these days. It's a minor pain to keep in sync with nrpages, but the pain becomes much bigger with the THP patches because we don't know how many indices a shadow entry occupies. It's easier to just remove it than keep it accurate. Also, we save 8 bytes per inode which is nothing to sneeze at; on my laptop, it would improve shmem_inode_cache from 22 to 23 objects per 16kB, and inode_cache from 26 to 27 objects. Combined, that saves a megabyte of memory from a combined usage of 25MB for both caches. Unfortunately, ext4 doesn't cross a magic boundary, so it doesn't save any memory for ext4. This patch (of 4): Instead of checking the two counters (nrpages and nrexceptional), we can just check whether i_pages is empty. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Tested-by: Vishal Verma <[email protected]> Acked-by: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-05-05arm64: Fix the documented event stream frequencyCatalin Marinas1-1/+1
It should be 10KHz, matching the ARCH_TIMER_EVT_STREAM_PERIOD_US of 100us. Note that this is only a documentation bug. Fixes: 611a7bc74ed2 ("arm64: docs: describe ELF hwcaps") Signed-off-by: Catalin Marinas <[email protected]> Cc: Mark Rutland <[email protected]> Acked-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2021-05-06kbuild: Don't remove link-vmlinux temporary files on exit/signalAndi Kleen1-14/+0
Keep them around until they are cleaned up by make clean. This uses a bit more disk space, but makes it easier to debug any problems with the kernel link process. Suggested-by: Masahiro Yamada <[email protected]> Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-06kbuild: remove the unneeded comments for external module buildsMasahiro Yamada1-11/+1
The supported targets for external modules are listed in the help target a few lines below. Let's not have duplicated information in two places. Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-06kbuild: make distclean remove tag files in sub-directoriesMasahiro Yamada1-7/+2
'make tags' and friends create tag files in the top directory, but people may manually create tag files in sub-directories. Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-06kbuild: make distclean work against $(objtree) instead of $(srctree)Masahiro Yamada1-1/+1
This reverts the old commit [1], which seems questionable to me. It claimed 'make distclean' could not remove editor backup files, but I believe KBUILD_OUTPUT or O= was set. When O= is given, Kbuild should always work against $(objtree). If O= is not given, $(objtree) and $(srctree) are the same, therefore $(srctree) is cleaned up. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=dd47df980c02eb33833b2690b033c34fba2fa80d Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-06kbuild: refactor modname-multi by using suffix-searchMasahiro Yamada1-1/+1
Improve the readability slightly. Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-06kbuild: refactor fdtoverlay ruleMasahiro Yamada2-19/+16
Rename overlay-y to multi-dtb-y, which is a consistent name with multi-obj-y. Also, use multi-search to avoid code duplication. Introduce real-dtb-y, which is a consistent name with real-obj-y, to contain primitive blobs compiled from *.dts. This is used to calculate the list of *.dt.yaml files. Set -@ to base DTB without using $(eval ). Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-06kbuild: parameterize the .o part of suffix-searchMasahiro Yamada1-8/+11
The suffix-search macro hard-codes the suffix, '.o'. Make it a parameter so that the multi-search and real-search macros can be reused for foo-dtbs syntax introduced by commit 15d16d6dadf6 ("kbuild: Add generic rule to apply fdtoverlay"). Signed-off-by: Masahiro Yamada <[email protected]>
2021-05-05arm64: entry: always set GIC_PRIO_PSR_I_SET during entryMark Rutland3-30/+5
Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18 Fixes: 23529049c684 ("arm64: entry: fix non-NMI user<->kernel transitions") Fixes: 7cd1ea1010ac ("arm64: entry: fix non-NMI kernel<->kernel transitions") Fixes: f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") Fixes: 2a9b3e6ac69a ("arm64: entry: fix EL1 debug transitions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Rutland <[email protected]> Reported-by: Zenghui Yu <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Will Deacon <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2021-05-06arch: use cross_compiling to check whether it is a cross build or notMasahiro Yamada5-9/+5
'cross_compiling' is defined by the top Makefile and available for arch Makefiles to check whether it is a cross build or not. A good thing is the variable name 'cross_compiling' is self-documenting. This is a simple replacement for m68k, mips, sh, for which $(ARCH) and $(SRCARCH) always match. No functional change is intended for xtensa, either. This is rather a fix for parisc because arch/parisc/Makefile defines UTS_MATCHINE depending on CONFIG_64BIT, therefore cc-cross-prefix is not working in Kconfig time. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Helge Deller <[email protected]> # parisc Acked-by: Max Filippov <[email protected]> # xtensa
2021-05-05ARM: footbridge: remove personal server platformRussell King5-107/+0
Remove the personal server platform, as that has had an array overrun issue identified. It is believed that no one is using this code. Signed-off-by: Russell King <[email protected]>
2021-05-05docs: vfio: fix typoAlyssa Ross1-1/+1
Signed-off-by: Alyssa Ross <[email protected]> Message-Id: <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2021-05-05vfio/pci: Revert nvlink removal uAPI breakageAlex Williamson1-4/+42
Revert the uAPI changes from the below commit with notice that these regions and capabilities are no longer provided. Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2") Reported-by: Greg Kurz <[email protected]> Signed-off-by: Alex Williamson <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Reviewed-by: Greg Kurz <[email protected]> Tested-by: Greg Kurz <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Message-Id: <162014341432.3807030.11054087109120670135.stgit@omen>
2021-05-05netfilter: nfnetlink: add a missing rcu_read_unlock()Eric Dumazet1-0/+1
Reported by syzbot : BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 26899, name: syz-executor.5 1 lock held by syz-executor.5/26899: #0: ffffffff8bf797a0 (rcu_read_lock){....}-{1:2}, at: nfnetlink_get_subsys net/netfilter/nfnetlink.c:148 [inline] #0: ffffffff8bf797a0 (rcu_read_lock){....}-{1:2}, at: nfnetlink_rcv_msg+0x1da/0x1300 net/netfilter/nfnetlink.c:226 Preemption disabled at: [<ffffffff8917799e>] preempt_schedule_irq+0x3e/0x90 kernel/sched/core.c:5533 CPU: 1 PID: 26899 Comm: syz-executor.5 Not tainted 5.12.0-next-20210504-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ___might_sleep.cold+0x1f1/0x237 kernel/sched/core.c:8338 might_alloc include/linux/sched/mm.h:201 [inline] slab_pre_alloc_hook mm/slab.h:500 [inline] slab_alloc_node mm/slub.c:2845 [inline] kmem_cache_alloc_node+0x33d/0x3e0 mm/slub.c:2960 __alloc_skb+0x20b/0x340 net/core/skbuff.c:413 alloc_skb include/linux/skbuff.h:1107 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x1ed/0xaa0 net/netlink/af_netlink.c:2437 netlink_rcv_skb+0x33d/0x420 net/netlink/af_netlink.c:2508 nfnetlink_rcv+0x1ac/0x420 net/netfilter/nfnetlink.c:650 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa8a03ee188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000056bf60 RCX: 00000000004665f9 RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000004 RBP: 00000000004bfce1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf60 R13: 00007fffe864480f R14: 00007fa8a03ee300 R15: 0000000000022000 ================================================ WARNING: lock held when returning to user space! 5.12.0-next-20210504-syzkaller #0 Tainted: G W ------------------------------------------------ syz-executor.5/26899 is leaving the kernel with locks still held! 1 lock held by syz-executor.5/26899: #0: ffffffff8bf797a0 (rcu_read_lock){....}-{1:2}, at: nfnetlink_get_subsys net/netfilter/nfnetlink.c:148 [inline] #0: ffffffff8bf797a0 (rcu_read_lock){....}-{1:2}, at: nfnetlink_rcv_msg+0x1da/0x1300 net/netfilter/nfnetlink.c:226 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 26899 at kernel/rcu/tree_plugin.h:359 rcu_note_context_switch+0xfd/0x16e0 kernel/rcu/tree_plugin.h:359 Modules linked in: CPU: 0 PID: 26899 Comm: syz-executor.5 Tainted: G W 5.12.0-next-20210504-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rcu_note_context_switch+0xfd/0x16e0 kernel/rcu/tree_plugin.h:359 Code: 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 2e 0d 00 00 8b bd cc 03 00 00 85 ff 7e 02 <0f> 0b 65 48 8b 2c 25 00 f0 01 00 48 8d bd cc 03 00 00 48 b8 00 00 RSP: 0000:ffffc90002fffdb0 EFLAGS: 00010002 RAX: 0000000000000007 RBX: ffff8880b9c36080 RCX: ffffffff8dc99bac RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000001 RBP: ffff88808b9d1c80 R08: 0000000000000000 R09: ffffffff8dc96917 R10: fffffbfff1b92d22 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88808b9d1c80 R14: ffff88808b9d1c80 R15: ffffc90002ff8000 FS: 00007fa8a03ee700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f09896ed000 CR3: 0000000032070000 CR4: 00000000001526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __schedule+0x214/0x23e0 kernel/sched/core.c:5044 schedule+0xcf/0x270 kernel/sched/core.c:5226 exit_to_user_mode_loop kernel/entry/common.c:162 [inline] exit_to_user_mode_prepare+0x13e/0x280 kernel/entry/common.c:208 irqentry_exit_to_user_mode+0x5/0x40 kernel/entry/common.c:314 asm_sysvec_reschedule_ipi+0x12/0x20 arch/x86/include/asm/idtentry.h:637 RIP: 0033:0x4665f9 Fixes: 50f2db9e368f ("netfilter: nfnetlink: consolidate callback types") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2021-05-05ftrace: Handle commands when closing set_ftrace_filter fileSteven Rostedt (VMware)1-1/+4
# echo switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter will cause switch_mm to stop tracing by the traceoff command. # echo -n switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter does nothing. The reason is that the parsing in the write function only processes commands if it finished parsing (there is white space written after the command). That's to handle: write(fd, "switch_mm:", 10); write(fd, "traceoff", 8); cases, where the command is broken over multiple writes. The problem is if the file descriptor is closed, then the write call is not processed, and the command needs to be processed in the release code. The release code can handle matching of functions, but does not handle commands. Cc: [email protected] Fixes: eda1e32855656 ("tracing: handle broken names in ftrace filter") Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-05-05Merge tag 'nvme-5.13-2021-05-05' of git://git.infradead.org/nvme into block-5.13Jens Axboe12-134/+143
Pull NVMe fixes from Christoph: "nvme updates for Linux 5.13 - reset the bdev to ns head when failover (Daniel Wagner) - remove unsupported command noise (Keith Busch) - misc passthrough improvements (Kanchan Joshi) - fix controller ioctl through ns_head (Minwoo Im) - fix controller timeouts during reset (Tao Chiu)" * tag 'nvme-5.13-2021-05-05' of git://git.infradead.org/nvme: nvmet: remove unsupported command noise nvme-multipath: reset bdev to ns head when failover nvme-pci: fix controller reset hang when racing with nvme_timeout nvme: move the fabrics queue ready check routines to core nvme: avoid memset for passthrough requests nvme: add nvme_get_ns helper nvme: fix controller ioctl through ns_head
2021-05-06KVM: PPC: Book3S HV: Fix conversion to gfn-based MMU notifier callbacksNicholas Piggin3-17/+36
Commit b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks") causes unmap_gfn_range and age_gfn callbacks to only work on the first gfn in the range. It also makes the aging callbacks call into both radix and hash aging functions for radix guests. Fix this. Add warnings for the single-gfn calls that have been converted to range callbacks, in case they ever receieve ranges greater than 1. Fixes: b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks") Reported-by: Bharata B Rao <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Tested-by: Bharata B Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-05-05dt-bindings: gpio: add YAML description for rockchip,gpio-bankJohan Jonker2-57/+83
Current dts files with "rockchip,gpio-bank" subnodes are manually verified. In order to automate this process the text that describes the compatible in rockchip,pinctrl.txt is removed and converted to YAML in rockchip,gpio-bank.yaml. Signed-off-by: Johan Jonker <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05gpio: mxs: remove useless functionJiapeng Chong1-5/+0
Fix the following gcc warning: drivers/gpio/gpio-mxs.c:63:19: warning: kernel/sys_ni.cunused function 'is_imx28_gpio'. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05dt-bindings: gpio: fairchild,74hc595: Convert to json-schemaGeert Uytterhoeven2-27/+77
Convert the Generic 8-bit shift register Device Tree binding documentation to json-schema. Rename from gpio-74x164 to fairchild,74hc595, as the former refers to the Linux driver, and not to a hardware name. Add the missing hog description. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05gpio: it87: remove unused codeJiapeng Chong1-8/+0
Fix the following clang warning: drivers/gpio/gpio-it87.c:128:20: warning: unused function 'superio_outw' [-Wunused-function]. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Acked-by: Simon Guinot <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05gpio: 104-dio-48e: Fix coding style issuesBarney Goette1-25/+25
Fixed multiple bare uses of 'unsigned' without 'int'. Fixed space around "*" operator. Fixed function parameter alignment to opening parenthesis. Reported by checkpatch. Signed-off-by: Barney Goette <[email protected]> Acked-by: William Breathitt Gray <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05gpio: mpc8xxx: Add ACPI supportRan Wang1-14/+33
Current implementation only supports DT, now add ACPI support. Signed-off-by: Ran Wang <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05gpio: ich: Switch to be dependent on LPC_ICHAndy Shevchenko2-5/+2
Driver is neither dependent to PCI nor using MFD_CORE. Replace those dependency and selection by dependency on LPC_ICH. Signed-off-by: Andy Shevchenko <[email protected]>
2021-05-05gpio: sch: Drop MFD_CORE selectionAndy Shevchenko1-1/+0
Since we are depended on LPC_SCH, which selects MFD_CORE, we don't need to do it ourselves. Signed-off-by: Andy Shevchenko <[email protected]>
2021-05-05gpio: sch: depends on LPC_SCHRandy Dunlap1-1/+1
Since LPC_SCH provides GPIO functionality, GPIO_SCH should depend on LPC_SCH to prevent kconfig warning and build errors: WARNING: unmet direct dependencies detected for LPC_SCH Depends on [n]: HAS_IOMEM [=y] && PCI [=n] Selected by [y]: - GPIO_SCH [=y] && GPIOLIB [=y] && X86 [=y] && (X86 [=y] || COMPILE_TEST [=n]) && ACPI [=y] and ../drivers/mfd/lpc_sch.c:204:1: warning: data definition has no type or storage class module_pci_driver(lpc_sch_driver); ^~~~~~~~~~~~~~~~~ ../drivers/mfd/lpc_sch.c:204:1: error: type defaults to ‘int’ in declaration of ‘module_pci_driver’ [-Werror=implicit-int] ../drivers/mfd/lpc_sch.c:204:1: warning: parameter names (without types) in function declaration ../drivers/mfd/lpc_sch.c:197:26: warning: ‘lpc_sch_driver’ defined but not used [-Wunused-variable] static struct pci_driver lpc_sch_driver = { ^~~~~~~~~~~~~~ Fixes: 6c46215d6b62 ("gpio: sch: Hook into ACPI GPE handler to catch GPIO edge events") Signed-off-by: Randy Dunlap <[email protected]> Cc: Linus Walleij <[email protected]> Cc: [email protected] Cc: Bartosz Golaszewski <[email protected]> Cc: Denis Turischev <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2021-05-05gpiolib: acpi: Add quirk to ignore EC wakeups on Dell Venue 10 Pro 5055Hans de Goede1-0/+14
Like some other Bay and Cherry Trail SoC based devices the Dell Venue 10 Pro 5055 has an embedded-controller which uses ACPI GPIO events to report events instead of using the standard ACPI EC interface for this. The EC interrupt is only used to report battery-level changes and it keeps doing this while the system is suspended, causing the system to not stay suspended. Add an ignore-wake quirk for the GPIO pin used by the EC to fix the spurious wakeups from suspend. Signed-off-by: Hans de Goede <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2021-05-05gpio: sch: Hook into ACPI GPE handler to catch GPIO edge eventsAndy Shevchenko2-1/+83
Neither the ACPI description on Intel Minnowboard (v1) platform provides the required information to establish a generic handling nor the hardware capable of doing it. According to the data sheet the hardware can generate SCI events. Therefore, we need to hook from the driver into GPE handler of the ACPI subsystem in order to catch and report GPIO-related events. Validated on the Inlel Minnowboard (v1) platform and Intel Galileo Gen 2. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]>
2021-05-05gpio: sch: Add edge event supportJan Kiszka2-8/+109
Add the required infrastructure to enable and report edge events of the pins to the GPIO core. The actual hook-up of the event interrupt will happen separately. Signed-off-by: Jan Kiszka <[email protected]> Co-developed-by: Andy Shevchenko <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]>
2021-05-05gpio: aggregator: Replace custom get_arg() with a generic next_arg()Andy Shevchenko1-34/+5
cmdline library provides next_arg() helper to traverse over parameters and their values given in command line. Replace custom approach in the driver by it. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]>
2021-05-05lib/cmdline: Export next_arg() for being used in modulesAndy Shevchenko1-0/+1
At least one module will benefit from using next_arg() helper. Let's export it for that module and others if they consider it helpful. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]>
2021-05-05gpio: omap: Use device_get_match_data() helperTian Tao1-3/+2
Use the device_get_match_data() helper instead of open coding. Signed-off-by: Tian Tao <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05gpio: Add Realtek Otto GPIO supportSander Vanheule3-0/+339
Realtek MIPS SoCs (platform name Otto) have GPIO controllers with up to 64 GPIOs, divided over two banks. Each bank has a set of registers for 32 GPIOs, with support for edge-triggered interrupts. Each GPIO bank consists of four 8-bit GPIO ports (ABCD and EFGH). Most registers pack one bit per GPIO, except for the IMR register, which packs two bits per GPIO (AB-CD). Although the byte order is currently assumed to have port A..D at offset 0x0..0x3, this has been observed to be reversed on other, Lexra-based, SoCs (e.g. RTL8196E/97D/97F). Interrupt support is disabled for the fallback devicetree-compatible 'realtek,otto-gpio'. This allows for quick support of GPIO banks in which the byte order would be unknown. In this case, the port ordering in the IMR registers may not match the reversed order in the other registers (DCBA, and BA-DC or DC-BA). Signed-off-by: Sander Vanheule <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05dt-bindings: gpio: Binding for Realtek Otto GPIOSander Vanheule1-0/+78
Add a binding description for Realtek's GPIO controller found on several of their MIPS-based SoCs (codenamed Otto), such as the RTL838x and RTL839x series of switch SoCs. A fallback binding 'realtek,otto-gpio' is provided for cases where the actual port ordering is not known yet, and enabling the interrupt controller may result in uncaught interrupts. Signed-off-by: Sander Vanheule <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05docs: kernel-parameters: Add gpio_mockup_named_linesAlexander Dahl1-0/+2
Missing since introduced in the driver. Fixes: 8a68ea00a62e ("gpio: mockup: implement naming the lines") Signed-off-by: Alexander Dahl <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05docs: kernel-parameters: Move gpio-mockup for alphabetic orderAlexander Dahl1-4/+4
All other sections are ordered alphabetically so do the same for gpio-mockup. Fixes: 0f98dd1b27d2 ("gpio/mockup: add virtual gpio device") Signed-off-by: Alexander Dahl <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-05-05lib: bitmap: provide devm_bitmap_alloc() and devm_bitmap_zalloc()Bartosz Golaszewski2-0/+41
Provide managed variants of bitmap_alloc() and bitmap_zalloc(). Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>