All of lore.kernel.org
 help / color / mirror / Atom feed
From: Salman Qazi <sqazi@google.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Biederman <ebiederm@xmission.com>,
	Eric Dumazet <edumazet@google.com>,
	linux-fsdevel@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs, ipc: Use an asynchronous version of kern_unmount in IPC
Date: Wed, 13 Feb 2019 13:07:58 -0800	[thread overview]
Message-ID: <CAKUOC8U8=2oG0vGgjgY6uR3ezw62kR2TsKH1d2mey9j265tFFg@mail.gmail.com> (raw)
In-Reply-To: <CAKUOC8Xvda0KPkck3Tunksm8gg2aCi8Zf1EWb7VVa_y9rv6j3g@mail.gmail.com>

Do you have any additional concerns?

On Thu, Feb 7, 2019 at 10:43 AM Salman Qazi <sqazi@google.com> wrote:
>
> On Wed, Feb 6, 2019 at 8:14 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Wed, Feb 06, 2019 at 11:53:54AM -0800, Salman Qazi wrote:
> >
> > > This patch solves the issue by removing synchronize_rcu from mq_put_mnt.
> > > This is done by implementing an asynchronous version of kern_unmount.
> > >
> > > Since mntput() sleeps, it needs to be deferred to a work queue.
> > >
> > > Additionally, the callers of mq_put_mnt appear to be safe having
> > > it behave asynchronously.  In particular, put_ipc_ns calls
> > > mq_clear_sbinfo which renders the inode inaccessible for the purposes of
> > > mqueue_create by making s_fs_info NULL.  This appears
> > > to be the thing that prevents access while free_ipc_ns is taking place.
> > > So, the unmount should be able to proceed lazily.
> >
> > Ugh...  I really doubt that it's correct.  The caller is
> >                 mq_put_mnt(ns);
> >                 free_ipc_ns(ns);
> > and we have
> > static void mqueue_evict_inode(struct inode *inode)
> > {
> >
> > ...
> >
> >         ipc_ns = get_ns_from_inode(inode);
> >
> > with
> >
> > static struct ipc_namespace *get_ns_from_inode(struct inode *inode)
> > {
> >         struct ipc_namespace *ns;
> >
> >         spin_lock(&mq_lock);
> >         ns = __get_ns_from_inode(inode);
> >         spin_unlock(&mq_lock);
> >         return ns;
> > }
> >
> > and
> >
> > static inline struct ipc_namespace *__get_ns_from_inode(struct inode *inode)
> > {
> >         return get_ipc_ns(inode->i_sb->s_fs_info);
> > }
> >
> > with ->s_fs_info being the ipc_namespace we are freeing after mq_put_ns()
> >
> > Are you saying that get_ipc_ns() after free_ipc_ns() is safe?  Because
> > ->evict_inode() *IS* called on umount.  What happens to your patch if
> > there was a regular file left on that filesystem?
> >
> > Smells like a memory corruptor...
>
> Actually, the full context in the caller is
>
>         if (refcount_dec_and_lock(&ns->count, &mq_lock)) {
>                 mq_clear_sbinfo(ns);
>                 spin_unlock(&mq_lock);
>                 mq_put_mnt(ns);
>                 free_ipc_ns(ns);
>         }
>
> And
>
> void mq_clear_sbinfo(struct ipc_namespace *ns)
> {
>         ns->mq_mnt->mnt_sb->s_fs_info = NULL;
> }
>
> Therefore, s_fs_info should be NULL before we proceed to unmount.  So,
> as far as I know, it should not be possible to find the ipc_namespace
> from the mount.

  reply	other threads:[~2019-02-13 21:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06 19:53 [PATCH] fs, ipc: Use an asynchronous version of kern_unmount in IPC Salman Qazi
2019-02-06 20:13 ` Eric Dumazet
2019-02-07  4:14 ` Al Viro
2019-02-07 18:43   ` Salman Qazi
2019-02-13 21:07     ` Salman Qazi [this message]
2019-03-04 19:48     ` [PATCH RESENT] " Salman Qazi

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='CAKUOC8U8=2oG0vGgjgY6uR3ezw62kR2TsKH1d2mey9j265tFFg@mail.gmail.com' \
    --to=sqazi@google.com \
    --cc=ebiederm@xmission.com \
    --cc=edumazet@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.