Messages in this thread | | | Date | Thu, 9 Jun 2022 14:18:44 +0200 | From | "Jason A. Donenfeld" <> | Subject | Re: [PATCH printk v5 1/1] printk: extend console_lock for per-console locking |
| |
Hey again,
On Thu, Jun 09, 2022 at 01:58:44PM +0200, Jason A. Donenfeld wrote: > Hi John, > > On Thu, Jun 09, 2022 at 01:25:15PM +0206, John Ogness wrote: > > (Added RANDOM NUMBER DRIVER and KFENCE people.) > > Thanks. > > > I am guessing you have CONFIG_PROVE_RAW_LOCK_NESTING enabled? > > > > We are seeing a spinlock (base_crng.lock) taken while holding a > > raw_spinlock (meta->lock). > > > > kfence_guarded_alloc() > > raw_spin_trylock_irqsave(&meta->lock, flags) > > prandom_u32_max() > > prandom_u32() > > get_random_u32() > > get_random_bytes() > > _get_random_bytes() > > crng_make_state() > > spin_lock_irqsave(&base_crng.lock, flags); > > > > I expect it is allowed to create kthreads via kthread_run() in > > early_initcalls. > > AFAIK, CONFIG_PROVE_RAW_LOCK_NESTING is useful for teasing out cases > where RT's raw spinlocks will nest wrong with RT's sleeping spinlocks. > But nobody who wants an RT kernel will be using KFENCE. So this seems > like a non-issue? Maybe just add a `depends on !KFENCE` to > PROVE_RAW_LOCK_NESTING?
On second thought, the fix is trivial: https://lore.kernel.org/lkml/20220609121709.12939-1-Jason@zx2c4.com/
Jason
| |