Message ID | 20231027-vfs-autofs-018bbf11ed67@brauner |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp648904vqb; Fri, 27 Oct 2023 07:34:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGenYT1ywr42qtdOZre6Lha70FFL3SubQzL36LaEpmy/LMVBOmCP5SZBPHPp9zu3BXYVVTl X-Received: by 2002:a81:c704:0:b0:5a7:b81a:7f5d with SMTP id m4-20020a81c704000000b005a7b81a7f5dmr2868624ywi.18.1698417256822; Fri, 27 Oct 2023 07:34:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698417256; cv=none; d=google.com; s=arc-20160816; b=nBFcuHFCvoGj+CC/Mcd2iRwJTtB8TrPAhRu2miOtfAEIT4VeDrOlJyXD3yng2VlDKT vsI+g5D7oZGZws/ndASJaj9pskzpbWuX9ZBcBlCRShrs+WJS33GCnyHt8/0h5aeTZRla Pw0oeUBccprcGAH70Aelj4Z2/3Q3bx1NWxwEFmMuLPnlaRLAN9+PvFmvx4r8CPhp9UNm o2rV8tLCVbbTzo2OoaeLCtGSgV7WF7YJDWDE6TtoLxWq7sWnADAGl6aj5UDjHcWqJUu5 qs12SdIyxfWs7rvSoQLp6sH7wib8eTQg74z60aqnioVwZ0IoqLY8A8UrYKYGYj5AZ7EP BypA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ZLGxhkrnzL0O/uDjMMGF1jzBACc76/n8Rosg/Lp54TE=; fh=qDZ+YnS9HJbCVOaeWFr2FnYZt7eE+vt5IJIDIlhBdxU=; b=hclCx+lbfVu4K5rpcvcGav2BgFXPC/D6BMC0FR/yMUR1VIpb8hOg9Soun724M+kQWc NUHNUFnK+ZjWZabxI+HYSKwaulsec2XGQqd7mvR5QmWAteU3gumX4pNe0ali7pTJ67LT qtcCh1iQ6g6o/xHRsMH9eMbf54CnW9nigcBAml+oFjCEq5O6Xym842wKDOB/LPX7FQJB SC5onVhKHv3antpJm2SbYIvloNPYOck2t7jo/TeGYUIJg3TDwVc20tXzbNxyKbDv2er7 5UES6W1jz4eyeli2m+aGHekFqzWtxJFNEtwajpUjUzC7mNd5xRA+89F9NCvovf58/RIC URhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W59Cui+s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id n62-20020a0de441000000b0059f57156507si2721088ywe.104.2023.10.27.07.34.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 07:34:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W59Cui+s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id B6D4A83711AD; Fri, 27 Oct 2023 07:34:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346071AbjJ0Od5 (ORCPT <rfc822;a1648639935@gmail.com> + 25 others); Fri, 27 Oct 2023 10:33:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346069AbjJ0Odw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Oct 2023 10:33:52 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA326C0 for <linux-kernel@vger.kernel.org>; Fri, 27 Oct 2023 07:33:49 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65408C433C8; Fri, 27 Oct 2023 14:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698417229; bh=XtwBVpxwOzBBFzwktednvY+wvC5tqsoHYE/dsTsZi+A=; h=From:To:Cc:Subject:Date:From; b=W59Cui+silA+bkCqaB4LVXiUAULBbO1iAcfW8qlFqqhJGjHiAKo0GwhKzuN6p4M5k NDfN3LhTY3ujwji06lqQo7grfiKJpX2wWjT22ehh9Luvicuf/Smq65Vx7J+3gi61W2 Q7cXHQcDQ3S5MR5vS3QkdFRKQsuiK4PmsBIYIRS6snhyO6diMEMQ0hI43tT3cRYocF I5yFInjExXNrVR4NKFEzpIVL9JRC7JtXEDE1L44mrqfMSHf7uXxud4oltGRqVWek/C Pynkt+EZ0kMq57jhntIVGFOoDG2mPTgZRxt4OYMbjt04cxMX0fq+mmbM/Fk8gPGHIP K0Uo+jLgcwVdA== From: Christian Brauner <brauner@kernel.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Christian Brauner <brauner@kernel.org>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [GIT PULL for v6.7] autofs updates Date: Fri, 27 Oct 2023 16:33:41 +0200 Message-Id: <20231027-vfs-autofs-018bbf11ed67@brauner> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2388; i=brauner@kernel.org; h=from:subject:message-id; bh=XtwBVpxwOzBBFzwktednvY+wvC5tqsoHYE/dsTsZi+A=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMaRan9Lufb7oz+pFD46+TH/VYntfbq/bzBO/bkrVRk+ccuYj z4q/TB2lLAxiXAyyYoosDu0m4XLLeSo2G2VqwMxhZQIZwsDFKQAT0brByPDo+tLomTkn7x/nV55R6c pw3vr8PamvOxs9zt3aunhnhJcTI8PVV4+EDiXoJFZaL45rq36yZ8aEt6vqai54Pv5z7eYja11eAA== X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Fri, 27 Oct 2023 07:34:13 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780919573384402279 X-GMAIL-MSGID: 1780919573384402279 |
Series |
[GIT,PULL,for,v6.7] autofs updates
|
|
Pull-request
git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.7.autofsMessage
Christian Brauner
Oct. 27, 2023, 2:33 p.m. UTC
Hey Linus, /* Summary */ This ports autofs to the new mount api. The patchset has existed for quite a while but never made it upstream. Ian picked it back up. This also fixes a bug where fs_param_is_fd() was passed a garbage param->dirfd but it expected it to be set to the fd that was used to set param->file otherwise result->uint_32 contains nonsense. So make sure it's set. One less filesystem using the old mount api. We're getting there, albeit rather slow. The last remaining major filesystem that hasn't converted is btrfs. Patches exist - I even wrote them - but so far they haven't made it upstream. /* Testing */ clang: Debian clang version 16.0.6 (16) gcc: gcc (Debian 13.2.0-5) 13.2.0 All patches are based on v6.6-rc2 and have been sitting in linux-next. No build failures or warnings were observed. /* Conflicts */ At the time of creating this PR no merge conflicts were reported from linux-next and no merge conflicts showed up doing a test-merge with current mainline. The following changes since commit ce9ecca0238b140b88f43859b211c9fdfd8e5b70: Linux 6.6-rc2 (2023-09-17 14:40:24 -0700) are available in the Git repository at: git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.7.autofs for you to fetch changes up to d3c50061765d4b5616dc97f5804fc18122598a9b: autofs: fix add autofs_parse_fd() (2023-10-24 11:04:45 +0200) Please consider pulling these changes from the signed vfs-6.7.autofs tag. Thanks! Christian ---------------------------------------------------------------- vfs-6.7.autofs ---------------------------------------------------------------- Christian Brauner (1): fsconfig: ensure that dirfd is set to aux Ian Kent (9): autofs: refactor autofs_prepare_pipe() autofs: add autofs_parse_fd() autofs: refactor super block info init autofs: reformat 0pt enum declaration autofs: refactor parse_options() autofs: validate protocol version autofs: convert autofs to use the new mount api autofs: fix protocol sub version setting autofs: fix add autofs_parse_fd() fs/autofs/autofs_i.h | 20 ++- fs/autofs/init.c | 9 +- fs/autofs/inode.c | 435 +++++++++++++++++++++++++++++++-------------------- fs/fsopen.c | 1 + 4 files changed, 283 insertions(+), 182 deletions(-)
Comments
On 27/10/23 22:33, Christian Brauner wrote: > Hey Linus, > > /* Summary */ > This ports autofs to the new mount api. The patchset has existed for > quite a while but never made it upstream. Ian picked it back up. > > This also fixes a bug where fs_param_is_fd() was passed a garbage > param->dirfd but it expected it to be set to the fd that was used to set > param->file otherwise result->uint_32 contains nonsense. So make sure > it's set. > > One less filesystem using the old mount api. We're getting there, albeit > rather slow. The last remaining major filesystem that hasn't converted > is btrfs. Patches exist - I even wrote them - but so far they haven't > made it upstream. Yes, looks like about 39 still to be converted. Just for information, excluding btrfs, what would you like to see as the priority for conversion (in case me or any of my colleagues get a chance to spend a bit more time on it)? Ian
On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote: > On 27/10/23 22:33, Christian Brauner wrote: > > Hey Linus, > > > > /* Summary */ > > This ports autofs to the new mount api. The patchset has existed for > > quite a while but never made it upstream. Ian picked it back up. > > > > This also fixes a bug where fs_param_is_fd() was passed a garbage > > param->dirfd but it expected it to be set to the fd that was used to set > > param->file otherwise result->uint_32 contains nonsense. So make sure > > it's set. > > > > One less filesystem using the old mount api. We're getting there, albeit > > rather slow. The last remaining major filesystem that hasn't converted > > is btrfs. Patches exist - I even wrote them - but so far they haven't > > made it upstream. > > Yes, looks like about 39 still to be converted. > > > Just for information, excluding btrfs, what would you like to see as the > > priority for conversion (in case me or any of my colleagues get a chance > > to spend a bit more time on it)? I think one way to prioritize them is by how likely they are to have (more than a couple) active users. So recently I've done overlayfs because aside from btrfs that was probably one of the really actively used filesystems that hadn't yet been converted. And that did surface some regression So 9p, fat, devpts, f2fs, zonefs, ext2 are pretty obvious targets. Judging from experience, the more mount options a filesystem has the bigger the conversion patch will usually be. Another way is by function. For example, we expose mount_bdev() which is basically the legacy version of get_tree_bdev(). And they sort of are almost copies of each other. So converting all callers to the new mount api means we can get rid of mount_bdev(). But that's like 25 of the remaining 39. But in the end any filesystem that is converted is great.
On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote: > On 27/10/23 22:33, Christian Brauner wrote: > > Hey Linus, > > > > /* Summary */ > > This ports autofs to the new mount api. The patchset has existed for > > quite a while but never made it upstream. Ian picked it back up. > > > > This also fixes a bug where fs_param_is_fd() was passed a garbage > > param->dirfd but it expected it to be set to the fd that was used to set > > param->file otherwise result->uint_32 contains nonsense. So make sure > > it's set. > > > > One less filesystem using the old mount api. We're getting there, albeit > > rather slow. The last remaining major filesystem that hasn't converted > > is btrfs. Patches exist - I even wrote them - but so far they haven't > > made it upstream. > > Yes, looks like about 39 still to be converted. > > > Just for information, excluding btrfs, what would you like to see as the > > priority for conversion (in case me or any of my colleagues get a chance > > to spend a bit more time on it)? I'm just starting to have a look at zonefs as a candidate. -Bill
The pull request you sent on Fri, 27 Oct 2023 16:33:41 +0200:
> git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.7.autofs
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0d63d8b2294b228147bf58def506dde35e57daef
Thank you!
On 30/10/23 18:24, Christian Brauner wrote: > On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote: >> On 27/10/23 22:33, Christian Brauner wrote: >>> Hey Linus, >>> >>> /* Summary */ >>> This ports autofs to the new mount api. The patchset has existed for >>> quite a while but never made it upstream. Ian picked it back up. >>> >>> This also fixes a bug where fs_param_is_fd() was passed a garbage >>> param->dirfd but it expected it to be set to the fd that was used to set >>> param->file otherwise result->uint_32 contains nonsense. So make sure >>> it's set. >>> >>> One less filesystem using the old mount api. We're getting there, albeit >>> rather slow. The last remaining major filesystem that hasn't converted >>> is btrfs. Patches exist - I even wrote them - but so far they haven't >>> made it upstream. >> Yes, looks like about 39 still to be converted. >> >> >> Just for information, excluding btrfs, what would you like to see as the >> >> priority for conversion (in case me or any of my colleagues get a chance >> >> to spend a bit more time on it)? > I think one way to prioritize them is by how likely they are to have > (more than a couple) active users. > > So recently I've done overlayfs because aside from btrfs that was > probably one of the really actively used filesystems that hadn't yet > been converted. And that did surface some regression > > So 9p, fat, devpts, f2fs, zonefs, ext2 are pretty obvious targets. > Judging from experience, the more mount options a filesystem has the > bigger the conversion patch will usually be. > > Another way is by function. For example, we expose mount_bdev() which is > basically the legacy version of get_tree_bdev(). And they sort of are > almost copies of each other. So converting all callers to the new mount > api means we can get rid of mount_bdev(). But that's like 25 of the > remaining 39. > > But in the end any filesystem that is converted is great. Thanks Christian, I know Bill was considering spending a bit of time on this and I may have some cycles myself in the not too distant future. But things change all too quickly so we'll need to see how it goes, ;) Ian I'll
On 30/10/23 22:28, Bill O'Donnell wrote: > On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote: >> On 27/10/23 22:33, Christian Brauner wrote: >>> Hey Linus, >>> >>> /* Summary */ >>> This ports autofs to the new mount api. The patchset has existed for >>> quite a while but never made it upstream. Ian picked it back up. >>> >>> This also fixes a bug where fs_param_is_fd() was passed a garbage >>> param->dirfd but it expected it to be set to the fd that was used to set >>> param->file otherwise result->uint_32 contains nonsense. So make sure >>> it's set. >>> >>> One less filesystem using the old mount api. We're getting there, albeit >>> rather slow. The last remaining major filesystem that hasn't converted >>> is btrfs. Patches exist - I even wrote them - but so far they haven't >>> made it upstream. >> Yes, looks like about 39 still to be converted. >> >> >> Just for information, excluding btrfs, what would you like to see as the >> >> priority for conversion (in case me or any of my colleagues get a chance >> >> to spend a bit more time on it)? > I'm just starting to have a look at zonefs as a candidate. > -Bill > And devpts looks fairly straight forward and is used a lot ... I'll see if I can get time to get that one done, ;) Ian
On 31/10/23 10:12, Ian Kent wrote: > On 30/10/23 22:28, Bill O'Donnell wrote: >> On Sun, Oct 29, 2023 at 03:54:52PM +0800, Ian Kent wrote: >>> On 27/10/23 22:33, Christian Brauner wrote: >>>> Hey Linus, >>>> >>>> /* Summary */ >>>> This ports autofs to the new mount api. The patchset has existed for >>>> quite a while but never made it upstream. Ian picked it back up. >>>> >>>> This also fixes a bug where fs_param_is_fd() was passed a garbage >>>> param->dirfd but it expected it to be set to the fd that was used >>>> to set >>>> param->file otherwise result->uint_32 contains nonsense. So make sure >>>> it's set. >>>> >>>> One less filesystem using the old mount api. We're getting there, >>>> albeit >>>> rather slow. The last remaining major filesystem that hasn't converted >>>> is btrfs. Patches exist - I even wrote them - but so far they haven't >>>> made it upstream. >>> Yes, looks like about 39 still to be converted. >>> >>> >>> Just for information, excluding btrfs, what would you like to see as >>> the >>> >>> priority for conversion (in case me or any of my colleagues get a >>> chance >>> >>> to spend a bit more time on it)? >> I'm just starting to have a look at zonefs as a candidate. >> -Bill >> > And devpts looks fairly straight forward and is used a lot ... I'll > see if Christian, David's original conversion patch for devpts looks like it's still relevant, it also looks fairly small to the point that I'm wondering if it's worth breaking it down into smaller patches. Would you be ok with me just doing a straight patch apply, detailed review and some testing before posting it? David, are you ok with me resurrecting your conversion patch and posting it on your behalf? Ian
Ian Kent <raven@themaw.net> wrote: > David, are you ok with me resurrecting your conversion patch and posting it > on your behalf? Yes, that's fine. David
> Christian, David's original conversion patch for devpts looks like it's > > still relevant, it also looks fairly small to the point that I'm wondering > > if it's worth breaking it down into smaller patches. I vaguely remember that patch and no, for simple fses like devpts breaking this into smaller chunks is probably not worth it. These conversions patches often aren't easy to split nicely anyway. > Would you be ok with me just doing a straight patch apply, detailed review > > and some testing before posting it? Sure.