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.