linux-kernel - Re: [RFC 0/9] Nginx refcount scalability issue with Apparmor enabled and potential solutions

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 for Android: free password hash cracker in your pocket

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

Date: Wed, 29 May 2024 11:38:04 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: John Johansen <john.johansen@...onical.com>
Cc: Neeraj Upadhyay <Neeraj.Upadhyay@....com>, paul@...l-moore.com, jmorris@...ei.org, 
	serge@...lyn.com, linux-security-module@...r.kernel.org, 
	linux-kernel@...r.kernel.org, "Gautham R. Shenoy" <gautham.shenoy@....com>, 
	"Shukla, Santosh" <Santosh.Shukla@....com>, "Narayan, Ananth" <Ananth.Narayan@....com>, 
	raghavendra.kodsarathimmappa@....com, koverstreet@...gle.com, 
	paulmck@...nel.org, boqun.feng@...il.com, vinicius.gomes@...el.com
Subject: Re: [RFC 0/9] Nginx refcount scalability issue with Apparmor enabled
 and potential solutions

On Wed, May 29, 2024 at 2:37 AM John Johansen
<john.johansen@...onical.com> wrote:
> I don't have objections to moving towards percpu refcounts, but the overhead
> of a percpu stuct per label is a problem when we have thousands of labels
> on the system. That is to say, this would have to be a config option. We
> moved buffers from kmalloc to percpu to reduce memory overhead to reduce
> contention. The to percpu, to a global pool because the percpu overhead was
> too high for some machines, and then from a global pool to a hybrid scheme
> because of global lock contention. I don't see a way of doing that with the
> label, which means a config would be the next best thing.
>

There was a patchset somewhere which adds counters starting as atomic
and automagically converting themselves per-cpu if there as enough
load applied to them. General point being it is plausible this may
autotune itself.

Another option would be a boot-time tunable.

> Not part of your patch but something to be considered is that the label tree
> needs a rework, its locking needs to move to read side a read side lock less
> scheme, and the plan was to make it also use a linked list such that new
> labels are always queued at the end, allowing dynamically created labels to
> be lazily added to the tree.
>

It's not *my* patchset. ;)

> I see the use of the kworker as problematic as well, especially if we are
> talking using kconfig to switch reference counting modes. I am futzing with
> some ideas, on how to deal with this.
>

Thanks for the update. Hopefully this is going to get sorted out in
the foreseeable future.

-- 
Mateusz Guzik <mjguzik gmail.com>