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. > > I was also asking that you test with the limit disabled (at user > namespace creation time) so that you can verify that is problem. > > >> The maximum for rlimit(RLIM_SIGPENDING) is the rlimit(RLIM_SIGPENDING) > >> value when the user namespace is created. > >> > >> Given that it took 3 and half years to report this. I am going to > >> say this really looks like a userspace bug. This issue was introduced in v5.15. The latest rhel release, 9.4, is based on v5.14... 3.5 years is not a long time... Thanks, Andrei
