1. Patchew
  2. linux
  3. View series

[PATCH 5.10 000/163] 5.10.119-rc1 review

Greg Kroah-Hartman posted 163 patches 3 years, 11 months ago
Only 162 patches received!
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(-)
[PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Greg Kroah-Hartman 3 years, 11 months ago 
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-rc1.gz
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(-)
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Sudip Mukherjee 3 years, 11 months ago 
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
RE: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Fox Chen 3 years, 11 months ago 
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-rc1.gz
> 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>
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Pavel Machek 3 years, 11 months ago 
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/549589225

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Jason A. Donenfeld 3 years, 11 months ago 
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/549589225

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
RE: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Chris Paterson 3 years, 11 months ago 
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&amp;data=05%7C01%7CChris.Paterson2%40ren
> esas.com%7C0de8f5ed337148db7bcf08da4024905d%7C53d82571da1947e49c
> b4625a166a4a2a%7C0%7C0%7C637892823031829365%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=P8snmZjBO52JAyScIA4rWmFe
> woxUstyBGl3%2Fvvn%2BC%2B4%3D&amp;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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Greg Kroah-Hartman 3 years, 11 months ago 
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/549589225

I do not know how to decypher random test summaries like this, sorry.

greg k-h
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Guenter Roeck 3 years, 11 months ago 
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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Jason A. Donenfeld 3 years, 11 months ago 
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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Guenter Roeck 3 years, 11 months ago 
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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Jason A. Donenfeld 3 years, 11 months ago 
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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Guenter Roeck 3 years, 11 months ago 
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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Guenter Roeck 3 years, 11 months ago 
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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Naresh Kamboju 3 years, 11 months ago 
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-rc1.gz
> 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.118-164-gd318333bd3db/

## 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
Re: [PATCH 5.10 000/163] 5.10.119-rc1 review
Posted by Samuel Zou 3 years, 11 months ago 

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-rc1.gz
> 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>

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.