From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4AECC6379A for ; Mon, 19 Jul 2021 18:27:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A9FD260FDB for ; Mon, 19 Jul 2021 18:27:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382721AbhGSRmR (ORCPT ); Mon, 19 Jul 2021 13:42:17 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:58980 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357721AbhGSQwQ (ORCPT ); Mon, 19 Jul 2021 12:52:16 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]:57914) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m5X8Q-00C5r8-9k; Mon, 19 Jul 2021 11:32:54 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:34170 helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m5X8P-003nal-5j; Mon, 19 Jul 2021 11:32:53 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Vasily Averin Cc: Andrew Morton , cgroups@vger.kernel.org, Michal Hocko , Shakeel Butt , Johannes Weiner , Vladimir Davydov , Roman Gushchin , Jens Axboe , Oleg Nesterov , linux-kernel@vger.kernel.org References: Date: Mon, 19 Jul 2021 12:32:46 -0500 In-Reply-To: (Vasily Averin's message of "Mon, 19 Jul 2021 13:45:44 +0300") Message-ID: <87k0lmryyp.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1m5X8P-003nal-5j;;;mid=<87k0lmryyp.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19riCDlCttkz1EHUrkai0JB6kWYfxt9MHc= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v5 13/16] memcg: enable accounting for signals X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vasily Averin 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 > Signed-off-by: Vasily Averin > --- > 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