Re: [PATCH v5 13/16] memcg: enable accounting for signals
From: Eric W. Biederman <hidden>
Date: 2021-07-19 18:27:16
Also in:
lkml
Vasily Averin [off-list ref] writes:
When a user send a signal to any another processes it forces the kernel to allocate memory for 'struct sigqueue' objects. The number of signals is limited by RLIMIT_SIGPENDING resource limit, but even the default settings allow each user to consume up to several megabytes of memory. Moreover, an untrusted admin inside container can increase the limit or create new fake users and force them to sent signals.
Not any more. Currently the number of sigqueue objects is limited by the rlimit of the creator of the user namespace of the container.
It makes sense to account for these allocations to restrict the host's memory consumption from inside the memcg-limited container.
Does it? Why? The given justification appears to have bit-rotted since -rc1. I know a lot of these things only really need a limit just to catch a program that starts malfunctioning. If that is indeed the case reasonable per-resource limits are probably better than some great big group limit that can be exhausted with any single resource in the group. Is there a reason I am not aware of that where it makes sense to group all of the resources together and only count the number of bytes consumed? Eric
quoted hunk
Signed-off-by: Vasily Averin <redacted> --- kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)diff --git a/kernel/signal.c b/kernel/signal.c index a3229ad..8921c4a 100644 --- a/kernel/signal.c +++ b/kernel/signal.c@@ -4663,7 +4663,7 @@ void __init signals_init(void) { siginfo_buildtime_checks(); - sigqueue_cachep = KMEM_CACHE(sigqueue, SLAB_PANIC); + sigqueue_cachep = KMEM_CACHE(sigqueue, SLAB_PANIC | SLAB_ACCOUNT); } #ifdef CONFIG_KGDB_KDB