Messages in this thread | | | Date | Tue, 7 Jun 2022 18:51:20 +0200 | From | Sebastian Andrzej Siewior <> | Subject | Re: [PATCH] locking/lockdep: Use sched_clock() for random numbers. |
| |
On 2022-05-17 11:16:14 [+0200], To linux-kernel@vger.kernel.org wrote: > Since the rewrote of prandom_u32(), in the commit mentioned below, the > function uses sleeping locks which extracing random numbers and filling > the batch. > This breaks lockdep on PREEMPT_RT because lock_pin_lock() disables > interrupts while calling __lock_pin_lock(). This can't be moved earlier > because the main user of the function (rq_pin_lock()) invokes that > function after disabling interrupts in order to acquire the lock. > > The cookie does not require random numbers as its goal is to provide a > random value in order to notice unexpected "unlock + lock" sites. > > Use sched_clock() to provide random numbers. > > Fixes: a0103f4d86f88 ("random32: use real rng for non-deterministic randomness") > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > --- > > So if the architecture does not provide sched_clock() and does not > enabled GENERIC_SCHED_CLOCK then we use jiffies here. Most of them do > one or the other except for alpha, csky, hexagon, ... but I don't worry > here since arm*, power*, x86* do provide it.
ping.
Jason suggested atomic_inc_return(&some_global).
> kernel/locking/lockdep.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 81e87280513ea..f06b91ca6482d 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -5432,7 +5432,7 @@ static struct pin_cookie __lock_pin_lock(struct lockdep_map *lock) > * be guessable and still allows some pin nesting in > * our u32 pin_count. > */ > - cookie.val = 1 + (prandom_u32() >> 16); > + cookie.val = 1 + (sched_clock() & 0xffff); > hlock->pin_count += cookie.val; > return cookie; > }
Sebastian
| |