linux-kernel - Re: [RFC next v2 0/5] ucount: add rlimit cache for ucount

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: <CAEWA0a6t8nsXkiM=VF_zQ+vk+6hrbGt23oig1jf8No2GopGR1w@mail.gmail.com>
Date: Thu, 22 May 2025 15:48:35 -0700
From: Andrei Vagin <avagin@...gle.com>
To: Alexey Gladkov <legion@...nel.org>
Cc: Chen Ridong <chenridong@...weicloud.com>, akpm@...ux-foundation.org, 
	paulmck@...nel.org, bigeasy@...utronix.de, roman.gushchin@...ux.dev, 
	brauner@...nel.org, tglx@...utronix.de, frederic@...nel.org, 
	peterz@...radead.org, oleg@...hat.com, joel.granados@...nel.org, 
	viro@...iv.linux.org.uk, lorenzo.stoakes@...cle.com, mengensun@...cent.com, 
	linux@...ssschuh.net, jlayton@...nel.org, ruanjinjie@...wei.com, 
	kees@...nel.org, linux-kernel@...r.kernel.org, lujialin4@...wei.com, 
	Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [RFC next v2 0/5] ucount: add rlimit cache for ucount

On Wed, May 21, 2025 at 12:29 AM Alexey Gladkov <legion@...nel.org> wrote:
<....>
>
> > > All I'm saying is that "bottleneck" with atomic counter was there before
> > > and can't be removed anywhere.
> > >
> >
> > Yes, it can not be removed anywhere, maybe we can make it better.
>
> Yes, we probably can, but we need to have a reason to complicate the code.
> And we're still talking about a synthetic test.

I think I have a real use case that will be negatively impacted by this
issue. This involves gVisor with the systrap platform. gVisor is an
application kernel, similar to user-mode Linux. The systrap platform
utilizes seccomp to intercept guest syscalls, meaning each guest syscall
triggers a SIGSYS signal. For some workloads, the signal handling overhead
accounts for over 50% of the total workload execution time.

However, considering the gVisor problem, I think the solution could be
simpler. Each task could reserve one signal in advance. Then, when a signal
is triggered by an 'exception' (e.g., seccomp or page fault), the kernel
could queue a force signal without incurring a ucount charge. Even
currently, such signals are allocated with the override_rlimit flag set,
meaning they are not subject to standard resource limits.

Thanks,
Andrei