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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 DD2CAC636C8 for ; Thu, 15 Jul 2021 17:50:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7F7CF61360 for ; Thu, 15 Jul 2021 17:50:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F7CF61360 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD3F28D00E9; Thu, 15 Jul 2021 13:50:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B83FD8D00CD; Thu, 15 Jul 2021 13:50:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4C188D00E9; Thu, 15 Jul 2021 13:50:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 7DB608D00CD for ; Thu, 15 Jul 2021 13:50:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4333720428 for ; Thu, 15 Jul 2021 17:50:55 +0000 (UTC) X-FDA: 78365562870.01.7F3B7BB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id A9FE79000264 for ; Thu, 15 Jul 2021 17:50:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=INGSnpl1UpF6CdwmxMLPgOIu/v7mSG58jf2OlaWN2WI=; b=I3elTLEKAqHwyiShzj/pAC4cdj loGG8gASgYQuRt8tigUzu7jKCXIIchfjOEQKJ4zotfEnlnm02Nm4Q4gMMVPhFM6fqwOWDaLxEDVri pIXgQ7ogB8LVZ2ivfcStsBpCktqX8DthN8Rd9SUTdszdJJ9j22PwQX2k9jWTdkIhsLt4sJUODpIus 2Cj4shRfDtqsNCfRjET45e9wvbkRvq2p4IJfLB0pelAedzrQoF4OUHiYlnmS3iVB5RCemKQwbm6HN HCdGV7Z343mVYcaWLc0ZfkBezLidn5096fEal0EuIS5v7XxHP/vahh0f86qSzBbpKO9oYHwexdYuZ fm4d4pNw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m45Ts-003ahC-4d; Thu, 15 Jul 2021 17:49:17 +0000 Date: Thu, 15 Jul 2021 18:49:04 +0100 From: Matthew Wilcox To: Yutian Yang Cc: mhocko@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, cgroups@vger.kernel.org, linux-mm@kvack.org, shenwenbo@zju.edu.cn Subject: Re: [PATCH] memcg: charge semaphores and sem_undo objects Message-ID: References: <1626333284-1404-1-git-send-email-nglaive@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1626333284-1404-1-git-send-email-nglaive@gmail.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A9FE79000264 X-Stat-Signature: jy55pqybiu6f6gr34wz5zbm3qbwwjoqc Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=I3elTLEK; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1626371453-402933 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 15, 2021 at 03:14:44AM -0400, Yutian Yang wrote: > This patch adds accounting flags to semaphores and sem_undo allocation > sites so that kernel could correctly charge these objects. > > A malicious user could take up more than 63GB unaccounted memory under > default sysctl settings by exploiting the unaccounted objects. She could > allocate up to 32,000 unaccounted semaphore sets with up to 32,000 > unaccounted semaphore objects in each set. She could further allocate one > sem_undo unaccounted object for each semaphore set. Do we really have to account every object that's allocated on behalf of userspace? ie how seriously do we take this kind of thing? Are memcgs supposed to be a hard limit, or are they just a rough accounting thing? There could be a very large stream of patches turning GFP_KERNEL into GFP_KERNEL_ACCOUNT. For example, file locks (fs/locks.c) are only allocated with GFP_KERNEL and you can allocate one lock per byte of a file. I'm sure there are hundreds more places where we do similar things.