All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
	linux-fsdevel@vger.kernel.org, paulmck@kernel.org,
	gscrivan@redhat.com, Eric Biederman <ebiederm@xmission.com>,
	Chris Mason <clm@fb.com>
Subject: Re: [PATCH 1/2] vfs: free vfsmount through rcu work from kern_unmount
Date: Sat, 19 Feb 2022 05:50:35 +0000	[thread overview]
Message-ID: <YhCFKyVMtOSyBDJh@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <YhAKV5cjXEz2JTBB@zeniv-ca.linux.org.uk>

On Fri, Feb 18, 2022 at 09:06:31PM +0000, Al Viro wrote:

> FWIW, that won't work correctly wrt failure exits.  I'm digging
> through the lifetime rules in there right now, will post when
> I'm done.

OK, now that I'd reconstructed the picture...  The problems with
delayed shutdown are prevented by mq_clear_sbinfo() call in there -
mqueue is capable of more or less gracefully dealing with
having ->s_fs_info ripped from under it, which is what that
thing does.  Before the kern_unmount().  And since that code is
non-modular, we don't need to protect that either.

IOW, having
void put_ipc_ns(struct ipc_namespace *ns)
{
        if (refcount_dec_and_lock(&ns->ns.count, &mq_lock)) {
		mq_clear_sbinfo(ns);
		spin_unlock(&mq_lock);
		free_ipc_ns(ns);
	}
}

and
void mq_put_mnt(struct ipc_namespace *ns)
{
	/*
	 * The only reason it's safe to have the mntput async
	 * is that we'd already ripped the ipc_namespace away
	 * from the mqueue superblock, by having called
	 * mq_clear_sbinfo().
	 *
	 * NOTE: kern_unmount_rcu() IS NOT SAFE TO USE
	 * WITHOUT SERIOUS PRECAUTIONS.
	 *
	 * Anything that is used by filesystem must either
	 * be already taken away (and fs must survive that)
	 * or have its destruction delayed until the superblock
	 * shutdown.
	 *
	 */
        kern_unmount_rcu(ns->mq_mnt);
}

would suffice.  free_ipc_work/free_ipc/mnt_llist can be killed off.

  reply	other threads:[~2022-02-19  5:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 18:31 [PATCH 0/2] fix rate limited ipc_namespace freeing Rik van Riel
2022-02-18 18:31 ` [PATCH 1/2] vfs: free vfsmount through rcu work from kern_unmount Rik van Riel
2022-02-18 19:26   ` Al Viro
2022-02-18 19:33     ` Rik van Riel
2022-02-18 19:43       ` Al Viro
2022-02-18 20:24         ` Al Viro
2022-02-18 21:06           ` Al Viro
2022-02-19  5:50             ` Al Viro [this message]
2022-02-19  5:53   ` Al Viro
2022-02-19  5:58     ` Al Viro
2022-02-19  6:07       ` Al Viro
2022-02-18 18:31 ` [PATCH 2/2] ipc: get rid of free_ipc_work workqueue Rik van Riel

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=YhCFKyVMtOSyBDJh@zeniv-ca.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=clm@fb.com \
    --cc=ebiederm@xmission.com \
    --cc=gscrivan@redhat.com \
    --cc=kernel-team@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=riel@surriel.com \
    /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.