On Mon, Sep 30, 2013 at 08:49:21PM +0100, Al Viro wrote:
> * btrfs: wants btrfs_root_readonly(BTRFS_I(inode)->root) usable in
> ->permission(). Delayed freeing of struct btrfs_root, perhaps?
Not needed, actually - it's only checked with MAY_WRITE, and we don't
pass that in RCU mode.
Anyway, I've
On Mon, Sep 30, 2013 at 08:49:21PM +0100, Al Viro wrote:
> OK... AFAICS, we are not too far from being able to handle RCU pathwalk
> straying into fs in the middle of being shut down.
> * There are 5 methods that can be called:
> ->d_hash(...)
> ->d_compare(...)
> ->d_revalidate(..., LOOKUP_
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode.
OK... AFAICS, we are not too far from being able to handle RCU pathwalk
straying into fs in the middle of being shut down.
* There are 5 methods t
On Sun, Sep 29, 2013 at 11:26:21AM -0700, Linus Torvalds wrote:
> > If my reading of that code is right, the proper fix would be to
> > turn that else if (inode) into else if (inode && !(flags & LOOKUP_RCU))
>
> That sounds safer, but then the fuse_advise_use_readdirplus() bit
> wouldn't get set.
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
[snip]
and another, this one completely unrelated to RCU:
unsigned long gen = (unsigned l
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
> fuse_dentry_revalidate() we have a case (reachable with LOOKUP_RCU) where
> we do this:
> } else
On Sun, Sep 29, 2013 at 11:10 AM, Al Viro wrote:
>
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
> fuse_dentry_revalidate() we have a case (reachable with LOOKUP_RCU) where
> we do this:
> } else if (i
On Sun, Sep 29, 2013 at 10:19:59AM -0700, Linus Torvalds wrote:
> I have to say, that when I was working with the dcache lockref code, I
> absolutely _detested_ the magical shrink_dcache_for_umount() code that
> violated all the locking rules.
... and duplicated random-half-of-an-arseload of stuff
On Sat, Sep 28, 2013 at 11:06 PM, Al Viro wrote:
>
> Sigh... Looks like there's a lot of fun in shrink_dcache_for_umount() -
> at the very least, it needs to bump ->d_seq on everything, because with
> that change we *can* walk into a filesystem in the middle of that.
> We obviously don't want to
On Sat, Sep 28, 2013 at 01:43:49PM -0700, Linus Torvalds wrote:
> Sounds reasonable to to me.
Sigh... Looks like there's a lot of fun in shrink_dcache_for_umount() -
at the very least, it needs to bump ->d_seq on everything, because with
that change we *can* walk into a filesystem in the middle
On Sat, Sep 28, 2013 at 1:27 PM, Al Viro wrote:
> FWIW, I think I have a kinda-sorta solution for that and I'd like
> to hear your comments on that. I want to replace vfsmount_lock with seqlock
> and store additional seq number in nameidata, set to vfsmount_seq in the
> beginning and rech
11 matches
Mail list logo
