aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-28net: remove SOCK_SUPPORT_ZC from sockmapPavel Begunkov4-8/+15
sockmap replaces ->sk_prot with its own callbacks, we should remove SOCK_SUPPORT_ZC as the new proto doesn't support msghdr::ubuf_info. Cc: <[email protected]> # 6.0 Reported-by: Jakub Kicinski <[email protected]> Fixes: e993ffe3da4bc ("net: flag sockets supporting msghdr originated zerocopy") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28udp: advertise ipv6 udp support for msghdr::ubuf_infoPavel Begunkov1-0/+1
Mark udp ipv6 as supporting msghdr::ubuf_info. In the original commit SOCK_SUPPORT_ZC was supposed to be set by a udp_init_sock() call from udp6_init_sock(), but d38afeec26ed4 ("tcp/udp: Call inet6_destroy_sock() in IPv6 ...") removed it and so ipv6 udp misses the flag. Cc: <[email protected]> # 6.0 Fixes: e993ffe3da4bc ("net: flag sockets supporting msghdr originated zerocopy") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28enic: MAINTAINERS: Update enic maintainersGovindarajulu Varadarajan1-1/+1
Update enic maintainers. Signed-off-by: Govindarajulu Varadarajan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28net: openvswitch: add missing .resv_start_opJakub Kicinski1-0/+1
I missed one of the families in OvS when annotating .resv_start_op. This triggers the warning added in commit ce48ebdd5651 ("genetlink: limit the use of validation workarounds to old ops"). Reported-by: [email protected] Fixes: 9c5d03d36251 ("genetlink: start to validate reserved header bytes") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28netlink: hide validation union fields from kdocJakub Kicinski1-13/+18
Mark the validation fields as private, users shouldn't set them directly and they are too complicated to explain in a more succinct way (there's already a long explanation in the comment above). The strict_start_type field is set directly and has a dedicated comment so move that above the "private" section. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28Merge tag 's390-6.1-3' of ↵Linus Torvalds8-29/+24
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux 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
2022-10-28Merge tag 'riscv-for-linus-6.1-rc3' of ↵Linus Torvalds7-15/+30
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux 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
2022-10-28Merge tag 'acpi-6.1-rc3' of ↵Linus Torvalds4-3/+11
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 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
2022-10-28Merge tag 'pm-6.1-rc3' of ↵Linus Torvalds6-209/+170
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 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
2022-10-28fortify: Capture __bos() results in const temp varsKees Cook1-4/+9
In two recent run-time memcpy() bound checking bug reports (NFS[1] and JFS[2]), the _detection_ was working correctly (in the sense that the requested copy size was larger than the destination field size), but the _warning text_ was showing the destination field size as SIZE_MAX ("unknown size"). This should be impossible, since the detection function will explicitly give up if the destination field size is unknown. For example, the JFS warning was: memcpy: detected field-spanning write (size 132) of single field "ip->i_link" at fs/jfs/namei.c:950 (size 18446744073709551615) Other cases of this warning (e.g.[3]) have reported correctly, and the reproducer only happens under GCC (at least 10.2 and 12.1), so this currently appears to be a GCC bug. Explicitly capturing the __builtin_object_size() results in const temporary variables fixes the report. For example, the JFS reproducer now correctly reports the field size (128): memcpy: detected field-spanning write (size 132) of single field "ip->i_link" at fs/jfs/namei.c:950 (size 128) Examination of the .text delta (which is otherwise identical), shows the literal value used in the report changing: - mov $0xffffffffffffffff,%rcx + mov $0x80,%ecx [1] https://lore.kernel.org/lkml/[email protected]/ [2] https://syzkaller.appspot.com/bug?id=23d613df5259b977dac1696bec77f61a85890e3d [3] https://lore.kernel.org/all/[email protected]/ Cc: "Dr. David Alan Gilbert" <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2022-10-29random: use arch_get_random*_early() in random_init()Jean-Philippe Brucker1-2/+2
While reworking the archrandom handling, commit d349ab99eec7 ("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: d349ab99eec7 ("random: handle archrandom with multiple longs") Cc: [email protected] Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-10-28tools/nolibc/string: Fix memcmp() implementationRasmus Villemoes1-2/+2
The C standard says that memcmp() must treat the buffers as consisting of "unsigned chars". If char happens to be unsigned, the casts are ok, but then obviously the c1 variable can never contain a negative value. And when char is signed, the casts are wrong, and there's still a problem with using an 8-bit quantity to hold the difference, because that can range from -255 to +255. For example, assuming char is signed, comparing two 1-byte buffers, one containing 0x00 and another 0x80, the current implementation would return -128 for both memcmp(a, b, 1) and memcmp(b, a, 1), whereas one of those should of course return something positive. Signed-off-by: Rasmus Villemoes <[email protected]> Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Cc: [email protected] # v5.0+ Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2022-10-28tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12Willy Tarreau1-5/+8
When built at -Os, gcc-12 recognizes an strlen() pattern in nolibc_strlen() and replaces it with a jump to strlen(), which is not defined as a symbol and breaks compilation. Worse, when the function is called strlen(), the function is simply replaced with a jump to itself, hence becomes an infinite loop. One way to avoid this is to always set -ffreestanding, but the calling code doesn't know this and there's no way (either via attributes or pragmas) to globally enable it from include files, effectively leaving a painful situation for the caller. Alexey suggested to place an empty asm() statement inside the loop to stop gcc from recognizing a well-known pattern, which happens to work pretty fine. At least it allows us to make sure our local definition is not replaced with a self jump. The function only needs to be renamed back to strlen() so that the symbol exists, which implies that nolibc_strlen() which is used on variable strings has to be declared as a macro that points back to it before the strlen() macro is redifined. It was verified to produce valid code with gcc 3.4 to 12.1 at different optimization levels, and both with constant and variable strings. In case this problem surfaces again in the future, an alternate approach consisting in adding an optimize("no-tree-loop-distribute-patterns") function attribute for gcc>=12 worked as well but is less pretty. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Fixes: 96980b833a21 ("tools/nolibc/string: do not use __builtin_strlen() at -O0") Cc: "Paul E. McKenney" <[email protected]> Cc: Alexey Dobriyan <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2022-10-28mm: multi-gen LRU: move lru_gen_add_mm() out of IRQ-off regionSebastian Andrzej Siewior1-1/+1
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/[email protected] Fixes: bd74fdaea1460 ("mm: multi-gen LRU: support page table walks") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Acked-by: Yu Zhao <[email protected]> Cc: Al Viro <[email protected]> Cc: "Eric W . Biederman" <[email protected]> Cc: Kees Cook <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28lib: maple_tree: remove unneeded initialization in mtree_range_walk()Lukas Bulwahn1-2/+2
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/[email protected] Signed-off-by: Lukas Bulwahn <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mmap: fix remap_file_pages() regressionLiam Howlett1-0/+3
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/[email protected] Fixes: 763ecb035029 (mm: remove the vma linked list) Signed-off-by: Liam R. Howlett <[email protected]> Reported-by: "J. R. Okajima" <[email protected]> Tested-by: "J. R. Okajima" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/shmem: ensure proper fallback if page faultsIra Weiny1-0/+17
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%[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Fixes: 7a7256d5f512 ("shmem: convert shmem_mfill_atomic_pte() to use a folio") Signed-off-by: Ira Weiny <[email protected]> Reported-by: Matthew Wilcox (Oracle) <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Peter Xu <[email protected]> Cc: Andrea Arcangeli <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/userfaultfd: replace kmap/kmap_atomic() with kmap_local_page()Ira Weiny1-4/+21
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/[email protected]/ [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%[email protected]/ [[email protected]: v2] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ira Weiny <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Peter Xu <[email protected]> Cc: Axel Rasmussen <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28x86: fortify: kmsan: fix KMSAN fortify buildsAlexander Potapenko4-6/+44
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/[email protected] Link: https://github.com/google/kmsan/issues/89 Signed-off-by: Alexander Potapenko <[email protected]> Reported-by: Tamas K Lengyel <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28x86: asm: make sure __put_user_size() evaluates pointer onceAlexander Potapenko1-6/+7
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/[email protected] Fixes: 888f84a6da4d ("x86: asm: instrument usercopy in get_user() and put_user()") Signed-off-by: Alexander Potapenko <[email protected]> Reported-by: youling257 <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28Kconfig.debug: disable CONFIG_FRAME_WARN for KMSAN by defaultAlexander Potapenko1-1/+2
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/[email protected] Link: https://github.com/google/kmsan/issues/89 Signed-off-by: Alexander Potapenko <[email protected]> Cc: Kees Cook <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nick Desaulniers <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28x86/purgatory: disable KMSAN instrumentationAlexander Potapenko1-0/+1
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/[email protected] Link: https://github.com/google/kmsan/issues/89 Signed-off-by: Alexander Potapenko <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm: kmsan: export kmsan_copy_page_meta()Alexander Potapenko1-0/+1
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/[email protected] Link: https://github.com/google/kmsan/issues/89 Fixes: b073d7f8aee4 ("mm: kmsan: maintain KMSAN metadata for page operations") Signed-off-by: Alexander Potapenko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm: migrate: fix return value if all subpages of THPs are migrated successfullyBaolin Wang1-0/+7
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: b5bade978e9b ("mm: migrate: fix the return value of migrate_pages()") Signed-off-by: Baolin Wang <[email protected]> Reviewed-by: Alistair Popple <[email protected]> Reviewed-by: Yang Shi <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: "Huang, Ying" <[email protected]> Cc: Zi Yan <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/uffd: fix vma check on userfault for wpPeter Xu1-3/+3
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 b1f9e876862d when moving code around. Fix it. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: b1f9e876862d ("mm/uffd: enable write protection for shmem & hugetlbfs") Signed-off-by: Peter Xu <[email protected]> Cc: Axel Rasmussen <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Nadav Amit <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm: prep_compound_tail() clear page->privateHugh Dickins2-1/+2
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 71e2d666ef85 ("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/[email protected] Fixes: 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") Signed-off-by: Hugh Dickins <[email protected]> Acked-by: Mel Gorman <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfsRik van Riel1-1/+11
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/[email protected] Fixes: 90e7e7f5ef3f ("mm: enable MADV_DONTNEED for hugetlb mappings") Signed-off-by: Rik van Riel <[email protected]> Reviewed-by: Mike Kravetz <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/page_isolation: fix clang deadcode warningMaria Yu1-1/+1
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/[email protected] Signed-off-by: Maria Yu <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Doug Berger <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Zi Yan <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28fs/ext4/super.c: remove unused `deprecated_msg'Andrew Morton1-4/+0
fs/ext4/super.c:1744:19: warning: 'deprecated_msg' defined but not used [-Wunused-const-variable=] Reported-by: kernel test robot <[email protected]> Cc: Theodore Ts'o <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28ipc/msg.c: fix percpu_counter use after freeAndrew Morton1-2/+2
These percpu counters are referenced in free_ipcs->freeque, so destroy them later. Fixes: 72d1e611082e ("ipc/msg: mitigate the lock contention with percpu counter") Reported-by: [email protected] Tested-by: Mark Rutland <[email protected]> Cc: Jiebin Sun <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28memory tier, sysfs: rename attribute "nodes" to "nodelist"Huang Ying2-6/+6
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/[email protected] Fixes: 9832fb87834e2b ("mm/demotion: expose memory tier details via sysfs") Signed-off-by: "Huang, Ying" <[email protected]> Acked-by: Wei Xu <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Reviewed-by: Yang Shi <[email protected]> Reviewed-by: Davidlohr Bueso <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Bharata B Rao <[email protected]> Cc: Dan Williams <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Hesham Almatary <[email protected]> Cc: Jagdish Gediya <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Tim Chen <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28MAINTAINERS: git://github.com -> https://github.com for nilfs2Palmer Dabbelt1-1/+1
Github deprecated the git:// links about a year ago, so let's move to the https:// URLs instead. Link: https://lkml.kernel.org/r/[email protected] Link: https://github.blog/2021-09-01-improving-git-protocol-security-github/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Reported-by: Conor Dooley <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/kmemleak: prevent soft lockup in kmemleak_scan()'s object iteration loopsWaiman Long1-19/+42
Commit 6edda04ccc7c ("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/[email protected] Fixes: 6edda04ccc7c ("mm/kmemleak: prevent soft lockup in first object iteration loop of kmemleak_scan()") Signed-off-by: Waiman Long <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Muchun Song <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28squashfs: fix buffer release race condition in readahead codePhillip Lougher1-2/+3
Fix a buffer release race condition, where the error value was used after release. Link: https://lkml.kernel.org/r/[email protected] Fixes: b09a7a036d20 ("squashfs: support reading fragments in readahead call") Signed-off-by: Phillip Lougher <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Reported-by: Marc Miltenberger <[email protected]> Cc: Dimitri John Ledkov <[email protected]> Cc: Hsin-Yi Wang <[email protected]> Cc: Mirsad Goran Todorovac <[email protected]> Cc: Slade Watkins <[email protected]> Cc: Thorsten Leemhuis <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28squashfs: fix extending readahead beyond end of filePhillip Lougher1-4/+7
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/[email protected] Fixes: 8fc78b6fe24c ("squashfs: implement readahead") Signed-off-by: Phillip Lougher <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Reported-by: Marc Miltenberger <[email protected]> Cc: Dimitri John Ledkov <[email protected]> Cc: Hsin-Yi Wang <[email protected]> Cc: Mirsad Goran Todorovac <[email protected]> Cc: Slade Watkins <[email protected]> Cc: Thorsten Leemhuis <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28squashfs: fix read regression introduced in readahead codePhillip Lougher3-4/+12
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/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: 8fc78b6fe24c ("squashfs: implement readahead") Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Phillip Lougher <[email protected]> Reported-by: Mirsad Goran Todorovac <[email protected]> Tested-by: Mirsad Goran Todorovac <[email protected]> Tested-by: Slade Watkins <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Reported-by: Marc Miltenberger <[email protected]> Cc: Dimitri John Ledkov <[email protected]> Cc: Hsin-Yi Wang <[email protected]> Cc: Thorsten Leemhuis <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28Merge tag 'rtc-6.1-fixes' of ↵Linus Torvalds1-3/+11
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux 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
2022-10-28Merge tag 'mmc-v6.1-rc1' of ↵Linus Torvalds6-29/+57
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc 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
2022-10-28Merge tag 'mtd/fixes-for-6.1-rc3' of ↵Linus Torvalds6-14/+25
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux 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()
2022-10-28Merge tag 'sound-6.1-rc3' of ↵Linus Torvalds45-122/+364
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound 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 ...
2022-10-28Merge tag 'drm-fixes-2022-10-28' of git://anongit.freedesktop.org/drm/drmLinus Torvalds41-161/+421
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 ...
2022-10-28Merge tag 'v6.1-p3' of ↵Linus Torvalds1-5/+14
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 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
2022-10-28efi: efivars: Fix variable writes with unsupported query_variable_store()Ard Biesheuvel1-48/+20
Commit 8a254d90a775 ("efi: efivars: Fix variable writes without query_variable_store()") addressed an issue that was introduced during the EFI variable store refactor, where alternative implementations of the efivars layer that lacked query_variable_store() would no longer work. Unfortunately, there is another case to consider here, which was missed: if the efivars layer is backed by the EFI runtime services as usual, but the EFI implementation predates the introduction of QueryVariableInfo(), we will return EFI_UNSUPPORTED, and this is no longer being dealt with correctly. So let's fix this, and while at it, clean up the code a bit, by merging the check_var_size() routines as well as their callers. Cc: <[email protected]> # v6.0 Fixes: bbc6d2c6ef22 ("efi: vars: Switch to new wrapper layer") Signed-off-by: Ard Biesheuvel <[email protected]> Tested-by: Aditya Garg <[email protected]>
2022-10-28RDMA/qedr: clean up work queue on failure in qedr_alloc_resources()Dan Carpenter1-1/+8
Add a check for if create_singlethread_workqueue() fails and also destroy the work queue on failure paths. Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/Y1gBkDucQhhWj5YM@kili Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2022-10-28RDMA/core: Fix null-ptr-deref in ib_core_cleanup()Chen Zhongjin2-2/+10
KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init(). Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management") Signed-off-by: Chen Zhongjin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2022-10-28ACPI: x86: Add another system to quirk list for forcing StorageD3EnableMario Limonciello1-0/+6
commit 018d6711c26e4 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable") introduced a quirk to allow a system with ambiguous use of _ADR 0 to force StorageD3Enable. Julius Brockmann reports that Inspiron 16 5625 suffers that same symptoms. Add this other system to the list as well. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216440 Reported-and-tested-by: Julius Brockmann <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-10-28MAINTAINERS: Change myself to a maintainerMatti Vaittinen1-2/+2
After some off-list discussion with Marek Vasut and Geert Uytterhoeven and finally a kx022a driver related discussion with Joe Perches https://lore.kernel.org/lkml/[email protected]/ it seems that my status as a reviewer has been wrong. I do look after the ROHM/Kionix drivers I've authored and currently I am also paid to do so as is reflected by the 'S: Supported'. According to Joe, the reviewer entry in MAINTAINERS do not indicate such level of support and having a reviewer supporting an IC is a contradiction. Switch undersigned from a reviewer to a maintainer for IC drivers I am taking care of. Signed-off-by: Matti Vaittinen <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2022-10-28Merge branches 'acpi-resource', 'acpi-pcc' and 'devprop'Rafael J. Wysocki3-3/+10
Merge an IRQ override quirk, an ACPI PCC code fix and a device properties documentation update for 6.1-rc3: - Make the ACPI device resources code skip IRQ override on Asus Vivobook S5602ZA (Tamim Khan). - Fix a possible integer overflow during multiplication in the ACPI PCC code (Manank Patel). - Fix the documentation of the *_match_string() family of functions to properly cover the return value (Andy Shevchenko). * acpi-resource: ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA * acpi-pcc: ACPI: PCC: Fix unintentional integer overflow * devprop: device property: Fix documentation for *_match_string() APIs
2022-10-28Merge branches 'pm-sleep', 'pm-domains' and 'pm-tools'Rafael J. Wysocki5-123/+123
Merge a hiberantion-related fix, a generic power domains code fix and a pm-graph update for 6.1-rc1: - 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). * pm-sleep: PM: hibernate: Allow hybrid sleep to work with s2idle * pm-domains: PM: domains: Fix handling of unavailable/disabled idle states * pm-tools: pm-graph v5.10
2022-10-28blk-mq: Properly init requests from blk_mq_alloc_request_hctx()John Garry1-1/+6
Function blk_mq_alloc_request_hctx() is missing zeroing/init of rq->bio, biotail, __sector, and __data_len members, which blk_mq_alloc_request() has, so duplicate what we do in blk_mq_alloc_request(). Fixes: 1f5bd336b9150 ("blk-mq: add blk_mq_alloc_request_hctx") Signed-off-by: John Garry <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.