linux-kernel - Re: [PATCH v3] apparmor: global buffers spin lock may get contended

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]

Date:   Mon, 20 Feb 2023 00:42:35 -0800
From:   John Johansen <john.johansen@...onical.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     LKLM <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Tomasz Figa <tfiga@...omium.org>,
        linux-security-module@...r.kernel.org,
        Anil Altinay <aaltinay@...gle.com>
Subject: Re: [PATCH v3] apparmor: global buffers spin lock may get contended

On 2/17/23 02:44, Sebastian Andrzej Siewior wrote:
> On 2023-02-16 16:08:10 [-0800], John Johansen wrote:
>> --- a/security/apparmor/lsm.c
>> +++ b/security/apparmor/lsm.c
>> @@ -49,12 +49,19 @@ union aa_buffer {
>>   	char buffer[1];
>>   };
>> +struct aa_local_cache {
>> +	unsigned int contention;
>> +	unsigned int hold;
>> +	struct list_head head;
>> +};
> 
> if you stick a local_lock_t into that struct, then you could replace
> 	cache = get_cpu_ptr(&aa_local_buffers);
> with
> 	local_lock(&aa_local_buffers.lock);
> 	cache = this_cpu_ptr(&aa_local_buffers);
> 
> You would get the preempt_disable() based locking for the per-CPU
> variable (as with get_cpu_ptr()) and additionally some lockdep
> validation which would warn if it is used outside of task context (IRQ).
> 
I did look at local_locks and there was a reason I didn't use them. I
can't recall as the original iteration of this is over a year old now.
I will have to dig into it again.

> I didn't parse completely the hold/contention logic but it seems to work
> ;)
> You check "cache->count >=  2" twice but I don't see an inc/ dec of it
> nor is it part of aa_local_cache.
> 
sadly I messed up the reordering of this and the debug patch. This will be
fixed in v4.

> I can't parse how many items can end up on the local list if the global
> list is locked. My guess would be more than 2 due the ->hold parameter.
> 
So this iteration, forces pushing back to global list if there are already
two on the local list. The hold parameter just affects how long the
buffers remain on the local list, before trying to place them back on
the global list.

Originally before the count was added more than 2 buffers could end up
on the local list, and having too many local buffers is a waste of
memory. The count got added to address this. The value of 2 (which should
be switched to a define) was chosen because no mediation routine currently
uses more than 2 buffers.

Note that this doesn't mean that more than two buffers can be allocated
to a tasks on a cpu. Its possible in some cases to have a task have
allocated buffers and to still have buffers on the local cache list.

> Do you have any numbers on the machine and performance it improved? It
> sure will be a good selling point.
> 

I can include some supporting info, for a 16 core machine. But it will
take some time to for me to get access to a bigger machine, where this
is much more important. Hence the call for some of the other people
on this thread to test.

thanks for the feedback