linux-kernel - Re: [PATCH v2 2/2] debugobjects: Disable lockdep tracking of debugobjects internal locks

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: <e3275861-6fbe-70c6-c005-2bfe80cbba0b@redhat.com>
Date:   Tue, 25 Sep 2018 12:20:05 -0400
From:   Waiman Long <longman@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Arnd Bergmann <arnd@...db.de>, chuhu@...hat.com
Subject: Re: [PATCH v2 2/2] debugobjects: Disable lockdep tracking of
 debugobjects internal locks

On 09/25/2018 11:32 AM, Peter Zijlstra wrote:
> On Tue, Sep 25, 2018 at 10:41:09AM -0400, Waiman Long wrote:
>> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
>> index 70935ed91125..68d72ed9ca22 100644
>> --- a/lib/debugobjects.c
>> +++ b/lib/debugobjects.c
>> @@ -1106,8 +1106,15 @@ void __init debug_objects_early_init(void)
>>  {
>>  	int i;
>>  
>> -	for (i = 0; i < ODEBUG_HASH_SIZE; i++)
>> +	/*
>> +	 * We don't need lockdep to verify correctness of debugobjects
>> +	 * internal locks.
>> +	 */
>> +	lockdep_set_novalidate_class(&pool_lock);
>> +	for (i = 0; i < ODEBUG_HASH_SIZE; i++) {
>>  		raw_spin_lock_init(&obj_hash[i].lock);
>> +		lockdep_set_novalidate_class(&obj_hash[i].lock);
>> +	}
>>  
>>  	for (i = 0; i < ODEBUG_POOL_SIZE; i++)
>>  		hlist_add_head(&obj_static_pool[i].node, &obj_pool);
> NAK, we do not _EVER_ set novalidate if it can at all be avoided.
>
> If there is a severe performance problem with lockdep, try and cure
> that. But really, who runs lockdep kernels on 8 sockets?

We do. It is part of our testing process to run both production and
debug kernels on a variety of different machines to see if anything
breaks. Some of them just happen to be 8-socket systems.

The internal locks in the debugobjects code don't interact with other
locks at all as memory allocation isn't called with those lock held. So
disabling lockdep for those locks won't materially affect the accuracy
of the lockdep code.

How about the ability to declare a class of locks as terminal in the
sense that no further lock acquisition is allowed while holding a
terminal lock? That will allow the the lockdep code to fast track the
handling of those locks and hopefully prevent hard lockup problem like that.

Cheers,
Longman