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 03502C0015E for ; Tue, 15 Aug 2023 03:52:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46DE8900017; Mon, 14 Aug 2023 23:52:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41E7090000B; Mon, 14 Aug 2023 23:52:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 333CE900017; Mon, 14 Aug 2023 23:52:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 251AD90000B for ; Mon, 14 Aug 2023 23:52:11 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DFD9C80CDC for ; Tue, 15 Aug 2023 03:52:10 +0000 (UTC) X-FDA: 81124966020.30.91DA549 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf04.hostedemail.com (Postfix) with ESMTP id EAECE40005 for ; Tue, 15 Aug 2023 03:52:07 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Hqstt6gp; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of hughd@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692071529; 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=P6v5atA1MLk+jjexl38Oyge5Liq245V+Bs/9eMZT5qA=; b=OZQSRuNnBpmupS9G2larPyC35Qa6bmZ2kEGjvkXSJj/Yr0lDjUBcdJnBr1EVWNnjc6nztH QIaqgg23rguJ15uslb6XtWHC5zIkDNyToSL2t5oV0Iuw2yK9S2hzX5zd6MXfZ5uCztFad9 HvM838N30k+rxWExMbDxzdfFmKJgMoo= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Hqstt6gp; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of hughd@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692071529; a=rsa-sha256; cv=none; b=F0q/UiqSUNLw4q74iW2Wnil55hw6CUYgaNv9AYjV78gSQrp8EAY/m2bRgcJSR4c4Yk4Pqz Yl+T2g/GtPNzPTm2XBRWuSVl5puUWMGTaT/7S2nFgM0qEmeK1M+sRLBPNDGqOZpXWrgr0u /fwsCVMUdE73U6oS7HyPun8hWb+vpho= Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-c5ffb6cda23so5111637276.0 for ; Mon, 14 Aug 2023 20:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692071528; x=1692676328; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=P6v5atA1MLk+jjexl38Oyge5Liq245V+Bs/9eMZT5qA=; b=Hqstt6gpw4qMxWppig97Rr6Qlp3T5tHXqrV5+Qy5v3hpqNIb3H8haad6Oh5Lq22ZIY b4PhmWj8GDeD5Z69Avs0HD+85Ab7CfHWdkMpg7iGPsqvy/3hvQOkEEq+bqVYbUXLYExI t/VhAsv5Q4Fs191fnx9/eSaqTiP4t5xMM5KBSpiwDXd9OVyAXdGEN1Uz7DK9tXgSOGJL z/IfltwnTZ5EHMXdvcI/6S5AfKrkPMtaz3MM0NnfrfGADM6h6PxO8XoEqwb5+vFFIyN8 +CKj4mwRMp+CpCQRejAbXaPIgB99Xaw3zdykYucPdtKMA3lFc28QmC35jW+Sgi/hOC7M jkeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692071528; x=1692676328; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P6v5atA1MLk+jjexl38Oyge5Liq245V+Bs/9eMZT5qA=; b=VoL8dZ4CTY/XVfScnvx4b3DNTJrFB/XKnM/nhbzCEmV0XkRu+Um9q2BrnZMyO83nly kYo0OjwehTQGwaEqfRs2h5dA1edcQPkCGiarwz+XEXWsU4AI8UO8ougA5G6cvW5IzJJq 2SyZSqA2litIAo3piic/OYWBaFL0xHOxnrk7V+g8qVecPj6+atgf57xeSDi8fpvL8c1k 6OA3fCJD0Enx15ETcP+73hmL3KgHDfoIqw8vsqSiL1ESUflhT06xtXvM72b032CGHs0/ 4oz/tTWYJ9k6rlbLWX1aESVism/Ga+Ow4IOLKzJpAmKaHhmeypfnKNCf9RsnJkMc2tOh XobQ== X-Gm-Message-State: AOJu0Yzthe27ZQO4Au/3EOvpQDBpNG2AXWz9oNKWArgoLbDFdg3Tw8rr OKDZsah3T4Rf5h5LklFGHIFDXw== X-Google-Smtp-Source: AGHT+IH0F5gScGnhM0E+60bW0tBpWCasf6XoXDM9+Kb+W9jwZ/n+VEOGms7zmDhiut4cXb6Bi2nhRQ== X-Received: by 2002:a81:600b:0:b0:559:f18d:ee94 with SMTP id u11-20020a81600b000000b00559f18dee94mr13057498ywb.10.1692071528050; Mon, 14 Aug 2023 20:52:08 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id n186-20020a8172c3000000b0058605521e6esm3190149ywc.125.2023.08.14.20.52.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Aug 2023 20:52:07 -0700 (PDT) Date: Mon, 14 Aug 2023 20:51:59 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Snaipe cc: hughd@google.com, ovt@google.com, corbet@lwn.net, akpm@linux-foundation.org, brauner@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] shmem: add support for user extended attributes In-Reply-To: <20230814082339.2006418-1-snaipe@arista.com> Message-ID: <986c412c-669a-43fe-d72a-9e81bca8211@google.com> References: <9b8d38f0-fd22-3f98-d070-16baf976ecb5@google.com> <20230814082339.2006418-1-snaipe@arista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: EAECE40005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: wo5j1o868494n1rioprdho95j3hfnan3 X-HE-Tag: 1692071527-164881 X-HE-Meta: U2FsdGVkX18rBKDTQjXYojoSiyWN77qOu1yUFLZoEYRD6HR4iEickgGCKrowDVjzDNjDxvWJs7qexJYwBX/9sBCQAnmkqi/35eq382Rosr2oqYPIsRXM/XqgAqcnnaNBd7yevPnXHc5C6iIr5a8CV8X66myT7TgAJrkiew6++Atmjm1PBl3cczpupsxlNpxVan4Ma+d3I2ThOxUzay3wIZucPttSlZp+jKyHlt237iZpCH0MpK4k+gbqqwBjPJjlMCUkLT6bjll4o7bWJQI635OMTJLGekfYWnbP2iaEYe9BLmRya6K9F82N/kOToys9KKpxSiRXUGexuT40h2tlBWuYbcSa/AA1Q4857yGRYg7PlsqbeyhYH7KM0TsrOEwXQobN7RHX/hYI/WKDARUP2Kc9Zb+ecZpfqA1R7wpHyJD8ocF34m6c9uMegPG0wGd9FML4erFYsgpz+8ENc6CG8hwnWmHwkS4mFSUwIUWyBm137oGiFOk8ZUt8YzxPJ08uUcimlX914SK6YZhTqnFhjgUyvSFeqGjIvwo9oZyoDfyzAOy5+vi6O05a5Pj6AeYJMXK4G89Gl6+XdvdQV7ZrvIQKhNIdXkxnYXTIpmbG7avfE5YxS1QB32B0Zy6iuJ1waYlvy2nY/UxJEqBw/MlwFkXMP+Nv2NfJrMRLdpsOfWMOvEpwxvRlJGkT+fSUROuRKX+ojcYYhNcIUSujZkjVIL/nvqgPm1CtHNYtjMxeQjUMjiEDXJVkzorAAcj8uv4cYIFQ9TMBhx+O/MxvJUwbEspE0l3IL82kJdHoKsYS4BlaSsxQZNny8bMrHAKSCf6pLRtsJZDGWCmzqg88Iejt8/s9DCXhnIRI3FaAH+cVmCU1Y8oaZ33wROMUwzzFbVI/VABE1cgSZmkrDOys5R9UDDoxSHY43GMEwsh1rTQebYD0ts0L4WMZ0aSHxBu7DsJNGjJwOURfH7770yLrOQN FaDqE+AB i+pyNv64wHbFhRrS6LczBn/9F+5bJSLKwgXzvCo0YHkbDxNaFmxW85HT94mDGWjsDMX5C1ipxEZbWcX3ea0KJUkepc1x/K4RKG/Mfk3iKLqzrhDidjWLOEmaU42k3x9vAkZ3xkMLFw4waF4+y+oHVCdRHWFpfdJte5iGyhJXQmcf2tl4KD+tLuR3GHyx+1YKSLdrs9HI7YjKmDCWB/yAHsQKuBitMA4X2xhVbz+opKRuXJRpd1iWL8paHrLU4/4CRjKC4HmM4kQo8f2N5ILoICD5+Vz7CnmgW/GaG8OrfI7+nWqhg4lAISwXvvmujiEwRcslHLrN3tbuKsflUiwWtM8pABvRpSCARW63Rh+qwvjgQZTQ7ZCiQ+YdSfan7iw+Zfj38zbWC9s6y1vUWFtuQVtGFmaakW7VwXgblnpa1JTaZr5KYFETf8DZfrw== 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 Mon, 14 Aug 2023, Snaipe wrote: > > Your sending this patch does help to raise the priority for my > > sending that patch: thank you; but I cannot promise when that will be. > > Hey Hugh, > > Just as an additional data point, if it helps with priority :) > > The lack of support of user xattrs on tmpfs our last remaining blocker for > using unprivileged overlayfs mounts that use a tmpfs for the upper dir & work > dir. Not that it isn't possible to use unprivileged overlayfs mounts in general, > but not having this option means that use-cases for discardable upper layer > changes are harder to clean up correctly when not on an tmpfs mount whose > lifetime is bound to a mount namespace. > > I don't think there's any rush; we can live with rmdir failing with EIO for now, > but it'd be great to see this fixed rather than having to implement expensive > cleanup routines that have to remove the upper+work dirs recursively with > CAP_DAC_OVERRIDE. Thanks for the encouragement. At the time that I wrote that (20 July) I did not expect to get around to it for months. But there happens to have been various VFS-involving works going on in mm/shmem.c recently, targeting v6.6: which caused me to rearrange priorities, and join the party with tmpfs user xattrs, see https://lore.kernel.org/linux-fsdevel/e92a4d33-f97-7c84-95ad-4fed8e84608c@google.com/ Which Christian Brauner quickly put into his vfs.git (vfs.tmpfs branch): so unless something goes horribly wrong, you can expect them in v6.6. There's a lot that you wrote above which I have no understanding of whatsoever (why would user xattrs stop rmdir failing?? it's okay, don't try to educate me, I don't need to know, I'm just glad if they help you). Though your mention of "unprivileged" does make me shiver a little: Christian will understand the implications when I do not, but I wonder if my effort to limit the memory usage of user xattrs to "inode space" can be be undermined by unprivileged mounts with unlimited (or default, that's bad enough) nr_inodes. If so, that won't endanger the tmpfs user xattrs implementation, since the problem would already go beyond those: can an unprivileged mount of tmpfs allow its user to gobble up much more memory than is good for the rest of the system? Hugh