linux-kernel - Re: BUG: MAX_LOCKDEP_CHAIN

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] [day] [month] [year] [list]

Message-Id: <2ffd1b69-76c2-4e15-a139-1406746ae4ef@app.fastmail.com>
Date:   Fri, 27 Jan 2023 10:33:27 -0500
From:   "Chris Murphy" <lists@...orremedies.com>
To:     "Waiman Long" <longman@...hat.com>,
        "Boqun Feng" <boqun.feng@...il.com>
Cc:     Михаил Гаврилов 
        <mikhail.v.gavrilov@...il.com>, "David Sterba" <dsterba@...e.cz>,
        "Btrfs BTRFS" <linux-btrfs@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "Ingo Molnar" <mingo@...hat.com>, "Will Deacon" <will@...nel.org>,
        "Joel Fernandes" <joel@...lfernandes.org>
Subject: Re: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!



On Fri, Jan 27, 2023, at 9:26 AM, Waiman Long wrote:
> On 1/26/23 23:07, Boqun Feng wrote:
>> On Thu, Jan 26, 2023 at 10:37:56PM -0500, Chris Murphy wrote:
>>>
>>> On Thu, Jan 26, 2023, at 7:20 PM, Waiman Long wrote:
>>>> On 1/26/23 17:42, Mikhail Gavrilov wrote:
>>>>>> I'm not sure whether these options are better than just increasing the
>>>>>> number, maybe to unblock your ASAP, you can try make it 30 and make sure
>>>>>> you have large enough memory to test.
>>>>> About just to increase the LOCKDEP_CHAINS_BITS by 1. Where should this
>>>>> be done? In vanilla kernel on kernel.org? In a specific distribution?
>>>>> or the user must rebuild the kernel himself? Maybe increase
>>>>> LOCKDEP_CHAINS_BITS by 1 is most reliable solution, but it difficult
>>>>> to distribute to end users because the meaning of using packaged
>>>>> distributions is lost (user should change LOCKDEP_CHAINS_BITS in
>>>>> config and rebuild the kernel by yourself).
>>>> Note that lockdep is typically only enabled in a debug kernel shipped by
>>>> a distro because of the high performance overhead. The non-debug kernel
>>>> doesn't have lockdep enabled. When LOCKDEP_CHAINS_BITS isn't big enough
>>>> when testing on the debug kernel, you can file a ticket to the distro
>>>> asking for an increase in CONFIG_LOCKDEP_CHAIN_BITS. Or you can build
>>>> your own debug kernel with a bigger CONFIG_LOCKDEP_CHAIN_BITS.
>>> Fedora bumped CONFIG_LOCKDEP_CHAINS_BITS=17 to 18 just 6 months ago for debug kernels.
>>> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1921
>>>
>>> If 19 the recommended value I don't mind sending an MR for it. But if
>>> the idea is we're going to be back here talking about bumping it to 20
>>> in six months, I'd like to avoid that.
>>>
>> How about a boot parameter then?
>
> A boot parameter doesn't work for a statically allocated array which is 
> determined at compile time. Dynamic memory allocation isn't enabled yet 
> at early boot when lockdep will be used.

Also, at least in Fedora Rawhide where the mainline debug kernels appear, mostly get used non-interactively with automated tests. So if we're going to discover lockdep issues, we need the kernel logs to be reliable at the time those tests are run, and we don't have a practical way of adding another boot parameter just for these tests.

Anyway I went ahead and submitted an MR to bump this to 19.
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2271



-- 
Chris Murphy