Rather than calling add_device_randomness(), the add_early_randomness()
function should use add_hwgenerator_randomness(), so that the early
entropy can be potentially credited, which allows for the RNG to
initialize earlier without having to wait for the kthread to come up.
Cc: Herbert Xu <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
drivers/char/hw_random/core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index cc002b0c2f0c..8c0819ce2781 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -69,8 +69,10 @@ static void add_early_randomness(struct hwrng *rng)
mutex_lock(&reading_mutex);
bytes_read = rng_get_data(rng, rng_fillbuf, 32, 0);
mutex_unlock(&reading_mutex);
- if (bytes_read > 0)
- add_device_randomness(rng_fillbuf, bytes_read);
+ if (bytes_read > 0) {
+ size_t entropy = bytes_read * 8 * rng->quality / 1024;
+ add_hwgenerator_randomness(rng_fillbuf, bytes_read, entropy);
+ }
}
static inline void cleanup_rng(struct kref *kref)
--
2.38.1
On Sat, Nov 5, 2022 at 9:44 PM Jason A. Donenfeld <[email protected]> wrote:
>
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.
>
> Cc: Herbert Xu <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> ---
> drivers/char/hw_random/core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index cc002b0c2f0c..8c0819ce2781 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -69,8 +69,10 @@ static void add_early_randomness(struct hwrng *rng)
> mutex_lock(&reading_mutex);
> bytes_read = rng_get_data(rng, rng_fillbuf, 32, 0);
> mutex_unlock(&reading_mutex);
> - if (bytes_read > 0)
> - add_device_randomness(rng_fillbuf, bytes_read);
> + if (bytes_read > 0) {
> + size_t entropy = bytes_read * 8 * rng->quality / 1024;
> + add_hwgenerator_randomness(rng_fillbuf, bytes_read, entropy);
> + }
This will cause problems, because add_hwgenerator_randomness() will
sleep. I'll look into a more robust change.
Jason
Rather than calling add_device_randomness(), the add_early_randomness()
function should use add_hwgenerator_randomness(), so that the early
entropy can be potentially credited, which allows for the RNG to
initialize earlier without having to wait for the kthread to come up.
Since we don't want to sleep from add_early_randomness(), we also
refactor the API a bit so that hw_random/core.c can do the sleep, this
time using the correct function, hwrng_msleep, rather than having
random.c awkwardly do it.
Cc: Herbert Xu <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
drivers/char/hw_random/core.c | 13 +++++++++----
drivers/char/random.c | 9 +++++----
include/linux/random.h | 2 +-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index cc002b0c2f0c..f6bbe0d8b95d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -69,8 +69,10 @@ static void add_early_randomness(struct hwrng *rng)
mutex_lock(&reading_mutex);
bytes_read = rng_get_data(rng, rng_fillbuf, 32, 0);
mutex_unlock(&reading_mutex);
- if (bytes_read > 0)
- add_device_randomness(rng_fillbuf, bytes_read);
+ if (bytes_read > 0) {
+ size_t entropy = bytes_read * 8 * rng->quality / 1024;
+ add_hwgenerator_randomness(rng_fillbuf, bytes_read, entropy);
+ }
}
static inline void cleanup_rng(struct kref *kref)
@@ -499,6 +501,7 @@ static int hwrng_fillfn(void *unused)
while (!kthread_should_stop()) {
unsigned short quality;
struct hwrng *rng;
+ unsigned long sleep;
rng = get_current_rng();
if (IS_ERR(rng) || !rng)
@@ -527,8 +530,10 @@ static int hwrng_fillfn(void *unused)
entropy_credit = entropy;
/* Outside lock, sure, but y'know: randomness. */
- add_hwgenerator_randomness((void *)rng_fillbuf, rc,
- entropy >> 10);
+ sleep = add_hwgenerator_randomness((void *)rng_fillbuf, rc,
+ entropy >> 10);
+ if (sleep)
+ hwrng_msleep(rng, jiffies_to_msecs(sleep));
}
hwrng_fill = NULL;
return 0;
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 4591d55cb135..16ee170151a9 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -893,9 +893,9 @@ EXPORT_SYMBOL(add_device_randomness);
/*
* Interface for in-kernel drivers of true hardware RNGs.
* Those devices may produce endless random bits and will be throttled
- * when our pool is full.
+ * when our pool is full. Returns suggested sleep time in jiffies.
*/
-void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
+unsigned long add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
{
mix_pool_bytes(buf, len);
credit_init_bits(entropy);
@@ -904,8 +904,9 @@ void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
* Throttle writing to once every reseed interval, unless we're not yet
* initialized or no entropy is credited.
*/
- if (!kthread_should_stop() && (crng_ready() || !entropy))
- schedule_timeout_interruptible(crng_reseed_interval());
+ if (crng_ready() || !entropy)
+ return crng_reseed_interval();
+ return 0;
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
diff --git a/include/linux/random.h b/include/linux/random.h
index 2bdd3add3400..02ef65fc02c2 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -17,7 +17,7 @@ void __init add_bootloader_randomness(const void *buf, size_t len);
void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value) __latent_entropy;
void add_interrupt_randomness(int irq) __latent_entropy;
-void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy);
+unsigned long add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy);
#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
static inline void add_latent_entropy(void)
--
2.38.1
Am Sun, Nov 06, 2022 at 02:50:42AM +0100 schrieb Jason A. Donenfeld:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.
We're already at device_initcall() level here, so that shouldn't be much of
an additional delay.
> Since we don't want to sleep from add_early_randomness(), we also
> refactor the API a bit so that hw_random/core.c can do the sleep, this
> time using the correct function, hwrng_msleep, rather than having
> random.c awkwardly do it.
Isn't this something you were quite hesistant about just recently[*]?
| I was thinking the other day that under certain circumstances, it
| would be nice if random.c could ask hwrng for more bytes NOW, rather
| than waiting. With the code as it is currently, this could be
| accomplished by having a completion event or something similar to
| that. With your proposed change, now it's left up to the hwrng
| interface to handle.
|
| That's not the end of the world, but it does mean we'd have to come up
| with a patch down the line that exports a hwrng function saying, "stop
| the delays and schedule the worker NOW". Now impossible, just more
| complex, as now the state flow is split across two places. Wondering
| if you have any thoughts about this.
Thanks,
Dominik
[*] https://lore.kernel.org/lkml/CAHmME9rhunb05DEnc=UfGr8k9_LBi1NW2Hi0OsRbGwcCN2NzjQ@mail.gmail.com/
Hi Dominik,
On Sun, Nov 06, 2022 at 08:02:56AM +0100, Dominik Brodowski wrote:
> Am Sun, Nov 06, 2022 at 02:50:42AM +0100 schrieb Jason A. Donenfeld:
> > Rather than calling add_device_randomness(), the add_early_randomness()
> > function should use add_hwgenerator_randomness(), so that the early
> > entropy can be potentially credited, which allows for the RNG to
> > initialize earlier without having to wait for the kthread to come up.
>
> We're already at device_initcall() level here, so that shouldn't be much of
> an additional delay.
Either the delay is not relevant, in which case we should entirely
remove `add_early_randomness()`, or the delay is relevant, in which case
hw_random should use the right function, so that it gets credited as it
should. (Semantically this is the right thing to do, too, so that
random.c can actually know what the deal is with the data it's getting;
knowing, "oh this comes from hw_random" could be useful.)
> > Since we don't want to sleep from add_early_randomness(), we also
> > refactor the API a bit so that hw_random/core.c can do the sleep, this
> > time using the correct function, hwrng_msleep, rather than having
> > random.c awkwardly do it.
>
> Isn't this something you were quite hesistant about just recently[*]?
It is, yes, thanks. The concern is that now it means random.c can't ask
for more hw_random data by canceling that sleep. I was thinking that it
would be nice to cancel the sleep during system resume, vm fork, and
other similar events, so that we can get some fresh bits during the
times it matters most. But there's a bit of a problem of doing it in a
basic way like that: we might get the bits, but that doesn't mean we'll
reseed right away at that advanced stage in uptime. So we'd actually
need something more complicated like, "unblock from sleep now and reseed
after mixing data". When writing this patch last night, I was thinking
this is a more complicated thing that could benefit from a more
complicated API. But actually, maybe there's a way I can make it work
for the existing thing. So you're right: let's hold off on this v2. And
I'll send a v3 that just adds a boolean parameter of whether or not to
sleep. And then I'll also try tackling the unblock&reseed thing too at
the same time.
Jason
Rather than calling add_device_randomness(), the add_early_randomness()
function should use add_hwgenerator_randomness(), so that the early
entropy can be potentially credited, which allows for the RNG to
initialize earlier without having to wait for the kthread to come up.
This requires some minor API refactoring, by adding a `sleep_after`
parameter to add_hwgenerator_randomness(), so that we don't hit a
blocking sleep from add_early_randomness().
Cc: Herbert Xu <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
Herbert - it might be easiest for me to take this patch if you want? Or
if this will interfere with what you have going on, you can take it. Let
me know what you feel like. -Jason
drivers/char/hw_random/core.c | 8 +++++---
drivers/char/random.c | 12 ++++++------
include/linux/random.h | 2 +-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index cc002b0c2f0c..63a0a8e4505d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -69,8 +69,10 @@ static void add_early_randomness(struct hwrng *rng)
mutex_lock(&reading_mutex);
bytes_read = rng_get_data(rng, rng_fillbuf, 32, 0);
mutex_unlock(&reading_mutex);
- if (bytes_read > 0)
- add_device_randomness(rng_fillbuf, bytes_read);
+ if (bytes_read > 0) {
+ size_t entropy = bytes_read * 8 * rng->quality / 1024;
+ add_hwgenerator_randomness(rng_fillbuf, bytes_read, entropy, false);
+ }
}
static inline void cleanup_rng(struct kref *kref)
@@ -528,7 +530,7 @@ static int hwrng_fillfn(void *unused)
/* Outside lock, sure, but y'know: randomness. */
add_hwgenerator_randomness((void *)rng_fillbuf, rc,
- entropy >> 10);
+ entropy >> 10, true);
}
hwrng_fill = NULL;
return 0;
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 4591d55cb135..70ecfcfdb1d7 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -711,7 +711,7 @@ static void __cold _credit_init_bits(size_t bits)
* the above entropy accumulation routines:
*
* void add_device_randomness(const void *buf, size_t len);
- * void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy);
+ * void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy, bool sleep_after);
* void add_bootloader_randomness(const void *buf, size_t len);
* void add_vmfork_randomness(const void *unique_vm_id, size_t len);
* void add_interrupt_randomness(int irq);
@@ -891,11 +891,11 @@ void add_device_randomness(const void *buf, size_t len)
EXPORT_SYMBOL(add_device_randomness);
/*
- * Interface for in-kernel drivers of true hardware RNGs.
- * Those devices may produce endless random bits and will be throttled
- * when our pool is full.
+ * Interface for in-kernel drivers of true hardware RNGs. Those devices
+ * may produce endless random bits, so this function will sleep for
+ * some amount of time after, if the sleep_after parameter is true.
*/
-void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
+void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy, bool sleep_after)
{
mix_pool_bytes(buf, len);
credit_init_bits(entropy);
@@ -904,7 +904,7 @@ void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
* Throttle writing to once every reseed interval, unless we're not yet
* initialized or no entropy is credited.
*/
- if (!kthread_should_stop() && (crng_ready() || !entropy))
+ if (!kthread_should_stop() && (crng_ready() || !entropy) && sleep_after)
schedule_timeout_interruptible(crng_reseed_interval());
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
diff --git a/include/linux/random.h b/include/linux/random.h
index 2bdd3add3400..728b29ade208 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -17,7 +17,7 @@ void __init add_bootloader_randomness(const void *buf, size_t len);
void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value) __latent_entropy;
void add_interrupt_randomness(int irq) __latent_entropy;
-void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy);
+void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy, bool sleep_after);
#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
static inline void add_latent_entropy(void)
--
2.38.1
On Sun, Nov 06, 2022 at 04:02:43PM +0100, Jason A. Donenfeld wrote:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.
>
> This requires some minor API refactoring, by adding a `sleep_after`
> parameter to add_hwgenerator_randomness(), so that we don't hit a
> blocking sleep from add_early_randomness().
>
> Cc: Herbert Xu <[email protected]>
> Cc: Dominik Brodowski <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> ---
> Herbert - it might be easiest for me to take this patch if you want? Or
> if this will interfere with what you have going on, you can take it. Let
> me know what you feel like. -Jason
I don't have anything that touches this file so feel free to push
it through your tree:
Acked-by: Herbert Xu <[email protected]>
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Am Sun, Nov 06, 2022 at 04:02:43PM +0100 schrieb Jason A. Donenfeld:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.
>
> This requires some minor API refactoring, by adding a `sleep_after`
> parameter to add_hwgenerator_randomness(), so that we don't hit a
> blocking sleep from add_early_randomness().
>
> Cc: Herbert Xu <[email protected]>
> Cc: Dominik Brodowski <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
Reviewed-by: Dominik Brodowski <[email protected]>
Thanks,
Dominik
Hi Jason,
Am Sun, Nov 06, 2022 at 03:50:51PM +0100 schrieb Jason A. Donenfeld:
> On Sun, Nov 06, 2022 at 08:02:56AM +0100, Dominik Brodowski wrote:
> > Am Sun, Nov 06, 2022 at 02:50:42AM +0100 schrieb Jason A. Donenfeld:
> > > Rather than calling add_device_randomness(), the add_early_randomness()
> > > function should use add_hwgenerator_randomness(), so that the early
> > > entropy can be potentially credited, which allows for the RNG to
> > > initialize earlier without having to wait for the kthread to come up.
> >
> > We're already at device_initcall() level here, so that shouldn't be much of
> > an additional delay.
>
> Either the delay is not relevant, in which case we should entirely
> remove `add_early_randomness()`,
There's another subtlety going on here: add_device_randomness() is called
for *all* hw_random devices upon their registration, while the hwrng thread
currently only works with the hw_random device with the best quality
available.
Thanks,
Dominik
Hi Herbert,
On Mon, Nov 7, 2022 at 3:17 AM Herbert Xu <[email protected]> wrote:
>
> On Sun, Nov 06, 2022 at 04:02:43PM +0100, Jason A. Donenfeld wrote:
> > Rather than calling add_device_randomness(), the add_early_randomness()
> > function should use add_hwgenerator_randomness(), so that the early
> > entropy can be potentially credited, which allows for the RNG to
> > initialize earlier without having to wait for the kthread to come up.
> >
> > This requires some minor API refactoring, by adding a `sleep_after`
> > parameter to add_hwgenerator_randomness(), so that we don't hit a
> > blocking sleep from add_early_randomness().
> >
> > Cc: Herbert Xu <[email protected]>
> > Cc: Dominik Brodowski <[email protected]>
> > Signed-off-by: Jason A. Donenfeld <[email protected]>
> > ---
> > Herbert - it might be easiest for me to take this patch if you want? Or
> > if this will interfere with what you have going on, you can take it. Let
> > me know what you feel like. -Jason
>
> I don't have anything that touches this file so feel free to push
> it through your tree:
>
> Acked-by: Herbert Xu <[email protected]>
Okay, will do. But by the way, feel free to change your mind about
this if need be. For example, I sent another patch that touches core.c
too (the entropy quality one). It touches different lines, so there
shouldn't be a conflict, but if it's still annoying for you and you
want to take them both, just pipe up and I'll drop this one from my
tree.
Jason
On Mon, Nov 07, 2022 at 01:55:53PM +0100, Jason A. Donenfeld wrote:
>
> Okay, will do. But by the way, feel free to change your mind about
> this if need be. For example, I sent another patch that touches core.c
> too (the entropy quality one). It touches different lines, so there
> shouldn't be a conflict, but if it's still annoying for you and you
> want to take them both, just pipe up and I'll drop this one from my
> tree.
They look like they shouldn't really conflict so it should be
fine.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Il 06/11/22 16:02, Jason A. Donenfeld ha scritto:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.
>
> This requires some minor API refactoring, by adding a `sleep_after`
> parameter to add_hwgenerator_randomness(), so that we don't hit a
> blocking sleep from add_early_randomness().
>
> Cc: Herbert Xu <[email protected]>
> Cc: Dominik Brodowski <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> Acked-by: Herbert Xu <[email protected]>
> ---
> Herbert - it might be easiest for me to take this patch if you want? Or
> if this will interfere with what you have going on, you can take it. Let
> me know what you feel like. -Jason
>
> drivers/char/hw_random/core.c | 8 +++++---
> drivers/char/random.c | 12 ++++++------
> include/linux/random.h | 2 +-
> 3 files changed, 12 insertions(+), 10 deletions(-)
>
Hello,
I tried booting next-20221108 on Acer Tomato Chromebook (MediaTek MT8195) but
this commit is producing a kernel panic.
Trace follows:
[ 2.957452] cr50_i2c 3-0050: cr50 TPM 2.0 (i2c 0x50 irq 114 id 0x28)
[ 3.047508] ------------[ cut here ]------------
[ 3.052178] WARNING: CPU: 5 PID: 1 at kernel/kthread.c:75
kthread_should_stop+0x2c/0x44
[ 3.060270] Modules linked in:
[ 3.063359] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc4-next-20221108+ #111
[ 3.071086] Hardware name: Acer Tomato (rev2) board (DT)
[ 3.076447] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 3.083473] pc : kthread_should_stop+0x2c/0x44
[ 3.087962] lr : add_hwgenerator_randomness+0x6c/0x110
[ 3.093152] sp : ffff80000808b570
[ 3.096499] x29: ffff80000808b570 x28: 0000000000061a80 x27: 00000000000f4240
[ 3.103707] x26: ffff030f3efe9d78 x25: ffffd855b3930000 x24: 0000000000000000
[ 3.110915] x23: 0000000000000000 x22: ffffd855b2c00d08 x21: 0000000000000020
[ 3.118122] x20: 0000000000000000 x19: ffffd855b2c00c90 x18: 000000000000001c
[ 3.125328] x17: 000000005358439e x16: ffffd855b2c00d00 x15: 000000003be00b9b
[ 3.132534] x14: 0000000088cee1a7 x13: 025733541e7bfbcb x12: 00000000000000d5
[ 3.139741] x11: 000000009d2113cd x10: 000000009d2113cd x9 : ffffd855b059298c
[ 3.146947] x8 : ffffd855b2dbf980 x7 : 0000000000000000 x6 : 0000000000000002
[ 3.154154] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 00000000000000d5
[ 3.161359] x2 : ffff2ab984b5c000 x1 : 0000000000000040 x0 : ffff030e00290000
[ 3.168565] Call trace:
[ 3.171037] kthread_should_stop+0x2c/0x44
[ 3.175176] add_early_randomness+0xb8/0x124
[ 3.179490] hwrng_register+0x174/0x220
[ 3.183366] tpm_chip_register+0xc4/0x290
[ 3.187417] tpm_cr50_i2c_probe+0x27c/0x2c0
[ 3.191642] i2c_device_probe+0x10c/0x360
[ 3.195695] really_probe+0xc8/0x3e0
[ 3.199307] __driver_probe_device+0x84/0x190
[ 3.203706] driver_probe_device+0x44/0x120
[ 3.207929] __device_attach_driver+0xc4/0x160
[ 3.212415] bus_for_each_drv+0x80/0xe0
[ 3.216288] __device_attach+0xb0/0x1f0
[ 3.220162] device_initial_probe+0x1c/0x30
[ 3.224386] bus_probe_device+0xa4/0xb0
[ 3.228260] device_add+0x3d0/0x8d0
[ 3.231788] device_register+0x28/0x40
[ 3.235577] i2c_new_client_device+0x15c/0x29c
[ 3.240067] of_i2c_register_device+0xc4/0xf0
[ 3.244465] of_i2c_register_devices+0x84/0x140
[ 3.249040] i2c_register_adapter+0x200/0x6dc
[ 3.253442] __i2c_add_numbered_adapter+0x68/0xc0
[ 3.258194] i2c_add_adapter+0xb0/0xe0
[ 3.261982] mtk_i2c_probe+0x4e8/0x660
[ 3.265771] platform_probe+0x70/0xe0
[ 3.269471] really_probe+0xc8/0x3e0
[ 3.273082] __driver_probe_device+0x84/0x190
[ 3.277481] driver_probe_device+0x44/0x120
[ 3.281704] __driver_attach+0xb8/0x230
[ 3.285577] bus_for_each_dev+0x78/0xdc
[ 3.289450] driver_attach+0x2c/0x3c
[ 3.293061] bus_add_driver+0x184/0x240
[ 3.296935] driver_register+0x80/0x13c
[ 3.300809] __platform_driver_register+0x30/0x3c
[ 3.305559] mtk_i2c_driver_init+0x24/0x30
[ 3.309699] do_one_initcall+0x7c/0x3d0
[ 3.313574] kernel_init_freeable+0x308/0x378
[ 3.317977] kernel_init+0x2c/0x140
[ 3.321505] ret_from_fork+0x10/0x20
[ 3.325117] irq event stamp: 620756
[ 3.328639] hardirqs last enabled at (620755): [<ffffd855b0fc7cb4>]
_raw_spin_unlock_irqrestore+0xa4/0xb0
[ 3.338382] hardirqs last disabled at (620756): [<ffffd855b0fb9724>]
el1_dbg+0x24/0x90
[ 3.346373] softirqs last enabled at (618152): [<ffffd855afc10be4>]
__do_softirq+0x414/0x588
[ 3.354973] softirqs last disabled at (618147): [<ffffd855afc171d8>]
____do_softirq+0x18/0x24
[ 3.363575] ---[ end trace 0000000000000000 ]---
[ 3.368278] Unable to handle kernel NULL pointer dereference at virtual address
0000000000000000
[ 3.377165] Mem abort info:
[ 3.380006] ESR = 0x0000000096000004
[ 3.383824] EC = 0x25: DABT (current EL), IL = 32 bits
[ 3.389203] SET = 0, FnV = 0
[ 3.392306] EA = 0, S1PTW = 0
[ 3.395494] FSC = 0x04: level 0 translation fault
[ 3.400432] Data abort info:
[ 3.403359] ISV = 0, ISS = 0x00000004
[ 3.407261] CM = 0, WnR = 0
[ 3.410275] [0000000000000000] user address but active_mm is swapper
[ 3.416720] Internal error: Oops: 0000000096000004 [#1] SMP
[ 3.422290] Modules linked in:
[ 3.425338] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G W
6.1.0-rc4-next-20221108+ #111
[ 3.434466] Hardware name: Acer Tomato (rev2) board (DT)
[ 3.439772] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 3.446728] pc : kthread_should_stop+0x38/0x44
[ 3.451170] lr : add_hwgenerator_randomness+0x6c/0x110
[ 3.456304] sp : ffff80000808b570
[ 3.459611] x29: ffff80000808b570 x28: 0000000000061a80 x27: 00000000000f4240
[ 3.466743] x26: ffff030f3efe9d78 x25: ffffd855b3930000 x24: 0000000000000000
[ 3.473875] x23: 0000000000000000 x22: ffffd855b2c00d08 x21: 0000000000000020
[ 3.481007] x20: 0000000000000000 x19: ffffd855b2c00c90 x18: 000000000000001c
[ 3.488139] x17: 000000005358439e x16: ffffd855b2c00d00 x15: 000000003be00b9b
[ 3.495270] x14: 0000000088cee1a7 x13: 025733541e7bfbcb x12: 00000000000000d5
[ 3.502402] x11: 000000009d2113cd x10: 000000009d2113cd x9 : ffffd855b059298c
[ 3.509533] x8 : ffffd855b2dbf980 x7 : 0000000000000000 x6 : 0000000000000002
[ 3.516665] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 00000000000000d5
[ 3.523796] x2 : ffff2ab984b5c000 x1 : 0000000000000040 x0 : 0000000000000000
[ 3.530927] Call trace:
[ 3.533366] kthread_should_stop+0x38/0x44
[ 3.537459] add_early_randomness+0xb8/0x124
[ 3.541725] hwrng_register+0x174/0x220
[ 3.545557] tpm_chip_register+0xc4/0x290
[ 3.549562] tpm_cr50_i2c_probe+0x27c/0x2c0
[ 3.553739] i2c_device_probe+0x10c/0x360
[ 3.557746] really_probe+0xc8/0x3e0
[ 3.561316] __driver_probe_device+0x84/0x190
[ 3.565667] driver_probe_device+0x44/0x120
[ 3.569845] __device_attach_driver+0xc4/0x160
[ 3.574284] bus_for_each_drv+0x80/0xe0
[ 3.578115] __device_attach+0xb0/0x1f0
[ 3.581944] device_initial_probe+0x1c/0x30
[ 3.586122] bus_probe_device+0xa4/0xb0
[ 3.589952] device_add+0x3d0/0x8d0
[ 3.593437] device_register+0x28/0x40
[ 3.597183] i2c_new_client_device+0x15c/0x29c
[ 3.601623] of_i2c_register_device+0xc4/0xf0
[ 3.605974] of_i2c_register_devices+0x84/0x140
[ 3.610499] i2c_register_adapter+0x200/0x6dc
[ 3.614853] __i2c_add_numbered_adapter+0x68/0xc0
[ 3.619555] i2c_add_adapter+0xb0/0xe0
[ 3.623300] mtk_i2c_probe+0x4e8/0x660
[ 3.627044] platform_probe+0x70/0xe0
[ 3.630702] really_probe+0xc8/0x3e0
[ 3.634271] __driver_probe_device+0x84/0x190
[ 3.638622] driver_probe_device+0x44/0x120
[ 3.642800] __driver_attach+0xb8/0x230
[ 3.646631] bus_for_each_dev+0x78/0xdc
[ 3.650460] driver_attach+0x2c/0x3c
[ 3.654030] bus_add_driver+0x184/0x240
[ 3.657859] driver_register+0x80/0x13c
[ 3.661690] __platform_driver_register+0x30/0x3c
[ 3.666390] mtk_i2c_driver_init+0x24/0x30
[ 3.670483] do_one_initcall+0x7c/0x3d0
[ 3.674313] kernel_init_freeable+0x308/0x378
[ 3.678668] kernel_init+0x2c/0x140
[ 3.682153] ret_from_fork+0x10/0x20
[ 3.685725] Code: d65f03c0 d4210000 f9431c00 d50323bf (f9400000)
[ 3.691813] ---[ end trace 0000000000000000 ]---
[ 3.696984] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 3.704636] SMP: stopping secondary CPUs
[ 3.708557] Kernel Offset: 0x5855a7c00000 from 0xffff800008000000
[ 3.714644] PHYS_OFFSET: 0xfffffcf300000000
[ 3.718820] CPU features: 0x30000,001700a4,6600720b
[ 3.723691] Memory Limit: none
[ 3.727265] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b ]---
Regards,
Angelo
On Tue, Nov 08, 2022 at 11:53:23AM +0100, AngeloGioacchino Del Regno wrote:
> Il 06/11/22 16:02, Jason A. Donenfeld ha scritto:
> > Rather than calling add_device_randomness(), the add_early_randomness()
> > function should use add_hwgenerator_randomness(), so that the early
> > entropy can be potentially credited, which allows for the RNG to
> > initialize earlier without having to wait for the kthread to come up.
> >
> > This requires some minor API refactoring, by adding a `sleep_after`
> > parameter to add_hwgenerator_randomness(), so that we don't hit a
> > blocking sleep from add_early_randomness().
> >
> > Cc: Herbert Xu <[email protected]>
> > Cc: Dominik Brodowski <[email protected]>
> > Signed-off-by: Jason A. Donenfeld <[email protected]>
> > Acked-by: Herbert Xu <[email protected]>
> > ---
> > Herbert - it might be easiest for me to take this patch if you want? Or
> > if this will interfere with what you have going on, you can take it. Let
> > me know what you feel like. -Jason
> >
> > drivers/char/hw_random/core.c | 8 +++++---
> > drivers/char/random.c | 12 ++++++------
> > include/linux/random.h | 2 +-
> > 3 files changed, 12 insertions(+), 10 deletions(-)
> >
>
> Hello,
>
> I tried booting next-20221108 on Acer Tomato Chromebook (MediaTek MT8195) but
> this commit is producing a kernel panic.
Thanks for the report. I see exactly what the problem is, and I'll send
a v+1 right away.
Jason
Rather than calling add_device_randomness(), the add_early_randomness()
function should use add_hwgenerator_randomness(), so that the early
entropy can be potentially credited, which allows for the RNG to
initialize earlier without having to wait for the kthread to come up.
This requires some minor API refactoring, by adding a `sleep_after`
parameter to add_hwgenerator_randomness(), so that we don't hit a
blocking sleep from add_early_randomness().
Reviewed-by: Dominik Brodowski <[email protected]>
Acked-by: Herbert Xu <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
Changes v3->v4:
- Check `sleep_after` argument before calling `kthread_should_stop()` to
avoid crash when not called from a kthread.
drivers/char/hw_random/core.c | 8 +++++---
drivers/char/random.c | 12 ++++++------
include/linux/random.h | 2 +-
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index cc002b0c2f0c..63a0a8e4505d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -69,8 +69,10 @@ static void add_early_randomness(struct hwrng *rng)
mutex_lock(&reading_mutex);
bytes_read = rng_get_data(rng, rng_fillbuf, 32, 0);
mutex_unlock(&reading_mutex);
- if (bytes_read > 0)
- add_device_randomness(rng_fillbuf, bytes_read);
+ if (bytes_read > 0) {
+ size_t entropy = bytes_read * 8 * rng->quality / 1024;
+ add_hwgenerator_randomness(rng_fillbuf, bytes_read, entropy, false);
+ }
}
static inline void cleanup_rng(struct kref *kref)
@@ -528,7 +530,7 @@ static int hwrng_fillfn(void *unused)
/* Outside lock, sure, but y'know: randomness. */
add_hwgenerator_randomness((void *)rng_fillbuf, rc,
- entropy >> 10);
+ entropy >> 10, true);
}
hwrng_fill = NULL;
return 0;
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 4591d55cb135..6b7aca683b81 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -711,7 +711,7 @@ static void __cold _credit_init_bits(size_t bits)
* the above entropy accumulation routines:
*
* void add_device_randomness(const void *buf, size_t len);
- * void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy);
+ * void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy, bool sleep_after);
* void add_bootloader_randomness(const void *buf, size_t len);
* void add_vmfork_randomness(const void *unique_vm_id, size_t len);
* void add_interrupt_randomness(int irq);
@@ -891,11 +891,11 @@ void add_device_randomness(const void *buf, size_t len)
EXPORT_SYMBOL(add_device_randomness);
/*
- * Interface for in-kernel drivers of true hardware RNGs.
- * Those devices may produce endless random bits and will be throttled
- * when our pool is full.
+ * Interface for in-kernel drivers of true hardware RNGs. Those devices
+ * may produce endless random bits, so this function will sleep for
+ * some amount of time after, if the sleep_after parameter is true.
*/
-void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
+void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy, bool sleep_after)
{
mix_pool_bytes(buf, len);
credit_init_bits(entropy);
@@ -904,7 +904,7 @@ void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy)
* Throttle writing to once every reseed interval, unless we're not yet
* initialized or no entropy is credited.
*/
- if (!kthread_should_stop() && (crng_ready() || !entropy))
+ if (sleep_after && !kthread_should_stop() && (crng_ready() || !entropy))
schedule_timeout_interruptible(crng_reseed_interval());
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
diff --git a/include/linux/random.h b/include/linux/random.h
index 2bdd3add3400..728b29ade208 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -17,7 +17,7 @@ void __init add_bootloader_randomness(const void *buf, size_t len);
void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value) __latent_entropy;
void add_interrupt_randomness(int irq) __latent_entropy;
-void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy);
+void add_hwgenerator_randomness(const void *buf, size_t len, size_t entropy, bool sleep_after);
#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
static inline void add_latent_entropy(void)
--
2.38.1
Il 08/11/22 12:24, Jason A. Donenfeld ha scritto:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.
>
> This requires some minor API refactoring, by adding a `sleep_after`
> parameter to add_hwgenerator_randomness(), so that we don't hit a
> blocking sleep from add_early_randomness().
>
> Reviewed-by: Dominik Brodowski <[email protected]>
> Acked-by: Herbert Xu <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
On MT8192 Asurada, MT8195 Tomato Chromebooks:
Tested-by: AngeloGioacchino Del Regno <[email protected]>
Thanks for the fast fix!
Regards,
Angelo
On 08.11.2022 12:44, AngeloGioacchino Del Regno wrote:
> Il 08/11/22 12:24, Jason A. Donenfeld ha scritto:
>> Rather than calling add_device_randomness(), the add_early_randomness()
>> function should use add_hwgenerator_randomness(), so that the early
>> entropy can be potentially credited, which allows for the RNG to
>> initialize earlier without having to wait for the kthread to come up.
>>
>> This requires some minor API refactoring, by adding a `sleep_after`
>> parameter to add_hwgenerator_randomness(), so that we don't hit a
>> blocking sleep from add_early_randomness().
>>
>> Reviewed-by: Dominik Brodowski <[email protected]>
>> Acked-by: Herbert Xu <[email protected]>
>> Signed-off-by: Jason A. Donenfeld <[email protected]>
>
> Reviewed-by: AngeloGioacchino Del Regno
> <[email protected]>
>
> On MT8192 Asurada, MT8195 Tomato Chromebooks:
> Tested-by: AngeloGioacchino Del Regno
> <[email protected]>
>
> Thanks for the fast fix!
I also confirm that this version fixed the boot issue observed on most
of my test systems with Linux next-20221108.
Tested-by: Marek Szyprowski <[email protected]>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Greeting,
FYI, we noticed WARNING:at_kernel/kthread.c:#kthread_should_stop due to commit (built with gcc-11):
commit: cea83a6b31856293ceab2c6ebab7843322fe105e ("[PATCH v3] hw_random: use add_hwgenerator_randomness() for early entropy")
url: https://github.com/intel-lab-lkp/linux/commits/UPDATE-20221106-230344/Jason-A-Donenfeld/hw_random-use-add_hwgenerator_randomness-for-early-entropy/20221106-044656
base: https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git 30a0b95b1335e12efef89dd78518ed3e4a71a763
patch subject: [PATCH v3] hw_random: use add_hwgenerator_randomness() for early entropy
in testcase: stress-ng
version: stress-ng-x86_64-0.11-06_20221109
with following parameters:
nr_threads: 100%
testtime: 60s
class: cpu
test: str
cpufreq_governor: performance
on test machine: 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz (Cascade Lake) with 512G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
| Reported-by: kernel test robot <[email protected]>
| Link: https://lore.kernel.org/oe-lkp/[email protected]
[ 23.856915][ T1] ------------[ cut here ]------------
[ 23.862386][ T1] WARNING: CPU: 48 PID: 1 at kernel/kthread.c:75 kthread_should_stop (kernel/kthread.c:75 kernel/kthread.c:157)
[ 23.871363][ T1] Modules linked in:
[ 23.875261][ T1] CPU: 48 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc3-00001-gcea83a6b3185 #1
[ 23.884138][ T1] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 23.895447][ T1] RIP: 0010:kthread_should_stop (kernel/kthread.c:75 kernel/kthread.c:157)
[ 23.901164][ T1] Code: 00 0f 1f 44 00 00 65 48 8b 04 25 00 ad 01 00 f6 40 2e 20 74 15 48 8b 80 08 0a 00 00 48 8b 00 48 d1 e8 83 e0 01 c3 cc cc cc cc <0f> 0b eb e7 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00
All code
========
0: 00 0f add %cl,(%rdi)
2: 1f (bad)
3: 44 00 00 add %r8b,(%rax)
6: 65 48 8b 04 25 00 ad mov %gs:0x1ad00,%rax
d: 01 00
f: f6 40 2e 20 testb $0x20,0x2e(%rax)
13: 74 15 je 0x2a
15: 48 8b 80 08 0a 00 00 mov 0xa08(%rax),%rax
1c: 48 8b 00 mov (%rax),%rax
1f: 48 d1 e8 shr %rax
22: 83 e0 01 and $0x1,%eax
25: c3 retq
26: cc int3
27: cc int3
28: cc int3
29: cc int3
2a:* 0f 0b ud2 <-- trapping instruction
2c: eb e7 jmp 0x15
2e: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1)
35: 00 00 00 00
39: 0f .byte 0xf
3a: 1f (bad)
3b: 84 00 test %al,(%rax)
3d: 00 00 add %al,(%rax)
...
Code starting with the faulting instruction
===========================================
0: 0f 0b ud2
2: eb e7 jmp 0xffffffffffffffeb
4: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1)
b: 00 00 00 00
f: 0f .byte 0xf
10: 1f (bad)
11: 84 00 test %al,(%rax)
13: 00 00 add %al,(%rax)
...
[ 23.920849][ T1] RSP: 0000:ffffc90000073b20 EFLAGS: 00010246
[ 23.926910][ T1] RAX: ffff888100df0000 RBX: 0000000000000000 RCX: 0000000000000000
[ 23.934914][ T1] RDX: 000000000000000e RSI: 0000000000000296 RDI: ffffffff830d57b8
[ 23.942914][ T1] RBP: 0000000000000296 R08: 00000000c7b95e77 R09: 00000000294e6f92
[ 23.950912][ T1] R10: 000000000defdd81 R11: 00000000f09cfad9 R12: ffff88c0882c1700
[ 23.958911][ T1] R13: 0000000000000020 R14: 0000000000000000 R15: 00000000001b15d1
[ 23.966910][ T1] FS: 0000000000000000(0000) GS:ffff88bf7fc00000(0000) knlGS:0000000000000000
[ 23.975872][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 23.982459][ T1] CR2: 0000000000000000 CR3: 000000807ee0a001 CR4: 00000000007706e0
[ 23.990463][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 23.998463][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 24.006470][ T1] PKRU: 55555554
[ 24.010006][ T1] Call Trace:
[ 24.013282][ T1] <TASK>
[ 24.016220][ T1] add_hwgenerator_randomness (drivers/char/random.c:885)
[ 24.021853][ T1] hwrng_register (drivers/char/hw_random/core.c:590)
[ 24.026528][ T1] tpm_chip_register (drivers/char/tpm/tpm-chip.c:254)
[ 24.031981][ T1] tpm_tis_core_init.cold (drivers/char/tpm/tpm_tis_core.c:1107)
[ 24.037355][ T1] tpm_tis_plat_probe (drivers/char/tpm/tpm_tis.c:324)
[ 24.042294][ T1] platform_probe (drivers/base/platform.c:1400)
[ 24.046797][ T1] really_probe (drivers/base/dd.c:560 drivers/base/dd.c:639)
[ 24.051207][ T1] ? pm_runtime_barrier (arch/x86/include/asm/paravirt.h:596 arch/x86/include/asm/qspinlock.h:57 include/linux/spinlock.h:203 include/linux/spinlock_api_smp.h:158 include/linux/spinlock.h:400 drivers/base/power/runtime.c:1413)
[ 24.056227][ T1] __driver_probe_device (drivers/base/dd.c:719 drivers/base/dd.c:776)
[ 24.061416][ T1] driver_probe_device (drivers/base/dd.c:808)
[ 24.066347][ T1] __driver_attach (drivers/base/dd.c:1191)
[ 24.071020][ T1] ? __device_attach_driver (drivers/base/dd.c:1135)
[ 24.076558][ T1] ? __device_attach_driver (drivers/base/dd.c:1135)
[ 24.082097][ T1] bus_for_each_dev (drivers/base/bus.c:301)
[ 24.086774][ T1] bus_add_driver (drivers/base/bus.c:618)
[ 24.091443][ T1] driver_register (drivers/base/driver.c:246)
[ 24.096116][ T1] ? tpm_init (drivers/char/tpm/tpm_tis.c:379)
[ 24.100263][ T1] init_tis (drivers/char/tpm/tpm_tis.c:386)
[ 24.104250][ T1] ? tpm_init (drivers/char/tpm/tpm_tis.c:379)
[ 24.108399][ T1] ? ktime_get (kernel/time/timekeeping.c:195 (discriminator 3) kernel/time/timekeeping.c:289 (discriminator 3) kernel/time/timekeeping.c:388 (discriminator 3) kernel/time/timekeeping.c:848 (discriminator 3))
[ 24.112637][ T1] ? tpm_init (drivers/char/tpm/tpm_tis.c:379)
[ 24.116789][ T1] do_one_initcall (init/main.c:1303)
[ 24.121461][ T1] do_initcalls (init/main.c:1375 init/main.c:1392)
[ 24.125784][ T1] kernel_init_freeable (init/main.c:1635)
[ 24.130978][ T1] ? rest_init (init/main.c:1511)
[ 24.135386][ T1] kernel_init (init/main.c:1521)
[ 24.139711][ T1] ret_from_fork (arch/x86/entry/entry_64.S:306)
[ 24.144122][ T1] </TASK>
[ 24.147143][ T1] ---[ end trace 0000000000000000 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
sudo bin/lkp install job.yaml # job file is attached in this email
bin/lkp split-job --compatible job.yaml # generate the yaml file for lkp run
sudo bin/lkp run generated-yaml-file
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
--
0-DAY CI Kernel Test Service
https://01.org/lkp
On Sun, Nov 13, 2022 at 09:48:46PM +0800, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed WARNING:at_kernel/kthread.c:#kthread_should_stop due to commit (built with gcc-11):
>
> commit: cea83a6b31856293ceab2c6ebab7843322fe105e ("[PATCH v3] hw_random: use add_hwgenerator_randomness() for early entropy")
> url: https://github.com/intel-lab-lkp/linux/commits/UPDATE-20221106-230344/Jason-A-Donenfeld/hw_random-use-add_hwgenerator_randomness-for-early-entropy/20221106-044656
> base: https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git 30a0b95b1335e12efef89dd78518ed3e4a71a763
> patch subject: [PATCH v3] hw_random: use add_hwgenerator_randomness() for early entropy
A bit late. v4 was posted a while ago now.