From: Christoph Hellwig <hch@lst.de>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@lst.de>,
viro@zeniv.linux.org.uk, jk@ozlabs.org
Subject: Re: [PATCH] powerpc/spufs: Add rcu_read_lock() around fcheck()
Date: Thu, 7 May 2020 08:54:51 +0200 [thread overview]
Message-ID: <20200507065451.GA6185@lst.de> (raw)
In-Reply-To: <875zdifrgw.fsf@mpe.ellerman.id.au>
On Wed, Apr 29, 2020 at 09:42:39PM +1000, Michael Ellerman wrote:
> Christoph Hellwig <hch@lst.de> writes:
> > On Tue, Apr 28, 2020 at 09:48:11PM +1000, Michael Ellerman wrote:
> >>
> >> This comes from fcheck_files() via fcheck().
> >>
> >> It's pretty clearly documented that fcheck() must be wrapped with
> >> rcu_read_lock(), so fix it.
> >
> > But for this to actually be useful you'd need the rcu read lock until
> > your are done with the file (or got a reference).
>
> Hmm OK. My reasoning was that we were done with the struct file, because
> we return the ctx that's hanging off the inode.
>
> + ctx = SPUFS_I(file_inode(file))->i_ctx;
>
> But I guess the lifetime of the ctx is not guaranteed if the file goes
> away.
>
> It looks like the only long lived reference on the ctx is the one
> taken in spufs_new_file() and dropped in spufs_evict_inode().
>
> So if we take a reference to the ctx with the RCU lock held we should be
> safe, I think. But I've definitely exhausted my spufs/vfs knowledge at
> this point.
>
> Something like below.
Looks reasonable.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christoph Hellwig <hch@lst.de>,
linuxppc-dev@ozlabs.org, jk@ozlabs.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/spufs: Add rcu_read_lock() around fcheck()
Date: Thu, 7 May 2020 08:54:51 +0200 [thread overview]
Message-ID: <20200507065451.GA6185@lst.de> (raw)
In-Reply-To: <875zdifrgw.fsf@mpe.ellerman.id.au>
On Wed, Apr 29, 2020 at 09:42:39PM +1000, Michael Ellerman wrote:
> Christoph Hellwig <hch@lst.de> writes:
> > On Tue, Apr 28, 2020 at 09:48:11PM +1000, Michael Ellerman wrote:
> >>
> >> This comes from fcheck_files() via fcheck().
> >>
> >> It's pretty clearly documented that fcheck() must be wrapped with
> >> rcu_read_lock(), so fix it.
> >
> > But for this to actually be useful you'd need the rcu read lock until
> > your are done with the file (or got a reference).
>
> Hmm OK. My reasoning was that we were done with the struct file, because
> we return the ctx that's hanging off the inode.
>
> + ctx = SPUFS_I(file_inode(file))->i_ctx;
>
> But I guess the lifetime of the ctx is not guaranteed if the file goes
> away.
>
> It looks like the only long lived reference on the ctx is the one
> taken in spufs_new_file() and dropped in spufs_evict_inode().
>
> So if we take a reference to the ctx with the RCU lock held we should be
> safe, I think. But I've definitely exhausted my spufs/vfs knowledge at
> this point.
>
> Something like below.
Looks reasonable.
next prev parent reply other threads:[~2020-05-07 6:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 11:48 [PATCH] powerpc/spufs: Add rcu_read_lock() around fcheck() Michael Ellerman
2020-04-28 11:48 ` Michael Ellerman
2020-04-28 13:52 ` Christoph Hellwig
2020-04-28 13:52 ` Christoph Hellwig
2020-04-29 11:42 ` Michael Ellerman
2020-04-29 11:42 ` Michael Ellerman
2020-05-07 6:54 ` Christoph Hellwig [this message]
2020-05-07 6:54 ` Christoph Hellwig
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=20200507065451.GA6185@lst.de \
--to=hch@lst.de \
--cc=jk@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mpe@ellerman.id.au \
--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.