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@xxxxxxxxxxxx> 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
