Re: [PATCH] signal: restore the override_rlimit logic

[Alexey Gladkov <legion@kernel.org>]

On Fri, Nov 01, 2024 at 03:44:48PM -0700, Andrei Vagin wrote:
> On Fri, Nov 1, 2024 at 1:58 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> 
> > > Well, personally I'd not use this limit too, but I don't think
> > > "it's broken, userspace shouldn't use it" argument is valid.
> >
> > I said if you don't want the limit don't use it.
> >
> > A version of "Doctor it hurts when I do this". To which the doctor
> > replies "Don't do that then".
> 
> Unfortunately, it isn't an option here. This is a non-root user that
> creates a new user-namespace. It can't change RLIMIT_SIGPENDING
> beyond the current limit.
> 
> We have to distinguish between two types of signals:
> 
> * Kernel signals: These are essential for proper application behavior.
> If a user process triggers a memory fault, it gets SIGSEGV and it can’t
> ignore it. The number of such signals is limited by one per user thread.
> 
> * User signals: These are sent by users and can be blocked by the
> receiving process, potentially leading to a large queue of pending
> signals. This is where the RLIMIT_SIGPENDING limit plays its role in
> preventing excessive resource consumption.
> 
> New user namespaces inherit the current sigpending rlimit, so it is
> expected that  the behavior of the user-namespace limit is aligned with
> the overall RLIMIT_SIGPENDING mechanism.

Hm. I think I understand the problem now.

+Cc Oleg Nesterov.

-- 
Rgrds, legion