| Age | Commit message (Collapse) | Author |
|---|
|
Since the AVX2 optimized RAID6 code uses YMM registers, execute vzeroupper
before returning from it. This is needed to avoid degrading the
performance of any later SSE code that may happen to be executed.
Link: https://lore.kernel.org/20260831212308.213855-1-ebiggers@kernel.org
Fixes: 2c935842bdb4 ("lib/raid6: Add AVX2 optimized gen_syndrome functions")
Fixes: 7056741fd9fc ("lib/raid6: Add AVX2 optimized recovery functions")
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
|
|
Since the AVX optimized XOR code uses YMM registers, execute vzeroupper
before returning from it. This is needed to avoid degrading the
performance of any later SSE code that may happen to be executed.
Link: https://lore.kernel.org/20260831212248.213805-1-ebiggers@kernel.org
Fixes: ea4d26ae24e5 ("raid5: add AVX optimized RAID5 checksumming")
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
|
|
The errseq_t infrastructure (lib/errseq.c) underpins writeback error
reporting but has no regression tests. Its semantics are subtle enough to
have needed fixing before: commit b4678df184b3 ("errseq: Always report a
writeback error once") changed how unseen errors reach new samplers.
Add a KUnit suite covering the documented single-threaded semantics:
- a zeroed errseq_t is the "no error yet" epoch
- errors are recorded, overwrite one another, and both ends of the
valid errno range round-trip exactly
- an error nobody has seen samples as zero, so a check against a
fresh sample still reports it
- errseq_check_and_advance() reports a given error exactly once per
cursor and leaves the cursor in place when nothing has changed
- once an error has been seen, a fresh sample is current and a check
against it reports nothing
- the same error recorded again after being seen is reported again,
even to a cursor that consumed the first occurrence while another
cursor marked the repeat as seen
- independent cursors each observe each error
The lockless behaviour of errseq_t under concurrent updates and the WARN
path for invalid error values are deliberately out of scope.
Tested with ./tools/testing/kunit/kunit.py run, with a kunitconfig
enabling CONFIG_KUNIT=y and CONFIG_ERRSEQ_KUNIT_TEST=y; all 13 tests pass
under ARCH=um.
Link: https://lore.kernel.org/20260812-errseq-kunit-v1-1-312be4c3aa0d@gmail.com
Signed-off-by: Thomas Maarseveen <maarseveent@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Jeff Layton <jlayton@kernel.org>
Cc: David Gow <david@davidgow.net>
|
|
These 7 DECOMPRESS_ options (e.g. DECOMPRESS_GZIP) currently have the
tristate type, but can never be set to M. Their only valid values are Y
and N, making them effectively booleans.
Let's make their types more accurate by changing them to 'bool'. Note
that this is only a code cleanup, there is no functional change.
These bistates were found by kconfirm, a static analysis tool for Kconfig.
Link: https://lore.kernel.org/20260817210311.2142999-1-julianbraha@gmail.com
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Julia Lawall <julia.lawall@inria.fr>
|
|
klist_remove() waits until a node is unreferenced so that its caller can
free the containing object. klist_release() currently publishes
waiter->woken and wakes the waiter before its final accesses to the waiter
and node. klist_remove() can then return, allowing its stack waiter and
the containing object to be freed or reused while klist_release() is still
running. In particular, bus_remove_driver() can free drv->p while
__device_attach() walks the same bus klist with bus_for_each_drv().
On an arm64 Cortex-A72 system, an unpatched 7.2.0-rc3 kernel with
CONFIG_PREEMPT_RT=y and CONFIG_KASAN=y reproduced the bug through the
in-tree I2C/at24 path. KASAN reported a use-after-free in
klist_dec_and_del() reached from klist_next()/bus_for_each_drv() while
at24 was being unregistered.
Clear n_klist and take a task reference before publishing woken. Use
release/acquire accesses for that publication and wake the referenced
task. The task reference keeps the waiter task alive if it returns and
exits before wake_up_process().
Link: https://lore.kernel.org/20260827041708.31682-1-kmehltretter@gmail.com
Fixes: 8b0c250be489 ("[PATCH] add klist_node_attached() to determine if a node is on a list or not.")
Fixes: 210272a28465 ("driver core: Remove completion from struct klist_node")
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Assisted-by: LLM
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
Enabling the (possibly long-running benchmarks) by default may cause a big
delay in boot time in case of built-in tests. However, they can still
safely be enabled by default if all tests are modular, as they would only
run when requested explicitly by the system administrator.
Link: https://lore.kernel.org/64c6e0191bd8ccef0074ffbb09bd0584680d710b.1787584360.git.geert@linux-m68k.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>
|
|
fault_create_debugfs_attr() has always taken an extra dentry reference on
the created directory (attr->dname = dget(dir)) so that fail_dump() could
print the name via %pd from any context. Nothing anywhere in the tree
ever calls dput() on attr->dname.
For callers with a matching teardown, that unmatched reference causes one
dentry plus its attached inode to leak per fault_create_debugfs_attr /
debugfs_remove_recursive cycle. simple_recursive_removal() drops
debugfs's own +1 ref on the child dentry, but the dget()'d ref keeps its
refcount at 1: the dentry ends up unhashed but pinned, and its inode is
never freed.
Boot-once callers (mm/failslab, block/blk-core, etc.) leak exactly once at
init and never destroy the tree, so the impact there is bounded. But
per-lifecycle callers (drivers/nvme, drivers/infiniband/hw/hfi1,
drivers/mmc, drivers/iommu/iommufd, drivers/media, drivers/misc,
drivers/gpu/drm/msm, drivers/crypto, net/sunrpc) leak on every
create/destroy cycle.
We observed this in production: an NVMe/RDMA host repeatedly reconnecting
to a target that rejected the CRTO Property Get went through ~50 nvme
controller create/destroy cycles per second, and dentry and inode_cache
grew by ~13k pinned objects per 240 s -- unrecoverable through
drop_caches. Byte math matched a per-cycle 1-dentry / 1-inode leak from
the "fault_inject" directory dentry.
Fix this by not holding any external reference in fault_attr. Embed the
directory name as a fixed-size char array (FAULT_ATTR_DNAME_LEN, 64 bytes)
inside struct fault_attr, copied by strscpy() at
fault_create_debugfs_attr() time. fail_dump() prints it via %s.
Advantages of an embedded array over kstrdup() + kfree() paired with a new
destroy API:
- Zero API footprint. No new export and no caller changes required:
callers already own their fault_attr's memory and free it when
they are done, and now that suffices.
- No allocation on the create path.
- fault_create_debugfs_attr() cannot fail from the name-copy step.
- No lifetime coupling between attr->dname and debugfs; the string
is valid for exactly as long as the containing struct.
The 64-byte length accommodates every in-tree caller with generous
headroom (the longest current name is "fail_dma_array_full", 19 chars).
The user-visible fail_dump() format changes from "name %pd" to "name %s",
but the printed content is identical -- %pd on the created directory
renders the same string that was passed in as @name.
drivers/infiniband/hw/hfi1/fault.c drops a now-invalid "attr.dname = NULL"
statement; the surrounding kzalloc() already zero-initialises the array.
Link: https://lore.kernel.org/20260821181527.3271414-1-mliang@purestorage.com
Fixes: 6adc4a22f20b ("fault-inject: add ratelimit option")
Signed-off-by: Michael Liang <mliang@purestorage.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Akinbou Mita <akinobu.mita@gmail.com>
Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
cmpxchg_emu_u8() emulates one-byte cmpxchg() in terms of four-byte
cmpxchg() for the architectures lacking native one-byte atomics.
The same architectures also lack native two-byte cmpxchg(), where
such an operation is not supported and either fails to compile via
BUILD_BUG() or fails to link, because the bad pointer sentinels
these architectures declare are never defined.
Add cmpxchg_emu_u16(), the two-byte sibling. It reads the enclosing
word with READ_ONCE(), splices the two target bytes through a union
and loops on cmpxchg() of the full word until the compare succeeds.
Like cmpxchg_emu_u8() it is fully ordered.
Unlike cmpxchg_emu_u8() it casts the old and new values to u16
internally and returns unsigned long, taking the old and new values
as unsigned long, per the suggestion from David Laight. The switch
statements in the architecture macros instantiate every size case,
so a cmpxchg() on a pointer type checks the two-byte case as well,
and a u16 parameter or return would make the macro casts and return
conversions warn there. With unsigned long parameters and return the
call sites need no narrowing casts, pointer exchanges compile warning
free, and the function still compares and returns exactly the 16 bits
the caller asked for, which matches the hardware cmpxchg r16
behaviour where a 16-bit compare only looks at the low 16 bits of
the register.
cmpxchg_emu_u8() keeps returning the old value unmasked, so a caller
that passes a wider old than 8 bits still gets it back as passed,
matching the behaviour the one-byte emulator always had.
The Kconfig symbol gating this file is renamed from
ARCH_NEED_CMPXCHG_1_EMU to ARCH_NEED_CMPXCHG_1_2_EMU, as it now
selects both the one-byte and the two-byte emulation.
[ paulmck: Apply kernel test robot feedback. ]
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: David Laight <david.laight.linux@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@kernel.org>
|
|
The `__chacha20poly1305_decrypt` function does not zeroize the chacha
state, unlike its encrypt counterpart. The regular
`chacha20poly1305_decrypt` function handles this by manually calling
chacha_zeroize_state(). However, `xchacha20poly1305_decrypt` returns
the result directly without clearing the state, leaving the derived
chacha20 subkey on the stack.
Because this function is EXPORT_SYMBOL()ed, this is an ABI robustness
improvement. To ensure consistent and safe cleanup for any future
callers, move the chacha_zeroize_state() call into
`__chacha20poly1305_decrypt()` itself, so the helper cleans up after its
own state just like `__chacha20poly1305_encrypt()` does.
Additionally, moved the src_len check to the callers so the state is not
initialized on invalid inputs, matching the logic in
chacha20poly1305_crypt_sg_inplace().
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
Link: https://patch.msgid.link/20261005150324.5621-1-raizudeen.kerneldev@gmail.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Commit 8530ea3c9b97 ("Kbuild: remove structleak gcc plugin") dropped
the stackinit GCC plugins, so there is no longer a gradient of test
coverage. Collapse the now identical USER_PASS, BYREF_PASS, STRONG_PASS
into a single INSTRUMENTED_PASS definition.
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
Under -ftrivial-auto-var-init= the initialization is emitted where a
variable is declared. A switch dispatch that reaches a case label below
the declaration, or a goto that jumps past it, never reaches that point,
so the variable was left uninitialized.
Commit 9cf016e6b49b ("lib: test_stackinit.c: XFAIL switch variable init
tests") marked test_switch_1_none and test_switch_2_none as expected
failures, noting the test should be retained "so that we can evaluate
compiler fixes". Clang 24 emits the initialization on the jumps that
bypass the declaration, so make the expectation depend on the compiler
version instead of failing unconditionally.
Add test_goto_none as well. The existing cases only cover a declaration
sitting between a switch and its first case label, while the compiler
change covers plain goto too.
GCC continues to initialize only at the declaration, and reports as much
with -Wtrivial-auto-var-init, so it keeps the expected-failure path.
Link: https://github.com/llvm/llvm-project/pull/181937
Link: https://github.com/KSPP/linux/issues/125
Link: https://llvm.org/pr44916
Assisted-by: LLM
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://patch.msgid.link/20261002-kspp-125-v1-1-91286a454fda@google.com
Signed-off-by: Kees Cook <kees@kernel.org>
|
|
ucs2_as_utf8() takes a maxlength argument, which specifies how many
bytes the function is permitted to store into the destination buffer.
The same value is used as an upper bound for the ucs2_strnlen()
invocation, which is reasonable in the general case, as each UCS-2
character produces at least one byte of UTF-8 output, and so there is
never a need to process more than 'maxlength' UCS-2 characters.
However, if the UCS-2 string is not NUL terminated, ucs2_strnlen() may
read past the end of the buffer if 'maxlength' is set to a high value.
Current callers pass UCS-2 strings that are expected to be NUL
terminated, but for processing the load options in the EFI stub, a
version is needed that takes a separate limit argument. So split that
off from the current implementation.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Allow the UCS-2 string library to be reused in the EFI stub, by
suppressing the modinfo data that is usually emitted so that the library
can be built as a module.
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
It's not really the job of library code to WARN and potentially bring
down the system (with panic_on_warn=1) on a condition that is fairly
arbitrary to begin with.
So drop the WARN_ON_ONCE() and tweak the condition so it matches the
actual constraint (count cannot exceed the range of the return type).
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Implement aes_xts_encrypt_arch() and aes_xts_decrypt_arch() with the AES
opcodes, for AES-128 and AES-256, two blocks per iteration. AES-192,
which IEEE 1619 does not specify, and data that is not 8-byte aligned
are left to the generic code.
The tweak is kept as little-endian words, so that multiplying it by x is
a 128-bit shift done with addcc and the VIS3 addxc. A little-endian
store and an ordinary load through a stack slot give it in the byte
order of the data, and the slot is cleared on return. The routines open
a register window, as %g4-%g6 belong to the kernel.
With that, xts-aes-lib no longer has to be kept off SPARC. Register it
there again, with the priority x86 and RISC-V use, so that it also
outranks an xts(ecb-aes-sparc64) instance (priority 300).
On a T7-1 (M7), MiB/s unless noted:
xts(ecb-aes-sparc64) xts-aes-lib
AF_ALG, 64 KiB, AES-128 415 1092
AF_ALG, 64 KiB, AES-256 390 936
dm-crypt on brd, AES-256:
sequential read 1399 2559
sequential write 1472 3480
4 KiB write latency, QD1 (us) 40.6 32.7
dm-crypt now matches aes-cbc-essiv on the same ramdisk.
On a T4-1, AF_ALG AES-256 goes from 238 to 544 MiB/s, and AES-128
from 252 to 616.
Tested with CONFIG_CRYPTO_SELFTESTS_FULL, and against OpenSSL over
random keys, tweaks and lengths, on both machines.
Link: https://github.com/sparclinux/issues/issues/106
Signed-off-by: Stian Halseth <stian@itx.no>
Link: https://patch.msgid.link/20261004192812.4145406-1-stian@itx.no
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
The addition of SipHash to lib/ predated the existence of the
lib/crypto/ directory. Since SipHash is a cryptographic algorithm, move
it from the top-level lib/ directory to lib/crypto/.
(This does mean HalfSipHash comes with it too, as it's in the same
files. But lib/crypto/ still seems like the proper place for both.)
Specifically:
- Move both siphash.c and siphash_kunit.c. Keep the header
<linux/siphash.h> as-is for now.
- Drop the dedicated MAINTAINERS entry for SipHash, as per the
suggestion from Jason
(https://lore.kernel.org/r/asB7QVFMlgKgbje2@zx2c4.com/). The C files
now just fold up to the "CRYPTO LIBRARY" entry. Add the header
explicitly, as it otherwise would be left unmaintained.
- Move the kconfig option that controls the KUnit test. Put
"CRYPTO_LIB" in its name and update the prompt and help text to make
it consistent with the other crypto library test options.
- Enable the KUnit test in lib/crypto/.kunitconfig.
- Link to siphash.rst from the appropriate place in libcrypto-hash.rst.
- Use obj-y instead of lib-y, for consistency with the fact that
currently lib/crypto/ doesn't use kbuild's support for library file
goals. We could keep it as lib-y, but virtually every kernel needs
SipHash support anyway (with vsprintf, printk, IPv4, IPv6, etc.
depending on it) so there is no practical difference in this case.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://patch.msgid.link/20261003162827.155527-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In the AES-CTR and AES-XCTR code that handles a remainder of '4*VL < LEN
< 8*VL', first 4 full vectors are processed, leaving 0 < LEN < 4*VL.
After that, five different cases are handled depending on whether there
are 0, 1, 2, 3, or 4 full vectors remaining. But the case of 4 vectors
is never reached there, making the code handling it unused. Remove it.
With that done, the '.Lxor_tail_partial_vec_3\@' block would be reached
only via an unconditional jump. Therefore, relocate it to the only
place that jumps to it. This allows removing the jump at the end of the
'.Lxor_tail_partial_vec_2\@' block and making it fall through.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20261002034405.49886-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
|
|
The inline lookup and insert helpers receive the rhashtable parameters by
value. With a static const parameter block, key_offset and key_len are
compile-time constants at the call site.
The default comparison throws that information away by reading both fields
back from ht->p. Fixed-size keys consequently load the parameters and call
bcmp() for every object in the bucket, even when the compiler could use
scalar comparisons instead.
The commit "sched_ext: Specialize the DSQ hashtable compare" [1] resulted
in a 2.9x faster DSQ lookup after replacing this path for its u64 key
with a scalar comparison. Doing that through obj_cmpfn requires every
fixed-key user to provide its own callback.
Pass the call-site parameters to rhashtable_compare(), as
rht_key_get_hash() already does. Use them when key_len is a compile-time
constant. Retain the ht->p path for dynamic parameter blocks. A constant
zero key_len continues to take the runtime length from ht->p.key_len.
This specializes the default comparison for all fixed-size users. With
Clang 22 on x86-64, bcmp() disappears from sched_ext, mac80211, NFSd,
TIPC, NFQUEUE, VFS superblock, pidfs, SysV IPC and hardware-breakpoint
table paths. The affected build_policy.o, sta_info.o and nfsd filecache.o
text shrinks by 512, 400 and 352 bytes respectively. Four- and eight-byte
keys become direct scalar comparisons; six-byte MAC addresses become a
four-byte and a two-byte comparison.
Measure the VFS case with ustat() on a mounted ramfs. This exercises
user_get_super() and its super_dev lookup. Across ten interleaved baseline
and patched VM boot pairs, with five 3 million call samples per boot, the
average per-boot median latency drops from 477.2 to 462.6 ns per call, or
3.0%. All ten pairs improved.
No functional change intended.
[1] https://lore.kernel.org/all/20260921171928.1639407-1-usama.arif@linux.dev/
Suggested-by: Mykola Lysenko <nickolay.lysenko@gmail.com>
Signed-off-by: Usama Arif <usama.arif@linux.dev>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Add a KUnit suite for the DIM library that checks the packet, byte,
event and completion rates computed by dim_calc_stats(), including
counter wraparound and windows whose byte or packet count times
USEC_PER_MSEC does not fit in 32 bits. The latter cases fail on 32-bit
architectures without the previous commit.
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
dim_calc_stats() computes the per-millisecond rates as
DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us)
where nbytes is a u32 and USEC_PER_MSEC is 1000L. On 64-bit the product
is done in 64-bit long arithmetic, but on 32-bit architectures long is
32 bits wide and the product wraps as soon as a measurement window
carries more than 4294967 bytes (about 4.3 MB). The same applies to the
packet and completion counts, although those need more than 4.29
million packets or completions per window.
A DIM window spans DIM_NEVENTS (64) events. Drivers count events per
interrupt or per NAPI poll, so under sustained load a window can easily
carry more than 4.3 MB: 64 full NAPI polls of 64 MTU-sized frames are
already 6.2 MB, and drivers such as mtk_eth_soc count one event per
interrupt while NAPI keeps polling with the interrupt masked. On 32-bit
users of the library (for example mtk_eth_soc on MT7621, bcmgenet and
bcmsysport on 32-bit ARM, or virtio_net in a 32-bit guest) bpms then
becomes the product modulo 2^32 divided by the window length, and
net_dim_stats_compare() makes its BETTER/WORSE decisions on a value
that has little to do with the real throughput.
For example, a 1 Gbit/s link at line rate that moves 5 MB in a 40 ms
window gives bpms = 125000 on 64-bit but 17626 on 32-bit, and 5 million
packets in 2 s gives ppms = 353 instead of 2500.
Widen the products to 64 bits and divide with DIV_ROUND_UP_ULL(). The
results are unchanged on 64-bit.
Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
Fixes: 4c4dbb4a7363 ("net/mlx5e: Move dynamic interrupt coalescing code to include/linux")
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
syzbot triggered a warning in __alloc_pages_slowpath(). [0]
ref_tracker_alloc() uses __GFP_NOFAIL if the passed gfp has
__GFP_DIRECT_RECLAIM.
However, cifs_demultiplex_thread() calls memalloc_noreclaim_save()
and its kthread has PF_MEMALLOC.
As commented in __alloc_pages_slowpath(), __GFP_NOFAIL should
not be used for PF_MEMALLOC thread.
if (unlikely(nofail)) {
...
/*
* PF_MEMALLOC request from this context is rather bizarre
* because we cannot reclaim anything and only can loop waiting
* for somebody to do a work for us.
*/
WARN_ON_ONCE(current->flags & PF_MEMALLOC);
Let's avoid using __GFP_NOFAIL for PF_MEMALLOC thread.
[0]:
current->flags & PF_MEMALLOC
WARNING: mm/page_alloc.c:4816 at __alloc_pages_slowpath mm/page_alloc.c:4816 [inline], CPU#0: cifsd/12032
WARNING: mm/page_alloc.c:4816 at __alloc_frozen_pages_noprof+0x1eac/0x3300 mm/page_alloc.c:5449, CPU#0: cifsd/12032
Modules linked in:
CPU: 0 UID: 0 PID: 12032 Comm: cifsd Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__alloc_pages_slowpath mm/page_alloc.c:4816 [inline]
RIP: 0010:__alloc_frozen_pages_noprof+0x1eac/0x3300 mm/page_alloc.c:5449
Code: 38 d0 7c 08 84 d2 0f 85 de 12 00 00 65 48 8b 05 e2 a7 1c 12 c7 84 24 94 00 00 00 00 80 00 00 f6 40 2d 08 0f 84 ba e7 ff ff 90 <0f> 0b 90 e9 b1 e7 ff ff 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03
RSP: 0000:ffffc90002e172d0 EFLAGS: 00010202
RAX: ffff888029380000 RBX: 0000000000000000 RCX: 1ffff1100fffad29
RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88803fffd938
RBP: ffff88802938002c R08: 0000000000008000 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000000 R12: 00000000000cac40
R13: ffff88803fffb900 R14: 0000000000000000 R15: 1ffff920005c2e74
FS: 0000000000000000(0000) GS:ffff888096955000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000008000a000 CR3: 00000000403b5000 CR4: 0000000000352ef0
Call Trace:
<TASK>
alloc_slab_page mm/slub.c:3347 [inline]
allocate_slab mm/slub.c:3470 [inline]
new_slab+0x1f6/0x6e0 mm/slub.c:3513
refill_objects+0xe3/0x410 mm/slub.c:7417
refill_sheaf mm/slub.c:2885 [inline]
__pcs_replace_empty_main+0x35e/0x650 mm/slub.c:4774
alloc_from_pcs mm/slub.c:4850 [inline]
slab_alloc_node mm/slub.c:4984 [inline]
__kmalloc_cache_noprof+0x4f4/0x6d0 mm/slub.c:5559
_kmalloc_noprof include/linux/slab.h:991 [inline]
_kzalloc_noprof include/linux/slab.h:1312 [inline]
ref_tracker_alloc+0x190/0x590 lib/ref_tracker.c:270
__netns_tracker_alloc include/net/net_namespace.h:370 [inline]
sk_alloc+0xcfc/0xe80 net/core/sock.c:2329
inet_create net/ipv4/af_inet.c:333 [inline]
inet_create+0x3a0/0x1060 net/ipv4/af_inet.c:259
__sock_create+0x339/0x860 net/socket.c:1676
generic_ip_connect+0x826/0x1810 fs/smb/client/connect.c:3377
__cifs_reconnect+0x348/0xa80 fs/smb/client/connect.c:420
_cifs_reconnect fs/smb/client/connect.c:596 [inline]
cifs_reconnect fs/smb/client/connect.c:610 [inline]
cifs_readv_from_socket+0x7c1/0xa30 fs/smb/client/connect.c:749
cifs_read_from_socket+0xb8/0x100 fs/smb/client/connect.c:804
cifs_demultiplex_thread+0x2db/0x2ea0 fs/smb/client/connect.c:1295
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Cc: stable+noautosel@kernel.org # ref_tracker is debug instrumentation
Fixes: 4e66934eaadc ("lib: add reference counting tracking infrastructure")
Reported-by: syzbot+f95c2f0a71a98cef50eb@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6abd860c.9b478af7.e8d7a.0000.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20260930220137.843785-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Some refcount issues are not necessarily associated with memory corruption,
but REFCOUNT_ADD_UAF suggests that a UAF either just happened or is about
to happen.
REFCOUNT_SUB_UAF is also an indicator that reference counting is wrong, and
suggests (less strongly) that a UAF access might have happened recently.
In these cases, BUG() is appropriate if CONFIG_BUG_ON_DATA_CORRUPTION is
set.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://patch.msgid.link/20260812-refcount-bug-on-data-corruption-v1-1-c6da63566101@google.com
|
|
Make aes_cbc_encrypt_aesni() set the RNDKEY register alias explicitly,
rather than reusing the alias left by the previous function (which
worked by chance).
Also consistently comment the register aliases needed by _do_aes.
Link: https://patch.msgid.link/20260930170542.140403-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of exposing the riscv-optimized AES-XTS code via a
riscv-specific crypto_skcipher algorithm, just implement the AES-XTS
library functions. This is simpler, it makes the AES-XTS library
functions be riscv-optimized, and it also fixes the longstanding issue
where the riscv-optimized AES-XTS code was disabled by default. AES-XTS
support still remains available through crypto_skcipher via
crypto/aes.c, but individual architectures no longer need to handle it.
To match what the library expects, update the assembly functions to
operate on struct aes_key rather than struct crypto_aes_ctx, adjust the
argument order, and remove the redundant ciphertext stealing support
which is already implemented in a generic way in the library.
Bump up the priority of the corresponding library-based algorithm on
riscv now that it no longer has to be lower than arch/riscv/crypto/.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-21-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of exposing the riscv-optimized AES-CTR code via a
riscv-specific crypto_skcipher algorithm, just implement the AES-CTR
library functions. This is simpler, it makes the AES-CTR library
functions be riscv-optimized, and it also fixes the longstanding issue
where the riscv-optimized AES-CTR code was disabled by default. AES-CTR
support still remains available through crypto_skcipher via
crypto/aes.c, but individual architectures no longer need to handle it.
To match what the library expects, update the assembly functions to
operate on struct aes_enckey rather than struct crypto_aes_ctx, and
adjust the argument order.
Bump up the priority of the corresponding library-based algorithm on
riscv now that it no longer has to be lower than arch/riscv/crypto/.
Also re-enable the library-based "ccm(aes)" and "gcm(aes)".
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-20-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of exposing the riscv-optimized AES-CBC and AES-CBC-CTS code via
a riscv-specific crypto_skcipher algorithm, just implement the AES-CBC
and AES-CBC-CTS library functions. This is simpler, it makes the
AES-CBC and AES-CBC-CTS library functions be riscv-optimized, and it
also fixes the longstanding issue where the riscv-optimized AES-CBC and
AES-CBC-CTS code was disabled by default. AES-CBC and AES-CBC-CTS
support still remains available through crypto_skcipher via
crypto/aes.c, but individual architectures no longer need to handle it.
To match what the library expects, update the assembly functions to
operate on struct aes_enckey or struct aes_key rather than struct
crypto_aes_ctx, and adjust the argument order.
Remove the single-block special case from the assembly code, since it's
already handled by lib/crypto/aes.c before calling aes_cbc_cts_*_arch().
Bump up the priority of the corresponding library-based algorithms on
riscv now that they no longer have to be lower than arch/riscv/crypto/.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-19-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Instead of exposing the riscv-optimized AES-ECB code via a
riscv-specific crypto_skcipher algorithm, just implement the AES-ECB
library functions. This is simpler, it makes the AES-ECB library
functions be riscv-optimized, and it also fixes the longstanding issue
where the riscv-optimized AES-ECB code was disabled by default. AES-ECB
support still remains available through crypto_skcipher via
crypto/aes.c, but individual architectures no longer need to handle it.
To match what the library expects, update the assembly functions to
operate on struct aes_enckey or struct aes_key rather than struct
crypto_aes_ctx, and adjust the argument order.
Bump up the priority of the corresponding library-based algorithm on
riscv now that it no longer has to be lower than arch/riscv/crypto/.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-18-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Make the assembly code take the AES key struct directly, rather than the
round keys pointer and key length separately. Make the aes_begin macro
assume this convention, and remove support for the legacy
'struct crypto_aes_ctx' from it since that isn't used here.
This aligns with the convention that is being used (and will continue to
be used) for the AES modes, it makes the C glue code slightly simpler,
and it avoids the unnecessary shuffling around of arguments.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-17-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Copy arch/riscv/crypto/aes-macros.S to lib/crypto/riscv/aes-macros.S and
make lib/crypto/riscv/aes-riscv64-zvkned.S include the latter copy.
This makes it possible to change these macros without interfering with
the remaining code in arch/riscv/crypto/.
Of course, the copy in arch/riscv/crypto/ will be removed once the rest
of the AES code there is migrated to the library.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-16-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Migrate aes-xts-avx-x86_64.S into lib/crypto/, wiring it up to the XTS
library functions instead of the crypto_skcipher API. It still remains
available through crypto_skcipher via crypto/aes.c.
Some adjustments to the assembly code were needed:
- Take 'struct aes_key' instead of 'struct crypto_aes_ctx'.
- Remove the ciphertext stealing support from the assembly code, as the
library implements it in a generic way instead. (This does slightly
reduce performance when the length isn't a multiple of 16 bytes;
however, that case seems to never be reached in practice in the
kernel. So it makes sense to not extensively optimize for it yet.)
- Change 'int len' to 'long nblocks' for compatibility with the
library's use of size_t lengths.
- Remove the CFI stubs, as the functions are now called directly.
- Adjust the argument order to match the caller. Not strictly required,
but it's easiest to handle this now when changing the function
prototypes anyway and adding the new glue code.
This makes the remaining code in aesni-intel_asm.S (which just handled
key expansion) unused, so remove that too.
Don't remove the selection of CRYPTO_SKCIPHER from CRYPTO_AES_NI_INTEL
yet, since it's still needed for the "skcipher_walk" functions.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-15-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Migrate aes-ctr-avx-x86_64.S into lib/crypto/, wiring it up to the CTR
and XCTR library functions instead of the crypto_skcipher API. It still
remains available through crypto_skcipher via crypto/aes.c.
Some slight adjustments to the assembly code were needed:
- Take 'struct aes_enckey' instead of 'struct crypto_aes_ctx'.
- Upgrade the length argument from 32-bit to 64-bit so that it's
compatible with the library's use of size_t (at least assuming no
lengths over S64_MAX, which seems quite safe to assume...)
- Remove the CFI stubs, as the functions are now called directly.
- Adjust the argument order to match the caller. Not strictly required,
but it's easiest to handle this now when changing the function
prototypes anyway and adding the new glue code.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-14-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Optimize the crypto library's AES-XTS support with AES-NI, bringing its
performance on par with the "xts-aes-aesni" skcipher algorithm it will
supersede.
The new assembly code is written from scratch to fit well into the
crypto library and to be more consistent with aes-xts-avx-x86_64.S than
the code in arch/x86/crypto/aesni-intel_asm.S that it will supersede.
At a high level it is quite similar though, including doing 4 blocks per
iteration and supporting 32-bit mode for parity with the old code.
The new assembly code also fixes the flaw the old code had where the
encrypted tweaks were spilled to the destination buffer, rather than
kept entirely in registers (64-bit mode) or spilled to the stack (32-bit
mode). The encrypted tweaks are secret values that should not be
exposed to any code that doesn't have access to the key itself.
Note: the priority of xts-aes-lib is left unchanged at 110 temporarily.
It will be increased when the AVX-optimized AES-XTS code is migrated
too. Most systems use the AVX-optimized code; this commit just deals
with support for older CPUs that have AES-NI but not AVX (and 32-bit).
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-8-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Optimize the crypto library's AES-CTR support with AES-NI, bringing its
performance on par with the "ctr-aes-aesni" skcipher algorithm it will
supersede.
The new assembly function is written from scratch to fit well into the
crypto library and to be more consistent with aes-ctr-avx-x86_64.S than
the code in arch/x86/crypto/aesni-intel_asm.S that it will supersede.
That includes using the "ctr64" convention, where the assembly code is
simplified by making the C code handle incrementing the high 64 bits of
the counter. Unlike the ECB, CBC, and XTS code, 32-bit support is *not*
included for this one, as the existing CTR code didn't have it.
Note: the priority of ctr-aes-lib is left unchanged at 110 temporarily.
It will be increased when the AVX-optimized code is migrated too.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Optimize the crypto library's AES-CBC and AES-CBC-CTS support with
AES-NI, bringing their performance on par with the "cbc-aes-aesni" and
"cts-cbc-aes-aesni" skcipher algorithms they will supersede.
The new assembly functions are written from scratch to fit well into the
crypto library. However, they are functionally very similar to the
functions in arch/x86/crypto/aesni-intel_asm.S that they will supersede
and are intended to provide parity with those -- including supporting
32-bit mode, having the inner loops do 4 AES blocks per iteration, etc.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Optimize the crypto library's AES-ECB support with AES-NI, bringing its
performance on par with the "ecb-aes-aesni" skcipher algorithm it will
supersede.
The new assembly functions are written from scratch to fit well into the
crypto library. However, they are functionally very similar to the
functions in arch/x86/crypto/aesni-intel_asm.S that they will supersede
and are intended to provide parity with those -- including supporting
32-bit mode, having the inner loops do 4 AES blocks per iteration, etc.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Various miscellaneous updates to the assembly code in preparation for
adding implementations of AES modes to the same file:
- Define macros for the function argument registers, function prologues,
and function epilogues to centralize some of the handling of 32-bit vs
64-bit.
- Refactor the actual AES encryption and AES decryption logic into
macros _do_aes and _do_aes_ecb so that some of the modes can reuse it.
- Rename mask to expandkey_mask to differentiate it from the bswap_mask
that will be added.
- Update the prototypes of aes_encrypt_aesni() and aes_decrypt_aesni()
to be dst, src, key so that they will match the mode functions.
Note that this means passing a pointer to the key struct instead of a
(nrounds, rndkeys) pair, similar to what arch/x86/crypto/aes*.S do.
Although this makes the assembly code depend on the format of the key
struct, having one fewer argument makes it easier to accommodate
32-bit mode, and the C glue code becomes slightly simpler.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Update the calling convention for aes_xctr_arch() to pass the counter by
value, then do the increment in generic code. This aligns better with
the x86_64 and arm64 assembly code for XCTR, which takes the counter by
value and thus has to be paired with an increment in C code anyway.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260927224418.109759-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code needs to zeroize their local hmac_sha1_key
or hmac_sha1_ctx structures after use to avoid leaking sensitive material.
Provide hmac_sha1_zeroize_key() and hmac_sha1_zeroize_ctx() helper
functions that e.g. can be used with __cleanup() to automatically zeroize
the structures when they go out of scope.
While we're at it, replace the related memzero_explicit() call in
lib/crypto/sha1.c with a call to the new helper function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-9-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code needs to zeroize their local blake2b_ctx
or blake2s_ctx structures after use to avoid leaking sensitive material.
Provide blake2b_zeroize_ctx() and blake2s_zeroize_ctx() helper functions
that e.g. can be used with __cleanup() to automatically zeroize the
structures when they go out of scope.
While we're at it, replace the related memzero_explicit() calls in
lib/crypto/blake2*.c with calls to the new helper functions.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-8-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code functions need to zeroize their local
sm3_ctx structure after use to avoid leaking sensitive material. Provide
a sm3_zeroize_ctx() helper function that e.g. can be used with __cleanup()
to automatically zeroize the structure when it goes out of scope.
While we're at it, replace the related memzero_explicit() call in
lib/crypto/sm3.c with a call to the new helper function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-7-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code functions need to zeroize their local
hmac_md5_key or hmac_md5_ctx structures after use to avoid leaking
sensitive material on the stack.
Provide hmac_md5_zeroize_key() and hmac_md5_zeroize_ctx() helper
functions that e.g. can be used with __cleanup() to automatically
zeroize the structure when it goes out of scope.
While we're at it, replace the related memzero_explicit() call in
lib/crypto/md5.c with a call to the new helper function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-6-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code needs to zeroize their local aes_ccm_key
or aes_ccm_ctx structures after use to avoid leaking sensitive material.
Provide aes_ccm_zeroize_key() and aes_ccm_zeroize_ctx() helper functions
that e.g. can be used with __cleanup() to automatically zeroize the
structures when they go out of scope.
While we're at it, replace the related memzero_explicit() calls in
lib/crypto/aes.c with calls to the new helper functions.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-5-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code needs to zeroize their local aes_gcm_key
or aes_gcm_ctx structures after use to avoid leaking sensitive material.
Provide aes_gcm_zeroize_key() and aes_gcm_zeroize_ctx() helper functions
that e.g. can be used with __cleanup() to automatically zeroize the
structures when they go out of scope.
While we're at it, replace the related memzero_explicit() calls in
lib/crypto/aes.c with calls to the new helper functions.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-4-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
In certain cases crypto code functions need to zeroize their local
aes_xts_key structures after use to avoid leaking sensitive material.
Provide an aes_xts_zeroize_key() helper function that e.g. can be
used with __cleanup() to automatically zeroize the struct when it
goes out of scope.
While we're at it, replace the related memzero_explicit() call in
lib/crypto/aes.c with a call to the new helper function.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-3-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Some crypto functions need to zeroize their local aes_key or aes_enckey
structures after use to avoid leaking sensitive material on the stack.
Provide aes_zeroize_key() and aes_zeroize_enckey() helper functions that
can be used with __cleanup() to automatically zeroize the structs when
they go out of scope.
While we're at it, replace the memzero_explicit() calls in lib/crypto/aes.c
with the new helper functions.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260916095022.604354-2-thuth@redhat.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Because UML_PCI (arch/um/drivers/Kconfig) selects FORCE_PCI, this
contradicts the current dependency of CONFIG_PCI on CONFIG_MMU. This
commit fixes this issue by adding right dependencies under !MMU
environment.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609271139.DpjVdepU-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609271351.tw8EOsgz-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609270410.Kc2FsJp1-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609270228.yku16Noi-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609270416.rEtAiqyF-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609270538.mV3NDkLu-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609271435.lANS7mTP-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609271512.pg5gWbIg-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609271717.pg5HjzeZ-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609271810.pxMMu5ZC-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609271940.FhRl0cBi-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609272107.sLZJEOtt-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202609272234.F8tROOdL-lkp@intel.com/
Fixes: 626ff2b34dbb ("um: allow deselecting CONFIG_MMU")
Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
Link: https://patch.msgid.link/20260927234537.1585880-1-thehajime@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Introduce bitmap_intersects_and() to determine whether the intersection
of three bitmaps is non-empty. Unlike cpumask_first_and_and(), this
returns immediately when an intersecting word is found and does not
calculate the first matching bit.
Add cpumask_intersects_and() as the corresponding cpumask wrapper.
A subsequent patch uses the helper to determine whether a task
has a CPU that is present in its affinity mask, the preferred CPU mask,
and task possible CPU mask.
Suggested-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Reviwed-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Yury Norov <yury.norov@gmail.com>
Link: https://patch.msgid.link/20260928053728.797539-3-sshegde@linux.ibm.com
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add bitmap_parselist() cases where the group size makes start +
group_len overflow an unsigned int. Before "bitmap: bitmap_parselist():
don't wrap around on a huge group size" the region walk wrapped around
and also set bit 0.
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
