This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 29 May 2022 08:46:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.119-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 5.10.119-rc1
Edward Matijevic motolav@gmail.com ALSA: ctxfi: Add SB046x PCI ID
Jason A. Donenfeld Jason@zx2c4.com random: check for signals after page of pool writes
Jens Axboe axboe@kernel.dk random: wire up fops->splice_{read,write}_iter()
Jens Axboe axboe@kernel.dk random: convert to using fops->write_iter()
Jens Axboe axboe@kernel.dk random: convert to using fops->read_iter()
Jason A. Donenfeld Jason@zx2c4.com random: unify batched entropy implementations
Jason A. Donenfeld Jason@zx2c4.com random: move randomize_page() into mm where it belongs
Jason A. Donenfeld Jason@zx2c4.com random: move initialization functions out of hot pages
Jason A. Donenfeld Jason@zx2c4.com random: make consistent use of buf and len
Jason A. Donenfeld Jason@zx2c4.com random: use proper return types on get_random_{int,long}_wait()
Jason A. Donenfeld Jason@zx2c4.com random: remove extern from functions in header
Jason A. Donenfeld Jason@zx2c4.com random: use static branch for crng_ready()
Jason A. Donenfeld Jason@zx2c4.com random: credit architectural init the exact amount
Jason A. Donenfeld Jason@zx2c4.com random: handle latent entropy and command line from random_init()
Jason A. Donenfeld Jason@zx2c4.com random: use proper jiffies comparison macro
Jason A. Donenfeld Jason@zx2c4.com random: remove ratelimiting for in-kernel unseeded randomness
Jason A. Donenfeld Jason@zx2c4.com random: move initialization out of reseeding hot path
Jason A. Donenfeld Jason@zx2c4.com random: avoid initializing twice in credit race
Jason A. Donenfeld Jason@zx2c4.com random: use symbolic constants for crng_init states
Jason A. Donenfeld Jason@zx2c4.com siphash: use one source of truth for siphash permutations
Jason A. Donenfeld Jason@zx2c4.com random: help compiler out with fast_mix() by using simpler arguments
Jason A. Donenfeld Jason@zx2c4.com random: do not use input pool from hard IRQs
Jason A. Donenfeld Jason@zx2c4.com random: order timer entropy functions below interrupt functions
Jason A. Donenfeld Jason@zx2c4.com random: do not pretend to handle premature next security model
Jason A. Donenfeld Jason@zx2c4.com random: use first 128 bits of input as fast init
Jason A. Donenfeld Jason@zx2c4.com random: do not use batches when !crng_ready()
Jason A. Donenfeld Jason@zx2c4.com random: insist on random_get_entropy() existing in order to simplify
Jason A. Donenfeld Jason@zx2c4.com xtensa: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com sparc: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com um: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com x86/tsc: Use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com nios2: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com arm: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com mips: use fallback for random_get_entropy() instead of just c0 random
Jason A. Donenfeld Jason@zx2c4.com riscv: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com m68k: use fallback for random_get_entropy() instead of zero
Jason A. Donenfeld Jason@zx2c4.com timekeeping: Add raw clock fallback for random_get_entropy()
Jason A. Donenfeld Jason@zx2c4.com powerpc: define get_cycles macro for arch-override
Jason A. Donenfeld Jason@zx2c4.com alpha: define get_cycles macro for arch-override
Jason A. Donenfeld Jason@zx2c4.com parisc: define get_cycles macro for arch-override
Jason A. Donenfeld Jason@zx2c4.com s390: define get_cycles macro for arch-override
Jason A. Donenfeld Jason@zx2c4.com ia64: define get_cycles macro for arch-override
Jason A. Donenfeld Jason@zx2c4.com init: call time_init() before rand_initialize()
Jason A. Donenfeld Jason@zx2c4.com random: fix sysctl documentation nits
Jason A. Donenfeld Jason@zx2c4.com random: document crng_fast_key_erasure() destination possibility
Jason A. Donenfeld Jason@zx2c4.com random: make random_get_entropy() return an unsigned long
Jason A. Donenfeld Jason@zx2c4.com random: allow partial reads if later user copies fail
Jason A. Donenfeld Jason@zx2c4.com random: check for signals every PAGE_SIZE chunk of /dev/[u]random
Jann Horn jannh@google.com random: check for signal_pending() outside of need_resched() check
Jason A. Donenfeld Jason@zx2c4.com random: do not allow user to keep crng key around on stack
Jan Varho jan.varho@gmail.com random: do not split fast init input in add_hwgenerator_randomness()
Jason A. Donenfeld Jason@zx2c4.com random: mix build-time latent entropy into pool at init
Jason A. Donenfeld Jason@zx2c4.com random: re-add removed comment about get_random_{u32,u64} reseeding
Jason A. Donenfeld Jason@zx2c4.com random: treat bootloader trust toggle the same way as cpu trust toggle
Jason A. Donenfeld Jason@zx2c4.com random: skip fast_init if hwrng provides large chunk of entropy
Jason A. Donenfeld Jason@zx2c4.com random: check for signal and try earlier when generating entropy
Jason A. Donenfeld Jason@zx2c4.com random: reseed more often immediately after booting
Jason A. Donenfeld Jason@zx2c4.com random: make consistent usage of crng_ready()
Jason A. Donenfeld Jason@zx2c4.com random: use SipHash as interrupt entropy accumulator
Jason A. Donenfeld Jason@zx2c4.com random: replace custom notifier chain with standard one
Jason A. Donenfeld Jason@zx2c4.com random: don't let 644 read-only sysctls be written to
Jason A. Donenfeld Jason@zx2c4.com random: give sysctl_random_min_urandom_seed a more sensible value
Jason A. Donenfeld Jason@zx2c4.com random: do crng pre-init loading in worker rather than irq
Jason A. Donenfeld Jason@zx2c4.com random: unify cycles_t and jiffies usage and types
Jason A. Donenfeld Jason@zx2c4.com random: cleanup UUID handling
Jason A. Donenfeld Jason@zx2c4.com random: only wake up writers after zap if threshold was passed
Jason A. Donenfeld Jason@zx2c4.com random: round-robin registers as ulong, not u32
Jason A. Donenfeld Jason@zx2c4.com random: clear fast pool, crng, and batches in cpuhp bring up
Jason A. Donenfeld Jason@zx2c4.com random: pull add_hwgenerator_randomness() declaration into random.h
Jason A. Donenfeld Jason@zx2c4.com random: check for crng_init == 0 in add_device_randomness()
Jason A. Donenfeld Jason@zx2c4.com random: unify early init crng load accounting
Jason A. Donenfeld Jason@zx2c4.com random: do not take pool spinlock at boot
Jason A. Donenfeld Jason@zx2c4.com random: defer fast pool mixing to worker
Jason A. Donenfeld Jason@zx2c4.com random: rewrite header introductory comment
Jason A. Donenfeld Jason@zx2c4.com random: group sysctl functions
Jason A. Donenfeld Jason@zx2c4.com random: group userspace read/write functions
Jason A. Donenfeld Jason@zx2c4.com random: group entropy collection functions
Jason A. Donenfeld Jason@zx2c4.com random: group entropy extraction functions
Jason A. Donenfeld Jason@zx2c4.com random: group crng functions
Jason A. Donenfeld Jason@zx2c4.com random: group initialization wait functions
Jason A. Donenfeld Jason@zx2c4.com random: remove whitespace and reorder includes
Jason A. Donenfeld Jason@zx2c4.com random: remove useless header comment
Jason A. Donenfeld Jason@zx2c4.com random: introduce drain_entropy() helper to declutter crng_reseed()
Jason A. Donenfeld Jason@zx2c4.com random: deobfuscate irq u32/u64 contributions
Jason A. Donenfeld Jason@zx2c4.com random: add proper SPDX header
Jason A. Donenfeld Jason@zx2c4.com random: remove unused tracepoints
Jason A. Donenfeld Jason@zx2c4.com random: remove ifdef'd out interrupt bench
Jason A. Donenfeld Jason@zx2c4.com random: tie batched entropy generation to base_crng generation
Dominik Brodowski linux@dominikbrodowski.net random: fix locking for crng_init in crng_reseed()
Jason A. Donenfeld Jason@zx2c4.com random: zero buffer after reading entropy from userspace
Jason A. Donenfeld Jason@zx2c4.com random: remove outdated INT_MAX >> 6 check in urandom_read()
Jason A. Donenfeld Jason@zx2c4.com random: make more consistent use of integer types
Jason A. Donenfeld Jason@zx2c4.com random: use hash function for crng_slow_load()
Jason A. Donenfeld Jason@zx2c4.com random: use simpler fast key erasure flow on per-cpu keys
Jason A. Donenfeld Jason@zx2c4.com random: absorb fast pool into input pool after fast load
Jason A. Donenfeld Jason@zx2c4.com random: do not xor RDRAND when writing into /dev/random
Jason A. Donenfeld Jason@zx2c4.com random: ensure early RDSEED goes through mixer on init
Jason A. Donenfeld Jason@zx2c4.com random: inline leaves of rand_initialize()
Jason A. Donenfeld Jason@zx2c4.com random: get rid of secondary crngs
Jason A. Donenfeld Jason@zx2c4.com random: use RDSEED instead of RDRAND in entropy extraction
Dominik Brodowski linux@dominikbrodowski.net random: fix locking in crng_fast_load()
Jason A. Donenfeld Jason@zx2c4.com random: remove batched entropy locking
Eric Biggers ebiggers@google.com random: remove use_input_pool parameter from crng_reseed()
Jason A. Donenfeld Jason@zx2c4.com random: make credit_entropy_bits() always safe
Jason A. Donenfeld Jason@zx2c4.com random: always wake up entropy writers after extraction
Jason A. Donenfeld Jason@zx2c4.com random: use linear min-entropy accumulation crediting
Jason A. Donenfeld Jason@zx2c4.com random: simplify entropy debiting
Jason A. Donenfeld Jason@zx2c4.com random: use computational hash for entropy extraction
Dominik Brodowski linux@dominikbrodowski.net random: only call crng_finalize_init() for primary_crng
Dominik Brodowski linux@dominikbrodowski.net random: access primary_pool directly rather than through pointer
Dominik Brodowski linux@dominikbrodowski.net random: continually use hwgenerator randomness
Jason A. Donenfeld Jason@zx2c4.com random: simplify arithmetic function flow in account()
Jason A. Donenfeld Jason@zx2c4.com random: selectively clang-format where it makes sense
Jason A. Donenfeld Jason@zx2c4.com random: access input_pool_data directly rather than through pointer
Jason A. Donenfeld Jason@zx2c4.com random: cleanup fractional entropy shift constants
Jason A. Donenfeld Jason@zx2c4.com random: prepend remaining pool constants with POOL_
Jason A. Donenfeld Jason@zx2c4.com random: de-duplicate INPUT_POOL constants
Jason A. Donenfeld Jason@zx2c4.com random: remove unused OUTPUT_POOL constants
Jason A. Donenfeld Jason@zx2c4.com random: rather than entropy_store abstraction, use global
Jason A. Donenfeld Jason@zx2c4.com random: remove unused extract_entropy() reserved argument
Jason A. Donenfeld Jason@zx2c4.com random: remove incomplete last_data logic
Jason A. Donenfeld Jason@zx2c4.com random: cleanup integer types
Jason A. Donenfeld Jason@zx2c4.com random: cleanup poolinfo abstraction
Schspa Shi schspa@gmail.com random: fix typo in comments
Jann Horn jannh@google.com random: don't reset crng_init_cnt on urandom_read()
Jason A. Donenfeld Jason@zx2c4.com random: avoid superfluous call to RDRAND in CRNG extraction
Dominik Brodowski linux@dominikbrodowski.net random: early initialization of ChaCha constants
Jason A. Donenfeld Jason@zx2c4.com random: use IS_ENABLED(CONFIG_NUMA) instead of ifdefs
Dominik Brodowski linux@dominikbrodowski.net random: harmonize "crng init done" messages
Jason A. Donenfeld Jason@zx2c4.com random: mix bootloader randomness into pool
Jason A. Donenfeld Jason@zx2c4.com random: do not re-init if crng_reseed completes before primary init
Jason A. Donenfeld Jason@zx2c4.com random: do not sign extend bytes for rotation when mixing
Jason A. Donenfeld Jason@zx2c4.com random: use BLAKE2s instead of SHA1 in extraction
Sebastian Andrzej Siewior bigeasy@linutronix.de random: remove unused irq_flags argument from add_interrupt_randomness()
Mark Brown broonie@kernel.org random: document add_hwgenerator_randomness() with other input functions
Jason A. Donenfeld Jason@zx2c4.com lib/crypto: blake2s: avoid indirect calls to compression function for Clang CFI
Jason A. Donenfeld Jason@zx2c4.com lib/crypto: sha1: re-roll loops to reduce code size
Jason A. Donenfeld Jason@zx2c4.com lib/crypto: blake2s: move hmac construction into wireguard
Jason A. Donenfeld Jason@zx2c4.com lib/crypto: blake2s: include as built-in
Eric Biggers ebiggers@google.com crypto: blake2s - include <linux/bug.h> instead of <asm/bug.h>
Eric Biggers ebiggers@google.com crypto: blake2s - adjust include guard naming
Eric Biggers ebiggers@google.com crypto: blake2s - add comment for blake2s_state fields
Eric Biggers ebiggers@google.com crypto: blake2s - optimize blake2s initialization
Eric Biggers ebiggers@google.com crypto: blake2s - share the "shash" API boilerplate code
Eric Biggers ebiggers@google.com crypto: blake2s - move update and final logic to internal/blake2s.h
Eric Biggers ebiggers@google.com crypto: blake2s - remove unneeded includes
Eric Biggers ebiggers@google.com crypto: x86/blake2s - define shash_alg structs using macros
Eric Biggers ebiggers@google.com crypto: blake2s - define shash_alg structs using macros
Herbert Xu herbert@gondor.apana.org.au crypto: lib/blake2s - Move selftest prototype into header file
Jason A. Donenfeld Jason@zx2c4.com MAINTAINERS: add git tree for random.c
Jason A. Donenfeld Jason@zx2c4.com MAINTAINERS: co-maintain random.c
Eric Biggers ebiggers@google.com random: remove dead code left over from blocking pool
Ard Biesheuvel ardb@kernel.org random: avoid arch_get_random_seed_long() when collecting IRQ randomness
Lorenzo Pieralisi lorenzo.pieralisi@arm.com ACPI: sysfs: Fix BERT error region memory mapping
Andy Shevchenko andriy.shevchenko@linux.intel.com ACPI: sysfs: Make sparse happy about address space in use
Hans Verkuil hverkuil-cisco@xs4all.nl media: vim2m: initialize the media device earlier
Sakari Ailus sakari.ailus@linux.intel.com media: vim2m: Register video device after setting up internals
Willy Tarreau w@1wt.eu secure_seq: use the 64 bits of the siphash for port offset calculation
Eric Dumazet edumazet@google.com tcp: change source port randomizarion at connect() time
Paolo Bonzini pbonzini@redhat.com KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID
Vitaly Kuznetsov vkuznets@redhat.com KVM: x86: Properly handle APF vs disabled LAPIC situation
Denis Efremov (Oracle) efremov@linux.com staging: rtl8723bs: prevent ->Ssid overflow in rtw_wx_set_scan()
Daniel Thompson daniel.thompson@linaro.org lockdown: also lock down previous kgdb use
-------------
Diffstat:
Documentation/admin-guide/kernel-parameters.txt | 6 + Documentation/admin-guide/sysctl/kernel.rst | 22 +- MAINTAINERS | 2 + Makefile | 4 +- arch/alpha/include/asm/timex.h | 1 + arch/arm/include/asm/timex.h | 1 + arch/ia64/include/asm/timex.h | 1 + arch/m68k/include/asm/timex.h | 2 +- arch/mips/include/asm/timex.h | 17 +- arch/nios2/include/asm/timex.h | 3 + arch/parisc/include/asm/timex.h | 3 +- arch/powerpc/include/asm/timex.h | 1 + arch/riscv/include/asm/timex.h | 2 +- arch/s390/include/asm/timex.h | 1 + arch/sparc/include/asm/timex_32.h | 4 +- arch/um/include/asm/timex.h | 9 +- arch/x86/crypto/Makefile | 4 +- arch/x86/crypto/blake2s-glue.c | 166 +- arch/x86/crypto/blake2s-shash.c | 77 + arch/x86/include/asm/timex.h | 9 + arch/x86/include/asm/tsc.h | 7 +- arch/x86/kernel/cpu/mshyperv.c | 2 +- arch/x86/kvm/lapic.c | 6 + arch/x86/kvm/mmu/mmu.c | 6 +- arch/x86/kvm/x86.c | 2 +- arch/xtensa/include/asm/timex.h | 6 +- crypto/Kconfig | 3 +- crypto/blake2s_generic.c | 158 +- crypto/drbg.c | 17 +- drivers/acpi/sysfs.c | 23 +- drivers/char/Kconfig | 3 +- drivers/char/hw_random/core.c | 1 + drivers/char/random.c | 3035 +++++++++-------------- drivers/hv/vmbus_drv.c | 2 +- drivers/media/test-drivers/vim2m.c | 22 +- drivers/net/Kconfig | 1 - drivers/net/wireguard/noise.c | 45 +- drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 6 +- include/crypto/blake2s.h | 66 +- include/crypto/chacha.h | 15 +- include/crypto/drbg.h | 2 +- include/crypto/internal/blake2s.h | 123 +- include/linux/cpuhotplug.h | 2 + include/linux/hw_random.h | 2 - include/linux/mm.h | 1 + include/linux/prandom.h | 23 +- include/linux/random.h | 100 +- include/linux/security.h | 2 + include/linux/siphash.h | 28 + include/linux/timex.h | 10 +- include/net/inet_hashtables.h | 2 +- include/net/secure_seq.h | 4 +- include/trace/events/random.h | 330 --- init/main.c | 13 +- kernel/cpu.c | 11 + kernel/debug/debug_core.c | 24 + kernel/debug/kdb/kdb_main.c | 62 +- kernel/irq/handle.c | 2 +- kernel/time/timekeeping.c | 15 + lib/Kconfig.debug | 3 +- lib/crypto/Kconfig | 23 +- lib/crypto/Makefile | 9 +- lib/crypto/blake2s-generic.c | 6 +- lib/crypto/blake2s-selftest.c | 33 +- lib/crypto/blake2s.c | 81 +- lib/random32.c | 16 +- lib/sha1.c | 95 +- lib/siphash.c | 32 +- lib/vsprintf.c | 10 +- mm/util.c | 32 + net/core/secure_seq.c | 4 +- net/ipv4/inet_hashtables.c | 28 +- net/ipv6/inet6_hashtables.c | 4 +- security/security.c | 2 + sound/pci/ctxfi/ctatc.c | 2 + sound/pci/ctxfi/cthardware.h | 3 +- 76 files changed, 1865 insertions(+), 3035 deletions(-)
Hi!
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Is there some kind of back-story why we are doing massive changes to /dev/random? 5.19-rc1 is not even out, so third of those changes did not get much testing.
It seems we hit some problems, but I'm not sure if they are kernel problems or test infrastructure problems. Perhaps Chris can help?
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/54...
Best regards, Pavel
On Fri, May 27, 2022 at 04:14:21PM +0200, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Is there some kind of back-story why we are doing massive changes to /dev/random? 5.19-rc1 is not even out, so third of those changes did not get much testing.
Did you miss the posting on the stable list that described all of this: https://lore.kernel.org/all/YouECCoUA6eZEwKf@zx2c4.com/
It seems we hit some problems, but I'm not sure if they are kernel problems or test infrastructure problems. Perhaps Chris can help?
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/54...
I do not know how to decypher random test summaries like this, sorry.
greg k-h
On 5/27/22 08:53, Greg Kroah-Hartman wrote:
On Fri, May 27, 2022 at 04:14:21PM +0200, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Is there some kind of back-story why we are doing massive changes to /dev/random? 5.19-rc1 is not even out, so third of those changes did not get much testing.
Did you miss the posting on the stable list that described all of this: https://lore.kernel.org/all/YouECCoUA6eZEwKf@zx2c4.com/
That describes _what_ is done, but not _why_ the patches needed to be backported to older kernels. Normally I would see those as enhancements, not as bug fixes. Given that we (ChromeOS) have been hit by rng related issues before (specifically boot stalls on some hardware), I am quite concerned about the possible impact of this series for stable releases.
Guenter
On 5/27/22 09:59, Guenter Roeck wrote:
On 5/27/22 08:53, Greg Kroah-Hartman wrote:
On Fri, May 27, 2022 at 04:14:21PM +0200, Pavel Machek wrote:
Hi!
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Is there some kind of back-story why we are doing massive changes to /dev/random? 5.19-rc1 is not even out, so third of those changes did not get much testing.
Did you miss the posting on the stable list that described all of this: https://lore.kernel.org/all/YouECCoUA6eZEwKf@zx2c4.com/
That describes _what_ is done, but not _why_ the patches needed to be backported to older kernels. Normally I would see those as enhancements, not as bug fixes. Given that we (ChromeOS) have been hit by rng related issues before (specifically boot stalls on some hardware), I am quite concerned about the possible impact of this series for stable releases.
Here is the missing information: This is required by NIST SP800-90B [1]. Without this set of changes, Linux distributions are expected to fail FIPS validation in the future.
Guenter
--- [1] https://csrc.nist.gov/publications/detail/sp/800-90b/final
Hi Guenter,
On Fri, May 27, 2022 at 09:59:14AM -0700, Guenter Roeck wrote:
Given that we (ChromeOS) have been hit by rng related issues before (specifically boot stalls on some hardware), I am quite concerned about the possible impact of this series for stable releases.
The urandom try_to_generate_entropy() change from 5.18 wasn't backported.
zx2c4@thinkpad ~/Projects/random-linux $ git diff linux-5.10.y:drivers/char/random.c master:drivers/char/random.c [...snip...] @@ -1292,6 +1311,13 @@ static ssize_t urandom_read_iter(struct kiocb *kiocb, struct iov_iter *iter) { static int maxwarn = 10;
+ /* + * Opportunistically attempt to initialize the RNG on platforms that + * have fast cycle counters, but don't (for now) require it to succeed. + */ + if (!crng_ready()) + try_to_generate_entropy(); + if (!crng_ready()) { if (!ratelimit_disable && maxwarn <= 0) ++urandom_warning.missed;
Jason
On Fri, May 27, 2022 at 11:10:35PM +0200, Jason A. Donenfeld wrote:
Hi Guenter,
On Fri, May 27, 2022 at 09:59:14AM -0700, Guenter Roeck wrote:
Given that we (ChromeOS) have been hit by rng related issues before (specifically boot stalls on some hardware), I am quite concerned about the possible impact of this series for stable releases.
The urandom try_to_generate_entropy() change from 5.18 wasn't backported.
Was it not backported on purpose or is it missing ?
Thanks, Guenter
zx2c4@thinkpad ~/Projects/random-linux $ git diff linux-5.10.y:drivers/char/random.c master:drivers/char/random.c [...snip...] @@ -1292,6 +1311,13 @@ static ssize_t urandom_read_iter(struct kiocb *kiocb, struct iov_iter *iter) { static int maxwarn = 10;
/** Opportunistically attempt to initialize the RNG on platforms that* have fast cycle counters, but don't (for now) require it to succeed.*/if (!crng_ready())try_to_generate_entropy();if (!crng_ready()) { if (!ratelimit_disable && maxwarn <= 0) ++urandom_warning.missed;Jason
On 5/28/22, Guenter Roeck linux@roeck-us.net wrote:
On Fri, May 27, 2022 at 11:10:35PM +0200, Jason A. Donenfeld wrote:
Hi Guenter,
On Fri, May 27, 2022 at 09:59:14AM -0700, Guenter Roeck wrote:
Given that we (ChromeOS) have been hit by rng related issues before (specifically boot stalls on some hardware), I am quite concerned about the possible impact of this series for stable releases.
The urandom try_to_generate_entropy() change from 5.18 wasn't backported.
Was it not backported on purpose or is it missing ?
On purpose, on account of the concern that you expressed. Hence I mentioned it in response to your message.
Jason
Hi Pavel,
On Fri, May 27, 2022 at 04:14:21PM +0200, Pavel Machek wrote:
It seems we hit some problems, but I'm not sure if they are kernel problems or test infrastructure problems. Perhaps Chris can help?
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/54...
I'm clicking on everything red, and all the actual boot logs and execution logs show things passing. Seems like this might be a CI issue? I'm certainly very interested to learn about potential regressions though if you can point to anything specific.
If I had to guess, it looks to me like the "lava" job finishes with "result: pass", but never tells the controller properly, so it times out waiting for the reply. Seems like CI infrastructure issue.
Jason
Hello,
Sorry for being late to the party.
From: Jason A. Donenfeld Jason@zx2c4.com Sent: 27 May 2022 22:05
Hi Pavel,
On Fri, May 27, 2022 at 04:14:21PM +0200, Pavel Machek wrote:
It seems we hit some problems, but I'm not sure if they are kernel problems or test infrastructure problems. Perhaps Chris can help?
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab .com%2Fcip-project%2Fcip-testing%2Flinux-stable-rc-ci%2F- %2Fpipelines%2F549589225&data=05%7C01%7CChris.Paterson2%40ren esas.com%7C0de8f5ed337148db7bcf08da4024905d%7C53d82571da1947e49c b4625a166a4a2a%7C0%7C0%7C637892823031829365%7CUnknown%7CTWFp bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C3000%7C%7C%7C&sdata=P8snmZjBO52JAyScIA4rWmFe woxUstyBGl3%2Fvvn%2BC%2B4%3D&reserved=0
I'm clicking on everything red, and all the actual boot logs and execution logs show things passing. Seems like this might be a CI issue? I'm certainly very interested to learn about potential regressions though if you can point to anything specific.
If I had to guess, it looks to me like the "lava" job finishes with "result: pass", but never tells the controller properly, so it times out waiting for the reply. Seems like CI infrastructure issue.
Exactly that, thank you Jason. We had some issues with some of the labs going offline at the end of last week. A bit sneaky because I was on leave. It resulted in a big backlog in jobs which meant it took more then 2 hours for them to go through and the GitLab runner gave up.
I've re-run the "failed" jobs and now we have lots of green ticks. Sorry for all the noise!
Kind regards, Chris
Jason
On Fri, May 27, 2022 at 10:48:00AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 29 May 2022 08:46:26 +0000. Anything received after that time might be too late.
Build results: total: 161 pass: 161 fail: 0 Qemu test results: total: 477 pass: 477 fail: 0
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
On Fri, 27 May 2022 at 14:21, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 29 May 2022 08:46:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.119-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
## Build * kernel: 5.10.119-rc1 * git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git * git branch: linux-5.10.y * git commit: d318333bd3dbc483b4d566521dc6486ef9f6ba04 * git describe: v5.10.118-164-gd318333bd3db * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10....
## Test Regressions (compared to v5.10.118) No test regressions found.
## Metric Regressions (compared to v5.10.118) No metric regressions found.
## Test Fixes (compared to v5.10.118) No test fixes found.
## Metric Fixes (compared to v5.10.118) No metric fixes found.
## Test result summary total: 94216, pass: 80324, fail: 458, skip: 12631, xfail: 803
## Build Summary * arc: 10 total, 10 passed, 0 failed * arm: 291 total, 291 passed, 0 failed * arm64: 41 total, 41 passed, 0 failed * dragonboard-410c: 1 total, 1 passed, 0 failed * hi6220-hikey: 1 total, 1 passed, 0 failed * i386: 40 total, 40 passed, 0 failed * juno-r2: 1 total, 1 passed, 0 failed * mips: 37 total, 37 passed, 0 failed * parisc: 12 total, 12 passed, 0 failed * powerpc: 51 total, 51 passed, 0 failed * riscv: 27 total, 27 passed, 0 failed * s390: 21 total, 21 passed, 0 failed * sh: 24 total, 24 passed, 0 failed * sparc: 12 total, 12 passed, 0 failed * x15: 1 total, 1 passed, 0 failed * x86: 1 total, 1 passed, 0 failed * x86_64: 41 total, 41 passed, 0 failed
## Test suites summary * fwts * kselftest-android * kselftest-arm64 * kselftest-bpf * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * kunit * kvm-unit-tests * libgpiod * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * packetdrill * perf * perf/Zstd-perf.data-compression * rcutorture * ssuite * v4l2-compliance * vdso
-- Linaro LKFT https://lkft.linaro.org
Hi Greg,
On Fri, May 27, 2022 at 10:48:00AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 29 May 2022 08:46:26 +0000. Anything received after that time might be too late.
Build test: mips (gcc version 11.3.1 20220517): 63 configs -> no failure arm (gcc version 11.3.1 20220517): 105 configs -> no new failure arm64 (gcc version 11.3.1 20220517): 3 configs -> no failure x86_64 (gcc version 11.3.1 20220517): 4 configs -> no failure
Boot test: x86_64: Booted on my test laptop. No regression. x86_64: Booted on qemu. No regression. [1] arm64: Booted on rpi4b (4GB model). No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/1218 [2]. https://openqa.qa.codethink.co.uk/tests/1220
Tested-by: Sudip Mukherjee sudip.mukherjee@codethink.co.uk
-- Regards Sudip
On Fri, 27 May 2022 10:48:00 +0200, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 29 May 2022 08:46:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.119-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below.
thanks,
greg k-h
5.10.119-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen foxhlchen@gmail.com
On 2022/5/27 16:48, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.119 release. There are 163 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sun, 29 May 2022 08:46:26 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.119-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below.
thanks,
greg k-h
Tested on arm64 and x86 for 5.10.119-rc1,
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.10.y Version: 5.10.119-rc1 Commit: d318333bd3dbc483b4d566521dc6486ef9f6ba04 Compiler: gcc version 7.3.0 (GCC)
arm64: -------------------------------------------------------------------- Testcase Result Summary: total: 9033 passed: 9033 failed: 0 timeout: 0 --------------------------------------------------------------------
x86: -------------------------------------------------------------------- Testcase Result Summary: total: 9033 passed: 9033 failed: 0 timeout: 0 --------------------------------------------------------------------
Tested-by: Hulk Robot hulkrobot@huawei.com
-
Chris Paterson -
Fox Chen -
Greg Kroah-Hartman -
Guenter Roeck -
Jason A. Donenfeld -
Naresh Kamboju -
Pavel Machek -
Samuel Zou -
Sudip Mukherjee