linux-rng/drivers/char, branch master

Merge tag 'random-6.19-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random

2025-12-03T03:00:26Z

Pull random number generator updates from Jason Donenfeld: - Dynamically allocate cpumasks off of the stack if the kernel is configured for a lot of CPUs, to handle a -Wframe-larger-than case - The removal of next_pseudo_random32() after the last user was switched over to the prandom interface - The removal of get_random_u{8,16,32,64}_wait() functions, as there were no users of those at all - Some house keeping changes - a few grammar cleanups in the comments, system_unbound_wq was renamed to system_dfl_wq, and static_key_initialized no longer needs to be checked * tag 'random-6.19-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: random: complete sentence of comment random: drop check for static_key_initialized random: remove unused get_random_var_wait functions random: replace use of system_unbound_wq with system_dfl_wq random: use offstack cpumask when necessary prandom: remove next_pseudo_random32 media: vivid: use prandom random: add missing words in function comments

Merge tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

2025-12-03T02:01:03Z

Pull crypto library updates from Eric Biggers: "This is the main crypto library pull request for 6.19. It includes: - Add SHA-3 support to lib/crypto/, including support for both the hash functions and the extendable-output functions. Reimplement the existing SHA-3 crypto_shash support on top of the library. This is motivated mainly by the upcoming support for the ML-DSA signature algorithm, which needs the SHAKE128 and SHAKE256 functions. But even on its own it's a useful cleanup. This also fixes the longstanding issue where the architecture-optimized SHA-3 code was disabled by default. - Add BLAKE2b support to lib/crypto/, and reimplement the existing BLAKE2b crypto_shash support on top of the library. This is motivated mainly by btrfs, which supports BLAKE2b checksums. With this change, all btrfs checksum algorithms now have library APIs. btrfs is planned to start just using the library directly. This refactor also improves consistency between the BLAKE2b code and BLAKE2s code. And as usual, it also fixes the issue where the architecture-optimized BLAKE2b code was disabled by default. - Add POLYVAL support to lib/crypto/, replacing the existing POLYVAL support in crypto_shash. Reimplement HCTR2 on top of the library. This simplifies the code and improves HCTR2 performance. As usual, it also makes the architecture-optimized code be enabled by default. The generic implementation of POLYVAL is greatly improved as well. - Clean up the BLAKE2s code - Add FIPS self-tests for SHA-1, SHA-2, and SHA-3" * tag 'libcrypto-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (37 commits) fscrypt: Drop obsolete recommendation to enable optimized POLYVAL crypto: polyval - Remove the polyval crypto_shash crypto: hctr2 - Convert to use POLYVAL library lib/crypto: x86/polyval: Migrate optimized code into library lib/crypto: arm64/polyval: Migrate optimized code into library lib/crypto: polyval: Add POLYVAL library crypto: polyval - Rename conflicting functions lib/crypto: x86/blake2s: Use vpternlogd for 3-input XORs lib/crypto: x86/blake2s: Avoid writing back unchanged 'f' value lib/crypto: x86/blake2s: Improve readability lib/crypto: x86/blake2s: Use local labels for data lib/crypto: x86/blake2s: Drop check for nblocks == 0 lib/crypto: x86/blake2s: Fix 32-bit arg treated as 64-bit lib/crypto: arm, arm64: Drop filenames from file comments lib/crypto: arm/blake2s: Fix some comments crypto: s390/sha3 - Remove superseded SHA-3 code crypto: sha3 - Reimplement using library API crypto: jitterentropy - Use default sha3 implementation lib/crypto: s390/sha3: Add optimized one-shot SHA-3 digest functions lib/crypto: sha3: Support arch overrides of one-shot digest functions ...

random: complete sentence of comment

2025-11-25T01:54:37Z

Complete the sentence by adding "is set", rather than having it dangle as a sentence fragment. Signed-off-by: Jason A. Donenfeld

s390: Remove KMSG_COMPONENT macro

2025-11-24T10:45:21Z

The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter Signed-off-by: Heiko Carstens

random: drop check for static_key_initialized

2025-11-11T00:25:31Z

Commit e871abcda3b6 ("random: handle creditable entropy from atomic process context") added the use of workqueues, which meant testing whether the workqueue is valid, but it did not remove the existing check of whether static keys have been initialized. This static key check is unnecessary because workqueues are initialized long after it. And semantically it doesn't make much sense either, because it's not really directly calling a static key function in the condition. Remove the now unnecessary check. Signed-off-by: Thomas Weißschuh [Jason: rewrite commit message with different explanation, rebase on random.git, and update code comment.] Signed-off-by: Jason A. Donenfeld

random: replace use of system_unbound_wq with system_dfl_wq

2025-10-30T17:40:12Z

system_unbound_wq has been renamed to system_dfl_wq in 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq"), so update random.c's usage of it system_unbound_wq to reflect the new change. The old system_unbound_wq is slated for removal in the next few cycles. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Signed-off-by: Jason A. Donenfeld

random: use offstack cpumask when necessary

2025-10-30T17:35:26Z

The entropy generation function keeps a local cpu mask on the stack, which can trigger warnings in configurations with a large number of CPUs: drivers/char/random.c:1292:20: error: stack frame size (1288) exceeds limit (1280) in 'try_to_generate_entropy' [-Werror,-Wframe-larger-than] Use the cpumask interface to dynamically allocate it in those configurations. Fixes: 1c21fe00eda7 ("random: spread out jitter callback to different CPUs") Signed-off-by: Arnd Bergmann Signed-off-by: Jason A. Donenfeld

random: add missing words in function comments

2025-10-30T17:35:26Z

s/good as/as good as/ Signed-off-by: Thorsten Blum Signed-off-by: Jason A. Donenfeld

lib/crypto: blake2s: Rename blake2s_state to blake2s_ctx

2025-10-30T05:04:24Z

For consistency with the SHA-1, SHA-2, SHA-3 (in development), and MD5 library APIs, rename blake2s_state to blake2s_ctx. As a refresher, the ctx name: - Is a bit shorter. - Avoids confusion with the compression function state, which is also often called the state (but is just part of the full context). - Is consistent with OpenSSL. Not a big deal, of course. But consistency is nice. With a BLAKE2b library API about to be added, this is a convenient time to update this. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251018043106.375964-3-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: blake2s: Adjust parameter order of blake2s()

2025-10-30T05:04:24Z

Reorder the parameters of blake2s() from (out, in, key, outlen, inlen, keylen) to (key, keylen, in, inlen, out, outlen). This aligns BLAKE2s with the common conventions of pairing buffers and their lengths, and having outputs follow inputs. This is widely used elsewhere in lib/crypto/ and crypto/, and even elsewhere in the BLAKE2s code itself such as blake2s_init_key() and blake2s_final(). So blake2s() was a bit of an exception. Notably, this results in the same order as hmac_*_usingrawkey(). Note that since the type signature changed, it's not possible for a blake2s() call site to be silently missed. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251018043106.375964-2-ebiggers@kernel.org Signed-off-by: Eric Biggers