Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 19 Jun 2022 18:38:11 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [GIT pull] locking/urgent for 5.19-rc3
Message-ID: <Yq9Q84H6HIfkJpoR@zx2c4.com>
References: <165564429738.1413209.17302088152547038708.tglx@xen13>
 <165564429887.1413209.8729918730024457105.tglx@xen13>
 <CAHk-=wgfrUdWBXA-Jx7ZC1x3wwsomou0L6niGgpRS2Hd5rQxyg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wgfrUdWBXA-Jx7ZC1x3wwsomou0L6niGgpRS2Hd5rQxyg@mail.gmail.com>
Precedence: bulk

Hi Linus,

On Sun, Jun 19, 2022 at 09:50:32AM -0500, Linus Torvalds wrote:
> On Sun, Jun 19, 2022 at 8:12 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > A RT fix for lockdep. lockdep invokes prandom_u32() to create cookies. This
> > worked until prandom_u32() was switched to the real random generator, which
> > takes a spinlock for extraction, which does not work on RT when invoked
> > from atomic contexts. lockdep has no requirement for real random numbers
> > and it turns out sched_clock() is good enough to create the cookie. That
> > works everywhere and is faster.
> 
> So this is obviously fine and works ok, but I do think it highlights
> that maybe that prandom change was a bad bad idea.
> 
> Even outside of RT, you might end up getting nasty locks within locks.
> Not a deadlock, but a "this was just pointless".

This was initially my concern too, which I expressed to Sebastian, but
he made the point that this area here is rather "special". Actually,
randomness isn't really required here. A counter would have worked, but
Peter thought that sched_clock() would be faster than incrementing a
counter. And if it did want some sort of max period generator that's not
sequential, there's still the deterministic prandom_u32_state()
function.

Anyway, if it turns out that this is terrible, and we're running into
issues all over the place, I'll start looking for more comprehensive
solutions. But as long as very special cases are fairly few and rare, it
seems like it's going to be okay. I guess we'll see. For now, I'm
undeterred.

Jason