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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 581A2C7618D for ; Thu, 6 Apr 2023 08:09:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D9F86B0071; Thu, 6 Apr 2023 04:09:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 396946B0074; Thu, 6 Apr 2023 04:09:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 251FE6B0075; Thu, 6 Apr 2023 04:09:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 172A56B0071 for ; Thu, 6 Apr 2023 04:09:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C25D58030E for ; Thu, 6 Apr 2023 08:09:08 +0000 (UTC) X-FDA: 80650240776.07.43EE06E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 1E7342001C for ; Thu, 6 Apr 2023 08:09:04 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FhalXvsd; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of cem@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cem@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680768545; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wHAlz0XGE/D48Bblm1soPADn+W11mFwjyQ7WOxZebow=; b=cxG3itptyobLYK/KPqKUPejZ0TeeVRobAxV7IgKiVv9QySiAm4xqj3vZap07/f5VSyA0+T jKSiIhpI/O4SwTmPBDcDpc9kqqxbI8aow5qr/R3ZiYPfhN9JfnIqDLoRFoDP4ZvNMzDWsl fWE8G9VeQ4KaQ5rBcyx5nKJ1W8fPfYg= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FhalXvsd; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of cem@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cem@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680768545; a=rsa-sha256; cv=none; b=4eV4k/Fu56+N9DBTUyA0PHGpFvmrOlVXT3pttIdOoRV2UddVUeyG+iOtCyux6OGjOGaxfX y8AXqtjk9HJQ4zx3EWK0eNTl7mokTmbnLATSEAB7O2Yc+ix8A3t7cvJs82FWTGslhRxHTY DQlq/1nFQUs9QbvLLkRJCL51J8tZW/w= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1859C62BE7; Thu, 6 Apr 2023 08:09:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D39FAC433D2; Thu, 6 Apr 2023 08:09:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680768543; bh=NTeRRWZxlm/R6TvohJy6rQ145WrsAqqZ4FjvkJL6G+U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FhalXvsdwGfhDc7dwUJayBb7g0jbXdw7gU7DYBL3Rb5aMpoTNGulCNLRZvNlDjEOX pLH+kpDsbV+Bdz/zskFBe6h2E7vxibIOXpY4gpWjJdjjc8iiz1M4bKj3eTmoSVN609 p/G61WR7unzESVhgeBSb/kKdOiqvAfNX3KI2NPlvt5UsR6Jil3KQywtQj2SC3tpleR q1Ob6Y57j2xiiOvaqrwP8M+esgCy0tyoNAyBFl98R4JJX16LJqRl8vH+SdH75VZoRu Uza9JelUssg6pFRqtbXXRul37B0d/5WPPK9aZSjbaCtQ3jkSpfRm7BUTmXVBo552ke Md6EFwTEGomzg== Date: Thu, 6 Apr 2023 10:08:58 +0200 From: Carlos Maiolino To: Christian Brauner Cc: hughd@google.com, jack@suse.cz, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH 0/6] shmem: Add user and group quota support for tmpfs Message-ID: <20230406080858.gvnbiscxloxydvhh@andromeda> References: <20230403084759.884681-1-cem@kernel.org> <20230405-klarkommen-zellkern-03af0950b80f@brauner> <20230405104427.rndb5skuubfhucpv@andromeda> <2xIltWe9jbdVUHS6W6lJDWnsQr2jOTDSaSi9y8nXWeb_71v-fLJNaRB-tkdauohZxz1xFAm4bd-471M41qA1eg==@protonmail.internalid> <20230405-hebamme-anonym-d41aa62ffea6@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230405-hebamme-anonym-d41aa62ffea6@brauner> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1E7342001C X-Stat-Signature: abtngrp7sqinjmoey5aekc6wnp9qg3fr X-HE-Tag: 1680768544-338231 X-HE-Meta: U2FsdGVkX19Jzz0p/bZ4b/+4DyUmceuomy1rCcW9iB/sVc9M2JOOTKdzGuRGRu3vYUKUBV225hoTT8a+16/2f08GQ2UHCRRnh23rDU8gSOoutqDFnQOyPTWrHzfTa7K+eUFEgRVqXTFZOmLnxriyxP5e2NIl1KOEKz2KgAvct5K9YstomlrRRNMLOAxty/6SzczFw2ie6539b/VPrG3Y+UNVmfm6RzPJrngwCK06lIt6zy5MTccrl929+7qh2B0Vxpq+9HoV5ucPkqNUNHIxs+1rzgpJ1eGpef+nVuWEPYIT22H9lexoP8amieiyX3p9Q7gQMhN9Dtq5Ge3/VHN+B2Sw10nWPtxUl1sVvoz9JtofAJZrf8bbzphc7arioSzlArJ3Pph/Em8msRdOOQSkEwMKLYCgR8xeXQf1zxQv6PJ9UmqC0NMF43pPaudVuwtzqSjQNYRFsCA6asSitcY15v7Ss+7yHv0fX0sQRenrwXuw0q/gU9/JmlIlOyvmQ0zHI3Dsty1PFP4S5uGrsF/+E7zN98BD/6BFt8u/UunpwbTLDHnvo4OWOo2D7zRw0swji28RZO+amLIbxkoG/CQJNZ/FQOCvMIWzEySRBhye2qxNDOsBWDEqcQxKFPW79vKorAHz9ReQR6UwPvatTWfuIvSw1QOvWbAzYVcdj1qmaIPvlt3WMh48gvOTFL9yh5L0ZdorpT9KKW1jf4ucUGGVlcWDNOsGOiV+XUbMtdgtHixQckRtXDvxfbT/SzrB0R7K5dTwFG++BnDwOvTjd8a/QnBwr105qk57CRb9L7+Bcv+yY4qilp/zVHT9WONGS07jPAiRekiECdTMukR0R+VaGNaB+c9V7dPkJZvUnUmW498nPpeCubFCCwhhlOa2bP8hkDJ+LP9cnkffTddeKFGN8+bHbapXhINsqlcQ1C4RY61YnQbKCNf0e/7/JXhZ11xaigXDwwTn0g4MeYbH5uJ XubgQq4Y pup1X7ZaUrgGDC72Y54no69+DbNY87XYyhl/U/BCbWpxy1DyOzRfxwzGIebCMAWfM7ejrsw8WB0dKQnhENzlrJAeof/8QMDPQnOayUbC+fAB0G9yUMw5Jc07swbIOTI+FYO7gZGJ4P1d7GmhAIvzxB8Q0fRfIehKNABju8B1wpfyZvOwUZY3pPzxLAgCV4gEQD9Rm6PDtNTks/NXNkmehqEYUJvoN+o/IxG03osVy1eMOAVFjXWfidWpNanNYqZIDApdVGBt4nmlUFkrXrj4ktY6S3Ps+KndNuZZ9ECjQHQJLVqepv+Kk8T5ijeMC+MhHuI2Wb/cAIR+Y1bWiqvRyD+/0anzlxCThHaG2VAlRQuHmDSy0OV8T2utpHTjwokEW7MkM 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 Wed, Apr 05, 2023 at 03:11:22PM +0200, Christian Brauner wrote: > On Wed, Apr 05, 2023 at 12:44:27PM +0200, Carlos Maiolino wrote: > > Hi Christian. > > > > On Wed, Apr 05, 2023 at 10:52:44AM +0200, Christian Brauner wrote: > > > On Mon, Apr 03, 2023 at 10:47:53AM +0200, cem@kernel.org wrote: > > > > From: Carlos Maiolino > > > > > > > > Hi folks. this work has been done originally by Lukas, but he left the company, > > > > so I'm taking over his work from where he left it of. This series is virtually > > > > done, and he had updated it with comments from the last version, but, I'm > > > > > > I've commented on the last version: > > > > > > https://lore.kernel.org/linux-fsdevel/20221129112133.rrpoywlwdw45k3qa@wittgenstein > > > > > > trying to point out that tmpfs can be mounted in user namespaces. Which > > > means that the quota uids and gids need to take the idmapping of the > > > user namespace in which the tmpfs instances is mounted in into account; > > > not the one on the host. > > > > > > See the link above for some details. Before we can merge this it would > > > be very good if we could get tests that verify tmpfs being mounted > > > inside a userns with quotas enabled because I don't think this is > > > covered yet by xfstests. Or you punt on it for now and restricted quotas > > > to tmpfs instances mounted on the host. > > > > > > > Thanks for the link, I've read it before, and this is by now a limitation I'd > > like to keep in this series. I can extend it to be namespace aware later on, but > > the current goal of this series is to be able tmpfs mounts on the host to limit > > the amount of memory consumed by users. Being namespace aware is something I > > This is fine with me. But please point the restriction out in the > documentation and in the commit message. This is especially important > because the check is hidden in the bowls of dquot_load_quota_sb(). Sounds reasonable, I'll work on the comments I received and re-send this series next week if nothing urgent comes up. > > Ideally we'd probably check for fc->user_ns == &init_user_ns directly > when parsing the quota mount options instead of waiting until > fill_super. -- Carlos Maiolino