Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1582960pxb; Fri, 18 Feb 2022 10:43:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJzjZIRABt2qTEFUFaxv/Jzr0fnW63KaWV1GwF0rcfXcW5vWRiYTzQX0BzM8xOPRdb6/QZv4 X-Received: by 2002:a17:902:da88:b0:14a:26ae:4e86 with SMTP id j8-20020a170902da8800b0014a26ae4e86mr9059553plx.59.1645209809733; Fri, 18 Feb 2022 10:43:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645209809; cv=none; d=google.com; s=arc-20160816; b=RknThDEp4wE2XCspdkAt81OtH7zVO/4toNWhl6lXF72GjosCx/asNmbUzM/oZJ1eyw ErjXqvSzFoHKQ+COypl6sWBXZZG76ZAGcVmWk40VobZnZHVujNW7LIWLd21YDkSbambS T/Ncq8mSl2+20smkexljCzWWCcfCRL4TNfIRi2+52Rq6Kc/ox1yRrlPlpG8Lw/2eZeXC Vi0VQpp6tgtm1i11vzcEgsGgTvEvRW5+fq+wWW/gj34gQd86Y+OkgbyVPPOZc9/u33Dd T2/tISd1pBIX9M6cOf9cJxC/VZ7zwTO5Qdp66Xp1V9CLOvJrSRfO9nFrZjL5mHHlGZUH IWEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=hrC6lEBYNs6YBYom+Le2Tgu2k1ZORJ7JTEm4DzMzqdY=; b=JH9aptjMBucivBR4liq/7btb1HkZ8BoXvgZW1l9B+PAQ4WQDNc4Dt8GKxl8ehzkOcb 6KYAdsg1AcSrAAQGNQoQEFdnsMOr7I00ju+/BO1nEQ1OCx2Edpx2bKyASz9poZ0en22v ih6ezfozAILqyfE/23t79uSCt7a4gLPygANiWWoO+BLjxWuDSDVwHCy1uI68PO/VRcTB cZqwCB8Z7wYBX/qdSI6s6JIUdvnkIk/Mr6lmRK/I1ifyjh7E6r0nsgw06HHHt9qotHjJ bQnj/o/c74JqLANb5a7WXf/d4eohgVQeesJPCI9le9ZYGCJDfLW6tcKpOgwTLAgWAnw/ HtyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j9si28387636plx.260.2022.02.18.10.43.13; Fri, 18 Feb 2022 10:43:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239275AbiBRSfb (ORCPT + 99 others); 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 Content-Transfer-Encoding: 8bit Sender: riel@shelob.surriel.com X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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) -- 2.34.1