From patchwork Fri Feb 18 18:31:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rik van Riel X-Patchwork-Id: 12751755 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D346AC433F5 for ; Fri, 18 Feb 2022 18:35:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239270AbiBRSfb (ORCPT ); Fri, 18 Feb 2022 13:35:31 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:33414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237385AbiBRSfb (ORCPT ); Fri, 18 Feb 2022 13:35:31 -0500 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 198E3251E75; Fri, 18 Feb 2022 10:35:14 -0800 (PST) Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nL82Z-0004OI-C5; Fri, 18 Feb 2022 13:31:35 -0500 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: kernel-team@fb.com, linux-fsdevel@vger.kernel.org, paulmck@kernel.org, gscrivan@redhat.com, viro@zeniv.linux.org.uk, Rik van Riel , Eric Biederman , Chris Mason Subject: [PATCH 1/2] vfs: free vfsmount through rcu work from kern_unmount Date: Fri, 18 Feb 2022 13:31:13 -0500 Message-Id: <20220218183114.2867528-2-riel@surriel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220218183114.2867528-1-riel@surriel.com> References: <20220218183114.2867528-1-riel@surriel.com> MIME-Version: 1.0 Sender: riel@shelob.surriel.com Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org After kern_unmount returns, callers can no longer access the vfsmount structure. However, the vfsmount structure does need to be kept around until the end of the RCU grace period, to make sure other accesses have all gone away too. This can be accomplished by either gating each kern_unmount on synchronize_rcu (the comment in the code says it all), or by deferring the freeing until the next grace period, where it needs to be handled in a workqueue due to the locking in mntput_no_expire(). Suggested-by: Eric Biederman Reported-by: Chris Mason --- fs/namespace.c | 11 +++++++++-- include/linux/mount.h | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 40b994a29e90..9f62cf6c69de 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -4384,13 +4384,20 @@ struct vfsmount *kern_mount(struct file_system_type *type) } EXPORT_SYMBOL_GPL(kern_mount); +static void mntput_rcu_work(struct work_struct *work) +{ + struct vfsmount *mnt = container_of(to_rcu_work(work), + struct vfsmount, free_rwork); + mntput(mnt); +} + void kern_unmount(struct vfsmount *mnt) { /* release long term mount so mount point can be released */ if (!IS_ERR_OR_NULL(mnt)) { real_mount(mnt)->mnt_ns = NULL; - synchronize_rcu(); /* yecchhh... */ - mntput(mnt); + INIT_RCU_WORK(&mnt->free_rwork, mntput_rcu_work); + queue_rcu_work(system_wq, &mnt->free_rwork); } } EXPORT_SYMBOL(kern_unmount); diff --git a/include/linux/mount.h b/include/linux/mount.h index 7f18a7555dff..cd007cb70d57 100644 --- a/include/linux/mount.h +++ b/include/linux/mount.h @@ -16,6 +16,7 @@ #include #include #include +#include struct super_block; struct vfsmount; @@ -73,6 +74,7 @@ struct vfsmount { struct super_block *mnt_sb; /* pointer to superblock */ int mnt_flags; struct user_namespace *mnt_userns; + struct rcu_work free_rwork; } __randomize_layout; static inline struct user_namespace *mnt_user_ns(const struct vfsmount *mnt)