From: Giuseppe Scrivano <gscrivan@redhat.com>
To: Rik van Riel <riel@surriel.com>
Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
kernel-team@meta.com, linux-fsdevel@vger.kernel.org,
Chris Mason <clm@meta.com>
Subject: Re: [PATCH 2/2] ipc,namespace: batch free ipc_namespace structures
Date: Fri, 27 Jan 2023 12:03:10 +0100 [thread overview]
Message-ID: <878rhome8h.fsf@redhat.com> (raw)
In-Reply-To: <20230127011535.1265297-3-riel@surriel.com> (Rik van Riel's message of "Thu, 26 Jan 2023 20:15:35 -0500")
Rik van Riel <riel@surriel.com> writes:
> Instead of waiting for an RCU grace period between each ipc_namespace
> structure that is being freed, wait an RCU grace period for every batch
> of ipc_namespace structures.
>
> Thanks to Al Viro for the suggestion of the helper function.
>
> This speeds up the run time of the test case that allocates ipc_namespaces
> in a loop from 6 minutes, to a little over 1 second:
>
> real 0m1.192s
> user 0m0.038s
> sys 0m1.152s
>
> Signed-off-by: Rik van Riel <riel@surriel.com>
> Reported-by: Chris Mason <clm@meta.com>
> Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> fs/namespace.c | 10 ++++++++++
> include/linux/mount.h | 1 +
> ipc/namespace.c | 13 ++++++++++---
> 3 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index ab467ee58341..296432ba3716 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1397,6 +1397,16 @@ struct vfsmount *mntget(struct vfsmount *mnt)
> }
> EXPORT_SYMBOL(mntget);
>
> +/*
> + * Make a mount point inaccessible to new lookups.
> + * Because there may still be current users, the caller MUST WAIT
> + * for an RCU grace period before destroying the mount point.
> + */
> +void mnt_make_shortterm(struct vfsmount *mnt)
> +{
> + real_mount(mnt)->mnt_ns = NULL;
> +}
> +
> /**
> * path_is_mountpoint() - Check if path is a mount in the current namespace.
> * @path: path to check
> diff --git a/include/linux/mount.h b/include/linux/mount.h
> index 62475996fac6..ec55a031aa8c 100644
> --- a/include/linux/mount.h
> +++ b/include/linux/mount.h
> @@ -88,6 +88,7 @@ extern void mnt_drop_write(struct vfsmount *mnt);
> extern void mnt_drop_write_file(struct file *file);
> extern void mntput(struct vfsmount *mnt);
> extern struct vfsmount *mntget(struct vfsmount *mnt);
> +extern void mnt_make_shortterm(struct vfsmount *mnt);
> extern struct vfsmount *mnt_clone_internal(const struct path *path);
> extern bool __mnt_is_readonly(struct vfsmount *mnt);
> extern bool mnt_may_suid(struct vfsmount *mnt);
> diff --git a/ipc/namespace.c b/ipc/namespace.c
> index a26860a41dac..6ecc30effd3e 100644
> --- a/ipc/namespace.c
> +++ b/ipc/namespace.c
> @@ -145,10 +145,11 @@ void free_ipcs(struct ipc_namespace *ns, struct ipc_ids *ids,
>
> static void free_ipc_ns(struct ipc_namespace *ns)
> {
> - /* mq_put_mnt() waits for a grace period as kern_unmount()
> - * uses synchronize_rcu().
> + /*
> + * Caller needs to wait for an RCU grace period to have passed
> + * after making the mount point inaccessible to new accesses.
> */
> - mq_put_mnt(ns);
mq_put_mnt() is not needed anymore, should it be removed?
> + mntput(ns->mq_mnt);
> sem_exit_ns(ns);
> msg_exit_ns(ns);
> shm_exit_ns(ns);
> @@ -168,6 +169,12 @@ static void free_ipc(struct work_struct *unused)
> struct llist_node *node = llist_del_all(&free_ipc_list);
> struct ipc_namespace *n, *t;
>
> + llist_for_each_entry_safe(n, t, node, mnt_llist)
> + mnt_make_shortterm(n->mq_mnt);
> +
> + /* Wait for any last users to have gone away. */
> + synchronize_rcu();
> +
> llist_for_each_entry_safe(n, t, node, mnt_llist)
> free_ipc_ns(n);
> }
next prev parent reply other threads:[~2023-01-27 11:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 1:15 [PATCH v2 0/2] ipc,namespace: fix free vs allocation race Rik van Riel
2023-01-27 1:15 ` [PATCH 1/2] ipc,namespace: make ipc namespace allocation wait for pending free Rik van Riel
2023-01-27 1:15 ` [PATCH 2/2] ipc,namespace: batch free ipc_namespace structures Rik van Riel
2023-01-27 1:31 ` [PATCH v2 " Rik van Riel
2023-01-27 11:03 ` Giuseppe Scrivano [this message]
2023-01-27 18:16 ` [PATCH " Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2023-01-27 18:46 [PATCH v3 0/2] ipc,namespace: fix free vs allocation race Rik van Riel
2023-01-27 18:46 ` [PATCH 2/2] ipc,namespace: batch free ipc_namespace structures Rik van Riel
2023-01-26 20:57 [PATCH 0/2] ipc,namespace: fix free vs allocation race Rik van Riel
2023-01-26 20:57 ` [PATCH 2/2] ipc,namespace: batch free ipc_namespace structures Rik van Riel
2023-01-26 21:14 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rhome8h.fsf@redhat.com \
--to=gscrivan@redhat.com \
--cc=clm@meta.com \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@surriel.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.