linux-kernel - Re: Linux 6.3-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c5f4fe2d-fc32-cb2f-669c-c9c5f6e3b46e@roeck-us.net>
Date:   Mon, 13 Mar 2023 15:49:26 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.3-rc2

On 3/13/23 15:16, Linus Torvalds wrote:
> On Mon, Mar 13, 2023 at 1:30 PM Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> It gets weird. Bisect log below. Reverting the identified patch does
>> indeed seem to fix the problem, only I have no clue why this might
>> be the case. The patch looks completely innocent to me. Yet, I can
>> reliably reproduce the problem with v6.3-rc2, but at least so far I
>> have not been able to reproduce it with commit f3dd0c53370 reverted
>> (and I am trying on five different servers in parallel).
> 
> Yeah, that commit looks very innocuous. I'm surprised it would even
> change any code generation, but it's very possible that it ends up
> affecting some code layout or something almost by mistake.
> 
> I'd be inclined to think that the problem is very timing-sensitive,
> and has probably been there for a while, and some random moon phase
> just made it happen now.
> 

Maybe, but it seems unlikely. I can reliably reproduce the problem
with v6.3-rc2. Typically it takes some 20-30 boot attempts to see it. With
f3dd0c53370 reverted I tried more than 1,000 boot attempts and did not see
the problem. I also don't recall ever having seen it before.

Anyway, I'll probably just disable CONFIG_DEBUG_LOCK_ALLOC for my
arm boot tests to avoid the message. I don't want it to create noise
and hide other problems.

Thanks,
Guenter