- 30 Oct, 2022 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/crng/randomLinus Torvalds authored
Pull random number generator fix from Jason Donenfeld: "One fix from Jean-Philippe Brucker, addressing a regression in which early boot code on ARM64 would use the non-_early variant of the arch_get_random family of functions, resulting in the architectural random number generator appearing unavailable during that early phase of boot. The fix simply changes arch_get_random*() to arch_get_random*_early(). This distinction between these two functions is a bit of an old wart I'm not a fan of, and for 6.2 I'll see if I can make obsolete the _early variant, so that one function does the right thing in all contexts without overhead" * tag 'random-6.1-rc3-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: random: use arch_get_random*_early() in random_init()
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Varions small fixes, all in drivers. Some of these arrived during the merge window and got held over to make sure of testing on the -rc tree. The biggest change is for standards conformance in the target driver, closely followed by a set of bug fixes in megaraid_sas" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (21 commits) scsi: ufs: core: Fix typo in comment scsi: mpi3mr: Select CONFIG_SCSI_SAS_ATTRS scsi: ufs: core: Fix typo for register name in comments scsi: pm80xx: Display proc_name in sysfs scsi: ufs: core: Fix the error log in ufshcd_query_flag_retry() scsi: ufs: core: Remove unneeded casts from void * scsi: lpfc: Fix spelling mistake "unsolicted" -> "unsolicited" scsi: qla2xxx: Use transport-defined speed mask for supported_speeds scsi: target: iblock: Fold iblock_emulate_read_cap_with_block_size() into iblock_get_blocks() scsi: qla2xxx: Fix serialization of DCBX TLV data request scsi: ufs: qcom: Remove redundant dev_err() call scsi: megaraid_sas: Move megasas_dbg_lvl init to megasas_init() scsi: megaraid_sas: Remove unnecessary memset() scsi: megaraid_sas: Simplify megasas_update_device_list scsi: megaraid_sas: Correct an error message scsi: megaraid_sas: Correct value passed to scsi_device_lookup() scsi: target: core: UA on all LUNs after reset scsi: target: core: New key must be used for moved PR scsi: target: core: Abort all preempted regs if requested scsi: target: core: Fix memory leak in preempt_and_abort ...
-
git://git.kernel.dk/linuxLinus Torvalds authored
Pull block fixes from Jens Axboe: - NVMe pull request via Christoph: - make the multipath dma alignment match the non-multipath one (Keith Busch) - fix a bogus use of sg_init_marker() (Nam Cao) - fix circulr locking in nvme-tcp (Sagi Grimberg) - Initialization fix for requests allocated via the special hw queue allocator (John) - Fix for a regression added in this release with the batched completions of end_io backed requests (Ming) - Error handling leak fix for rbd (Yang) - Error handling leak fix for add_disk() failure (Yu) * tag 'block-6.1-2022-10-28' of git://git.kernel.dk/linux: blk-mq: Properly init requests from blk_mq_alloc_request_hctx() blk-mq: don't add non-pt request with ->end_io to batch rbd: fix possible memory leak in rbd_sysfs_init() nvme-multipath: set queue dma alignment to 3 nvme-tcp: fix possible circular locking when deleting a controller under memory pressure nvme-tcp: replace sg_init_marker() with sg_init_table() block: fix memory leak for elevator on add_disk failure
-
git://git.kernel.dk/linuxLinus Torvalds authored
Pull io_uring fix from Jens Axboe: "Just a fix for a locking regression introduced with the deferred task_work running from this merge window" * tag 'io_uring-6.1-2022-10-28' of git://git.kernel.dk/linux: io_uring: unlock if __io_run_local_work locked inside io_uring: use io_run_local_work_locked helper
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull misc hotfixes from Andrew Morton: "Eight fix pre-6.0 bugs and the remainder address issues which were introduced in the 6.1-rc merge cycle, or address issues which aren't considered sufficiently serious to warrant a -stable backport" * tag 'mm-hotfixes-stable-2022-10-28' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (23 commits) mm: multi-gen LRU: move lru_gen_add_mm() out of IRQ-off region lib: maple_tree: remove unneeded initialization in mtree_range_walk() mmap: fix remap_file_pages() regression mm/shmem: ensure proper fallback if page faults mm/userfaultfd: replace kmap/kmap_atomic() with kmap_local_page() x86: fortify: kmsan: fix KMSAN fortify builds x86: asm: make sure __put_user_size() evaluates pointer once Kconfig.debug: disable CONFIG_FRAME_WARN for KMSAN by default x86/purgatory: disable KMSAN instrumentation mm: kmsan: export kmsan_copy_page_meta() mm: migrate: fix return value if all subpages of THPs are migrated successfully mm/uffd: fix vma check on userfault for wp mm: prep_compound_tail() clear page->private mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs mm/page_isolation: fix clang deadcode warning fs/ext4/super.c: remove unused `deprecated_msg' ipc/msg.c: fix percpu_counter use after free memory tier, sysfs: rename attribute "nodes" to "nodelist" MAINTAINERS: git://github.com -> https://github.com for nilfs2 mm/kmemleak: prevent soft lockup in kmemleak_scan()'s object iteration loops ...
-
- 29 Oct, 2022 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Fix a case of rescheduling with user access unlocked, when preempt is enabled. - A follow-up fix for a recent fix, which could lead to IRQ state assertions firing incorrectly. - Two fixes for lockdep warnings seen when using kfence with the Hash MMU. - Two fixes for preempt warnings seen when using the Hash MMU. - Two fixes for the VAS coprocessor mechanism used on pseries. - Prevent building some of our older KVM backends when CONTEXT_TRACKING_USER is enabled, as it's known to cause crashes. - A couple of fixes for issues seen with PMU NMIs. Thanks to Nicholas Piggin, Guenter Roeck, Frederic Barrat Haren Myneni, Sachin Sant, and Samuel Holland. * tag 'powerpc-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/64s/interrupt: Fix clear of PACA_IRQS_HARD_DIS when returning to soft-masked context powerpc/64s/interrupt: Perf NMI should not take normal exit path powerpc/64/interrupt: Prevent NMI PMI causing a dangerous warning KVM: PPC: BookS PR-KVM and BookE do not support context tracking powerpc: Fix reschedule bug in KUAP-unlocked user copy powerpc/64s: Fix hash__change_memory_range preemption warning powerpc/64s: Disable preemption in hash lazy mmu mode powerpc/64s: make linear_map_hash_lock a raw spinlock powerpc/64s: make HPTE lock and native_tlbie_lock irq-safe powerpc/64s: Add lockdep for HPTE lock powerpc/pseries: Use lparcfg to reconfig VAS windows for DLPAR CPU powerpc/pseries/vas: Add VAS IRQ primary handler
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull s390 fixes from Vasily Gorbik: - Remove outdated linux390 link from MAINTAINERS - Add few missing EX_TABLE entries to inline assemblies - Fix raw data collection for pai_ext PMU - Add kernel image secure boot trailer for future firmware versions - Fix out-of-bounds access on cio_ignore free - Fix memory allocation of mdev_types array in vfio-ap * tag 's390-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/vfio-ap: Fix memory allocation for mdev_types array s390/cio: fix out-of-bounds access on cio_ignore free s390/pai: fix raw data collection for PMU pai_ext s390/boot: add secure boot trailer s390/pci: add missing EX_TABLE entries to __pcistg_mio_inuser()/__pcilg_mio_inuser() s390/futex: add missing EX_TABLE entry to __futex_atomic_op() s390/uaccess: add missing EX_TABLE entries to __clear_user() MAINTAINERS: remove outdated linux390 link
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Palmer Dabbelt: - A fix for a build warning in the jump_label code - One of the git://github -> https://github cleanups, for the SiFive drivers - A fix for the kasan initialization code, this still likely warrants some cleanups but that's a bigger problem and at least this fixes the crashes in the short term - A pair of fixes for extension support detection on mixed LLVM/GNU toolchains - A fix for a runtime warning in the /proc/cpuinfo code * tag 'riscv-for-linus-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Fix /proc/cpuinfo cpumask warning riscv: fix detection of toolchain Zihintpause support riscv: fix detection of toolchain Zicbom support riscv: mm: add missing memcpy in kasan_init MAINTAINERS: git://github.com -> https://github.com for sifive riscv: jump_label: mark arguments as const to satisfy asm constraints
-
- 28 Oct, 2022 32 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull ACPI and device properties fixes from Rafael Wysocki: "These fix device properties documentation and the ACPI PCC code, add a new IRQ override quirk for resource handling and add one more item to the list of device IDs to be ignored when returned by _DEP. Specifics: - Fix the documentation of the *_match_string() family of functions to properly cover the return value (Andy Shevchenko) - Fix a possible integer overflow during multiplication in the ACPI PCC code (Manank Patel) - Make the ACPI device resources code skip IRQ override on Asus Vivobook S5602ZA (Tamim Khan) - Add LATT2021 to the list of device IDs that are ignored when returned by _DEP, because there are no drivers for them in the kernel and no plans to add such drivers (Hans de Goede)" * tag 'acpi-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: scan: Add LATT2021 to acpi_ignore_dep_ids[] ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA ACPI: PCC: Fix unintentional integer overflow device property: Fix documentation for *_match_string() APIs
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fixes from Rafael Wysocki: "These make the intel_pstate driver work as expected on all hybrid platforms to date (regardless of possible platform firmware issues), fix hybrid sleep on systems using suspend-to-idle by default, make the generic power domains code handle disabled idle states properly and update pm-graph. Specifics: - Make intel_pstate use what is known about the hardware instead of relying on information from the platform firmware (ACPI CPPC in particular) to establish the relationship between the HWP CPU performance levels and frequencies on all hybrid platforms available to date (Rafael Wysocki) - Allow hybrid sleep to use suspend-to-idle as a system suspend method if it is the current suspend method of choice (Mario Limonciello) - Fix handling of unavailable/disabled idle states in the generic power domains code (Sudeep Holla) - Update the pm-graph suite of utilities to version 5.10 which is fixes-mostly and does not add any new features (Todd Brandt)" * tag 'pm-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: domains: Fix handling of unavailable/disabled idle states pm-graph v5.10 cpufreq: intel_pstate: hybrid: Use known scaling factor for P-cores cpufreq: intel_pstate: Read all MSRs on the target CPU PM: hibernate: Allow hybrid sleep to work with s2idle
-
Jean-Philippe Brucker authored
While reworking the archrandom handling, commit d349ab99 ("random: handle archrandom with multiple longs") switched to the non-early archrandom helpers in random_init(), which broke initialization of the entropy pool from the arm64 random generator. Indeed at that point the arm64 CPU features, which verify that all CPUs have compatible capabilities, are not finalized so arch_get_random_seed_longs() is unsuccessful. Instead random_init() should use the _early functions, which check only the boot CPU on arm64. On other architectures the _early functions directly call the normal ones. Fixes: d349ab99 ("random: handle archrandom with multiple longs") Cc: stable@vger.kernel.org Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
-
Sebastian Andrzej Siewior authored
lru_gen_add_mm() has been added within an IRQ-off region in the commit mentioned below. The other invocations of lru_gen_add_mm() are not within an IRQ-off region. The invocation within IRQ-off region is problematic on PREEMPT_RT because the function is using a spin_lock_t which must not be used within IRQ-disabled regions. The other invocations of lru_gen_add_mm() occur while task_struct::alloc_lock is acquired. Move lru_gen_add_mm() after interrupts are enabled and before task_unlock(). Link: https://lkml.kernel.org/r/20221026134830.711887-1-bigeasy@linutronix.de Fixes: bd74fdae ("mm: multi-gen LRU: support page table walks") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Yu Zhao <yuzhao@google.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Eric W . Biederman" <ebiederm@xmission.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Lukas Bulwahn authored
Before the do-while loop in mtree_range_walk(), the variables next, min, max need to be initialized. The variables last, prev_min and prev_max are set within the loop body before they are eventually used after exiting the loop body. As it is a do-while loop, the loop body is executed at least once, so the variables last, prev_min and prev_max do not need to be initialized before the loop body. Remove unneeded initialization of last and prev_min. The needless initialization was reported by clang-analyzer as Dead Stores. As the compiler already identifies these assignments as unneeded, it optimizes the assignments away. Hence: No functional change. No change in object code. Link: https://lkml.kernel.org/r/20221026120029.12555-2-lukas.bulwahn@gmail.comSigned-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Liam Howlett authored
When using the VMA iterator, the final execution will set the variable 'next' to NULL which causes the function to fail out. Restore the break in the loop to exit the VMA iterator early without clearing NULL fixes the issue. Link: https://lore.kernel.org/lkml/29344.1666681759@jrobl/ Link: https://lkml.kernel.org/r/20221025161222.2634030-1-Liam.Howlett@oracle.com Fixes: 763ecb03 (mm: remove the vma linked list) Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com> Reported-by: "J. R. Okajima" <hooanon05g@gmail.com> Tested-by: "J. R. Okajima" <hooanon05g@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Ira Weiny authored
The kernel test robot flagged a recursive lock as a result of a conversion from kmap_atomic() to kmap_local_folio()[Link] The cause was due to the code depending on the kmap_atomic() side effect of disabling page faults. In that case the code expects the fault to fail and take the fallback case. git archaeology implied that the recursion may not be an actual bug.[1] However, depending on the implementation of the mmap_lock and the condition of the call there may still be a deadlock.[2] So this is not purely a lockdep issue. Considering a single threaded call stack there are 3 options. 1) Different mm's are in play (no issue) 2) Readlock implementation is recursive and same mm is in play (no issue) 3) Readlock implementation is _not_ recursive (issue) The mmap_lock is recursive so with a single thread there is no issue. However, Matthew pointed out a deadlock scenario when you consider additional process' and threads thusly. "The readlock implementation is only recursive if nobody else has taken a write lock. If you have a multithreaded process, one of the other threads can call mmap() and that will prevent recursion (due to fairness). Even if it's a different process that you're trying to acquire the mmap read lock on, you can still get into a deadly embrace. eg: process A thread 1 takes read lock on own mmap_lock process A thread 2 calls mmap, blocks taking write lock process B thread 1 takes page fault, read lock on own mmap lock process B thread 2 calls mmap, blocks taking write lock process A thread 1 blocks taking read lock on process B process B thread 1 blocks taking read lock on process A Now all four threads are blocked waiting for each other." Regardless using pagefault_disable() ensures that no matter what locking implementation is used a deadlock will not occur. Add an explicit pagefault_disable() and a big comment to explain this for future souls looking at this code. [1] https://lore.kernel.org/all/Y1MymJ%2FINb45AdaY@iweiny-desk3/ [2] https://lore.kernel.org/lkml/Y1bXBtGTCym77%2FoD@casper.infradead.org/ Link: https://lkml.kernel.org/r/20221025220108.2366043-1-ira.weiny@intel.com Link: https://lore.kernel.org/r/202210211215.9dc6efb5-yujie.liu@intel.com Fixes: 7a7256d5 ("shmem: convert shmem_mfill_atomic_pte() to use a folio") Signed-off-by: Ira Weiny <ira.weiny@intel.com> Reported-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reported-by: kernel test robot <yujie.liu@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Peter Xu <peterx@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Ira Weiny authored
kmap() and kmap_atomic() are being deprecated in favor of kmap_local_page() which is appropriate for any thread local context.[1] A recent locking bug report with userfaultfd showed that the conversion of the kmap_atomic()'s in those code flows requires care with regard to the prevention of deadlock.[2] git archaeology implied that the recursion may not be an actual bug.[3] However, depending on the implementation of the mmap_lock and the condition of the call there may still be a deadlock.[4] So this is not purely a lockdep issue. Considering a single threaded call stack there are 3 options. 1) Different mm's are in play (no issue) 2) Readlock implementation is recursive and same mm is in play (no issue) 3) Readlock implementation is _not_ recursive (issue) The mmap_lock is recursive so with a single thread there is no issue. However, Matthew pointed out a deadlock scenario when you consider additional process' and threads thusly. "The readlock implementation is only recursive if nobody else has taken a write lock. If you have a multithreaded process, one of the other threads can call mmap() and that will prevent recursion (due to fairness). Even if it's a different process that you're trying to acquire the mmap read lock on, you can still get into a deadly embrace. eg: process A thread 1 takes read lock on own mmap_lock process A thread 2 calls mmap, blocks taking write lock process B thread 1 takes page fault, read lock on own mmap lock process B thread 2 calls mmap, blocks taking write lock process A thread 1 blocks taking read lock on process B process B thread 1 blocks taking read lock on process A Now all four threads are blocked waiting for each other." Regardless using pagefault_disable() ensures that no matter what locking implementation is used a deadlock will not occur. Complete kmap conversion in userfaultfd by replacing the kmap() and kmap_atomic() calls with kmap_local_page(). When replacing the kmap_atomic() call ensure page faults continue to be disabled to support the correct fall back behavior and add a comment to inform future souls of the requirement. [1] https://lore.kernel.org/all/20220813220034.806698-1-ira.weiny@intel.com/ [2] https://lore.kernel.org/all/Y1Mh2S7fUGQ%2FiKFR@iweiny-desk3/ [3] https://lore.kernel.org/all/Y1MymJ%2FINb45AdaY@iweiny-desk3/ [4] https://lore.kernel.org/lkml/Y1bXBtGTCym77%2FoD@casper.infradead.org/ [ira.weiny@intel.com: v2] Link: https://lkml.kernel.org/r/20221025220136.2366143-1-ira.weiny@intel.com Link: https://lkml.kernel.org/r/20221024043452.1491677-1-ira.weiny@intel.comSigned-off-by: Ira Weiny <ira.weiny@intel.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Alexander Potapenko authored
Ensure that KMSAN builds replace memset/memcpy/memmove calls with the respective __msan_XXX functions, and that none of the macros are redefined twice. This should allow building kernel with both CONFIG_KMSAN and CONFIG_FORTIFY_SOURCE. Link: https://lkml.kernel.org/r/20221024212144.2852069-5-glider@google.com Link: https://github.com/google/kmsan/issues/89Signed-off-by: Alexander Potapenko <glider@google.com> Reported-by: Tamas K Lengyel <tamas.lengyel@zentific.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Alexander Potapenko authored
User access macros must ensure their arguments are evaluated only once if they are used more than once in the macro body. Adding instrument_put_user() to __put_user_size() resulted in double evaluation of the `ptr` argument, which led to correctness issues when performing e.g. unsafe_put_user(..., p++, ...). To fix those issues, evaluate the `ptr` argument of __put_user_size() at the beginning of the macro. Link: https://lkml.kernel.org/r/20221024212144.2852069-4-glider@google.com Fixes: 888f84a6 ("x86: asm: instrument usercopy in get_user() and put_user()") Signed-off-by: Alexander Potapenko <glider@google.com> Reported-by: youling257 <youling257@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Alexander Potapenko authored
KMSAN adds a lot of instrumentation to the code, which results in increased stack usage (up to 2048 bytes and more in some cases). It's hard to predict how big the stack frames can be, so we disable the warnings for KMSAN instead. Link: https://lkml.kernel.org/r/20221024212144.2852069-3-glider@google.com Link: https://github.com/google/kmsan/issues/89Signed-off-by: Alexander Potapenko <glider@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Alexander Potapenko authored
The stand-alone purgatory.ro does not contain the KMSAN runtime, therefore it can't be built with KMSAN compiler instrumentation. Link: https://lkml.kernel.org/r/20221024212144.2852069-2-glider@google.com Link: https://github.com/google/kmsan/issues/89Signed-off-by: Alexander Potapenko <glider@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Alexander Potapenko authored
Certain modules call copy_user_highpage(), which calls kmsan_copy_page_meta() under KMSAN, so we need to export the latter. Link: https://lkml.kernel.org/r/20221024212144.2852069-1-glider@google.com Link: https://github.com/google/kmsan/issues/89 Fixes: b073d7f8 ("mm: kmsan: maintain KMSAN metadata for page operations") Signed-off-by: Alexander Potapenko <glider@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Baolin Wang authored
During THP migration, if THPs are not migrated but they are split and all subpages are migrated successfully, migrate_pages() will still return the number of THP pages that were not migrated. This will confuse the callers of migrate_pages(). For example, the longterm pinning will failed though all pages are migrated successfully. Thus we should return 0 to indicate that all pages are migrated in this case Link: https://lkml.kernel.org/r/de386aa864be9158d2f3b344091419ea7c38b2f7.1666599848.git.baolin.wang@linux.alibaba.com Fixes: b5bade97 ("mm: migrate: fix the return value of migrate_pages()") Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Yang Shi <shy828301@gmail.com> Cc: David Hildenbrand <david@redhat.com> Cc: "Huang, Ying" <ying.huang@intel.com> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Peter Xu authored
We used to have a report that pte-marker code can be reached even when uffd-wp is not compiled in for file memories, here: https://lore.kernel.org/all/YzeR+R6b4bwBlBHh@x1n/T/#u I just got time to revisit this and found that the root cause is we simply messed up with the vma check, so that for !PTE_MARKER_UFFD_WP system, we will allow UFFDIO_REGISTER of MINOR & WP upon shmem as the check was wrong: if (vm_flags & VM_UFFD_MINOR) return is_vm_hugetlb_page(vma) || vma_is_shmem(vma); Where we'll allow anything to pass on shmem as long as minor mode is requested. Axel did it right when introducing minor mode but I messed it up in b1f9e876 when moving code around. Fix it. Link: https://lkml.kernel.org/r/20221024193336.1233616-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20221024193336.1233616-2-peterx@redhat.com Fixes: b1f9e876 ("mm/uffd: enable write protection for shmem & hugetlbfs") Signed-off-by: Peter Xu <peterx@redhat.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Nadav Amit <nadav.amit@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Hugh Dickins authored
Although page allocation always clears page->private in the first page or head page of an allocation, it has never made a point of clearing page->private in the tails (though 0 is often what is already there). But now commit 71e2d666 ("mm/huge_memory: do not clobber swp_entry_t during THP split") issues a warning when page_tail->private is found to be non-0 (unless it's swapcache). Change that warning to dump page_tail (which also dumps head), instead of just the head: so far we have seen dead000000000122, dead000000000003, dead000000000001 or 0000000000000002 in the raw output for tail private. We could just delete the warning, but today's consensus appears to want page->private to be 0, unless there's a good reason for it to be set: so now clear it in prep_compound_tail() (more general than just for THP; but not for high order allocation, which makes no pass down the tails). Link: https://lkml.kernel.org/r/1c4233bb-4e4d-5969-fbd4-96604268a285@google.com Fixes: 71e2d666 ("mm/huge_memory: do not clobber swp_entry_t during THP split") Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Mel Gorman <mgorman@techsingularity.net> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Rik van Riel authored
A common use case for hugetlbfs is for the application to create memory pools backed by huge pages, which then get handed over to some malloc library (eg. jemalloc) for further management. That malloc library may be doing MADV_DONTNEED calls on memory that is no longer needed, expecting those calls to happen on PAGE_SIZE boundaries. However, currently the MADV_DONTNEED code rounds up any such requests to HPAGE_PMD_SIZE boundaries. This leads to undesired outcomes when jemalloc expects a 4kB MADV_DONTNEED, but 2MB of memory get zeroed out, instead. Use of pre-built shared libraries means that user code does not always know the page size of every memory arena in use. Avoid unexpected data loss with MADV_DONTNEED by rounding up only to PAGE_SIZE (in do_madvise), and rounding down to huge page granularity. That way programs will only get as much memory zeroed out as they requested. Link: https://lkml.kernel.org/r/20221021192805.366ad573@imladris.surriel.com Fixes: 90e7e7f5 ("mm: enable MADV_DONTNEED for hugetlb mappings") Signed-off-by: Rik van Riel <riel@surriel.com> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Cc: David Hildenbrand <david@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Maria Yu authored
When !CONFIG_VM_BUG_ON, there is warning of clang-analyzer-deadcode.DeadStores: Value stored to 'mt' during its initialization is never read. Link: https://lkml.kernel.org/r/20221021101555.7992-2-quic_aiquny@quicinc.comSigned-off-by: Maria Yu <quic_aiquny@quicinc.com> Cc: David Hildenbrand <david@redhat.com> Cc: Doug Berger <opendmb@gmail.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Zi Yan <ziy@nvidia.com> Cc: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Andrew Morton authored
fs/ext4/super.c:1744:19: warning: 'deprecated_msg' defined but not used [-Wunused-const-variable=] Reported-by: kernel test robot <lkp@intel.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Andrew Morton authored
These percpu counters are referenced in free_ipcs->freeque, so destroy them later. Fixes: 72d1e611 ("ipc/msg: mitigate the lock contention with percpu counter") Reported-by: syzbot+96e659d35b9d6b541152@syzkaller.appspotmail.com Tested-by: Mark Rutland <mark.rutland@arm.com> Cc: Jiebin Sun <jiebin.sun@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Huang Ying authored
In sysfs, we use attribute name "cpumap" or "cpus" for cpu mask and "cpulist" or "cpus_list" for cpu list. For example, in my system, $ cat /sys/devices/system/node/node0/cpumap f,ffffffff $ cat /sys/devices/system/cpu/cpu2/topology/core_cpus 0,00100004 $ cat cat /sys/devices/system/node/node0/cpulist 0-35 $ cat /sys/devices/system/cpu/cpu2/topology/core_cpus_list 2,20 It looks reasonable to use "nodemap" for node mask and "nodelist" for node list. So, rename the attribute to follow the naming convention. Link: https://lkml.kernel.org/r/20221020015122.290097-1-ying.huang@intel.com Fixes: 9832fb87 ("mm/demotion: expose memory tier details via sysfs") Signed-off-by: "Huang, Ying" <ying.huang@intel.com> Acked-by: Wei Xu <weixugc@google.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Yang Shi <shy828301@gmail.com> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Cc: Alistair Popple <apopple@nvidia.com> Cc: Bharata B Rao <bharata@amd.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Hesham Almatary <hesham.almatary@huawei.com> Cc: Jagdish Gediya <jvgediya.oss@gmail.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Tim Chen <tim.c.chen@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
git://github.comhttps://github.comPalmer Dabbelt authored
Github deprecated the git:// links about a year ago, so let's move to the https:// URLs instead. Link: https://lkml.kernel.org/r/20221020024255.5000-1-konishi.ryusuke@gmail.com Link: https://github.blog/2021-09-01-improving-git-protocol-security-github/ Link: https://lkml.kernel.org/r/20221013214638.30933-1-palmer@rivosinc.comSigned-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Waiman Long authored
Commit 6edda04c ("mm/kmemleak: prevent soft lockup in first object iteration loop of kmemleak_scan()") adds cond_resched() in the first object iteration loop of kmemleak_scan(). However, it turns that the 2nd objection iteration loop can still cause soft lockup to happen in some cases. So add a cond_resched() call in the 2nd and 3rd loops as well to prevent that and for completeness. Link: https://lkml.kernel.org/r/20221020175619.366317-1-longman@redhat.com Fixes: 6edda04c ("mm/kmemleak: prevent soft lockup in first object iteration loop of kmemleak_scan()") Signed-off-by: Waiman Long <longman@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Phillip Lougher authored
Fix a buffer release race condition, where the error value was used after release. Link: https://lkml.kernel.org/r/20221020223616.7571-4-phillip@squashfs.org.uk Fixes: b09a7a03 ("squashfs: support reading fragments in readahead call") Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Reported-by: Marc Miltenberger <marcmiltenberger@gmail.com> Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Cc: Slade Watkins <srw@sladewatkins.net> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Phillip Lougher authored
The readahead code will try to extend readahead to the entire size of the Squashfs data block. But, it didn't take into account that the last block at the end of the file may not be a whole block. In this case, the code would extend readahead to beyond the end of the file, leaving trailing pages. Fix this by only requesting the expected number of pages. Link: https://lkml.kernel.org/r/20221020223616.7571-3-phillip@squashfs.org.uk Fixes: 8fc78b6f ("squashfs: implement readahead") Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Reported-by: Marc Miltenberger <marcmiltenberger@gmail.com> Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Cc: Slade Watkins <srw@sladewatkins.net> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
Phillip Lougher authored
Patch series "squashfs: fix some regressions introduced in the readahead code". This patchset fixes 3 regressions introduced by the recent readahead code changes. The first regression is causing "snaps" to randomly fail after a couple of hours or days, which how the regression came to light. This patch (of 3): If a file isn't a whole multiple of the page size, the last page will have trailing bytes unfilled. There was a mistake in the readahead code which did this. In particular it incorrectly assumed that the last page in the readahead page array (page[nr_pages - 1]) will always contain the last page in the block, which if we're at file end, will be the page that needs to be zero filled. But the readahead code may not return the last page in the block, which means it is unmapped and will be skipped by the decompressors (a temporary buffer used). In this case the zero filling code will zero out the wrong page, leading to data corruption. Fix this by by extending the "page actor" to return the last page if present, or NULL if a temporary buffer was used. Link: https://lkml.kernel.org/r/20221020223616.7571-1-phillip@squashfs.org.uk Link: https://lkml.kernel.org/r/20221020223616.7571-2-phillip@squashfs.org.uk Fixes: 8fc78b6f ("squashfs: implement readahead") Link: https://lore.kernel.org/lkml/b0c258c3-6dcf-aade-efc4-d62a8b3a1ce2@alu.unizg.hr/Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk> Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Tested-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Tested-by: Slade Watkins <srw@sladewatkins.net> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Reported-by: Marc Miltenberger <marcmiltenberger@gmail.com> Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linuxLinus Torvalds authored
Pull RTC fixes from Alexandre Belloni: "Fix wakeup support that broke on multiple platforms" * tag 'rtc-6.1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: rtc: cmos: fix build on non-ACPI platforms rtc: cmos: Fix wake alarm breakage
-
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds authored
Pull MMC fixes from Ulf Hansson: "MMC core: - Cancel recovery work on cleanup to avoid NULL pointer dereference - Fix error path in the read/write error recovery path - Fix kernel panic when remove non-standard SDIO card - Fix WRITE_ZEROES handling for CQE MMC host: - sdhci_am654: Fixup Kconfig dependency for REGMAP_MMIO - sdhci-esdhc-imx: Avoid warning of misconfigured bus-width - sdhci-pci: Disable broken HS400 ES mode for ASUS BIOS on Jasper Lake" * tag 'mmc-v6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci_am654: 'select', not 'depends' REGMAP_MMIO mmc: core: Fix WRITE_ZEROES CQE handling mmc: core: Fix kernel panic when remove non-standard SDIO card mmc: sdhci-pci-core: Disable ES for ASUS BIOS on Jasper Lake mmc: sdhci-esdhc-imx: Propagate ESDHC_FLAG_HS400* only on 8bit bus mmc: queue: Cancel recovery work on cleanup mmc: block: Remove error check of hw_reset on reset
-
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linuxLinus Torvalds authored
Pull mtd fixes from Miquel Raynal: "MTD core: - partitions: Add missing of_node_get() in dynamic partitions code Parser drivers: - bcm47xxpart: Fix halfblock reads Raw NAND controller drivers: - marvell: Use correct logic for nand-keep-config - tegra: Fix PM disable depth imbalance in probe - intel: Add missing of_node_put() in ebu_nand_probe() SPI-NOR core changes: - Ignore -ENOTSUPP in spi_nor_init()" * tag 'mtd/fixes-for-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: parsers: bcm47xxpart: Fix halfblock reads mtd: rawnand: marvell: Use correct logic for nand-keep-config mtd: rawnand: tegra: Fix PM disable depth imbalance in probe mtd: rawnand: intel: Add missing of_node_put() in ebu_nand_probe() mtd: core: add missing of_node_get() in dynamic partitions code mtd: spi-nor: core: Ignore -ENOTSUPP in spi_nor_init()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound fixes from Takashi Iwai: "A collection of small fixes: - fixes for regressions by the recent ALSA control hash usages - fixes for UAF with del_timer() at removals in a few drivers - char signedness fixes - a few memory leak fixes in error paths - device-specific fixes / quirks for Intel SOF, AMD, HD-audio, USB-audio, and various ASoC codecs" * tag 'sound-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (50 commits) ALSA: aoa: Fix I2S device accounting ALSA: Use del_timer_sync() before freeing timer ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() ALSA: rme9652: use explicitly signed char ALSA: au88x0: use explicitly signed char ALSA: hda/realtek: Add another HP ZBook G9 model quirks ALSA: usb-audio: Add quirks for M-Audio Fast Track C400/600 ASoC: SOF: Intel: hda-codec: fix possible memory leak in hda_codec_device_init() ASoC: amd: yc: Add Lenovo Thinkbook 14+ 2022 21D0 to quirks table ASoC: Intel: Skylake: fix possible memory leak in skl_codec_device_init() ALSA: ac97: Use snd_ctl_rename() to rename a control ALSA: ca0106: Use snd_ctl_rename() to rename a control ALSA: emu10k1: Use snd_ctl_rename() to rename a control ALSA: hda/realtek: Use snd_ctl_rename() to rename a control ALSA: usb-audio: Use snd_ctl_rename() to rename a control ALSA: control: add snd_ctl_rename() ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() ASoC: SOF: Intel: pci-tgl: fix ADL-N descriptor ASoC: qcom: lpass-cpu: Mark HDMI TX parity register as volatile ASoC: amd: yc: Adding Lenovo ThinkBook 14 Gen 4+ ARA and Lenovo ThinkBook 16 Gen 4+ ARA to the Quirks List ...
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Regularly scheduled fixes for drm, live from a Red Hat office for the first time in a while. The core has two fixes, one for scheduler leak and one for aperture uninit read. Otherwise a single bridge fix, and msm, amdgpu/kfd and i915 have a set of fixes each. sched: - Stop leaking fences when killing a sched entity. aperture: - Avoid uninitialized read in aperture_remove_conflicting_pci_device() bridge: - Fix HPD on bridge/ps8640. msm: - Fix shrinker deadlock - Fix crash during suspend after unbind - Fix IRQ lifetime issues - Fix potential memory corruption with too many bridges - Fix memory corruption on GPU state capture amdgpu: - Stable pstate fix - SMU 13.x updates - SR-IOV fixes - PCI AER fix - GC 11.x fixes - Display fixes - Expose IMU firmware version for debugging - Plane modifier fix - S0i3 fix amdkfd: - Fix possible memory leak - Fix GC 10.x cache info reporting i915: - Extend Wa_1607297627 to Alderlake-P - Keep PCI autosuspend control 'on' by default on all dGPU - Reset frl trained flag before restarting FRL training" * tag 'drm-fixes-2022-10-28' of git://anongit.freedesktop.org/drm/drm: (39 commits) fbdev/core: Avoid uninitialized read in aperture_remove_conflicting_pci_device() drm/amdgpu: disallow gfxoff until GC IP blocks complete s2idle resume drm/scheduler: fix fence ref counting drm/amd/display: Revert logic for plane modifiers drm/amdkfd: correct the cache info for gfx1036 drm/amdkfd: update gfx1037 Lx cache setting drm/amdgpu: skip mes self test for gc 11.0.3 in recover drm/amd: Add IMU fw version to fw version queries drm/amd/display: Don't return false if no stream drm/amd/display: Remove wrong pipe control lock drm/amd/pm: allow gfxoff on gc_11_0_3 drm/amdkfd: Fix memory leak in kfd_mem_dmamap_userptr() drm/amdgpu: Remove ATC L2 access for MMHUB 2.1.x drm/i915/dp: Reset frl trained flag before restarting FRL training drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU drm/i915: Extend Wa_1607297627 to Alderlake-P drm/amdgpu: Adjust MES polling timeout for sriov drm/amd/pm: update driver-if header for smu_v13_0_10 drm/amdgpu: fix pstate setting issue drm/bridge: ps8640: Add back the 50 ms mystery delay after HPD ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fix from Herbert Xu: "Fix an alignment crash in x86/polyval" * tag 'v6.1-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: x86/polyval - Fix crashes when keys are not 16-byte aligned
-