Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/ufs/ufs

On Sep,Tuesday 22 2009, at 9:42 PM, Antti Kantee wrote:

On Tue Sep 22 2009 at 21:04:14 +0200, Manuel Bouyer wrote:
that's not an issue with the reference count. It's an issue with vclean()
calling VOP_RECLAIM() even if the refcount is greater than 1, and
vrelel() calling vclean() even if the refcount is greater than 1,
when the file has been unlink(2)ed. There's a comment about this in
vrelel(), look for variable "recycle".

Ah, ic, probably would've been easier if I read the PR first ;)

So basically someone can vget the vnode (via fhtovp, since it's gone
from the directory namespace) between VOP_INACTIVE and clean.

Your fix doesn't really fix this problem, since depending on timings
the inode might still be recycled after you check it's "valid".

Hmm, ok, so things which might happen:

1: VOP_REMOVE, vnode is locked, vrele is called
2: fhtovp before inode is reclaimed, blocks on vn_lock
1: VOP_INACTIVE releases vnlock, returns signal to recycle vnode
2: gets lock, does check that it's still the same inode
1: reclaims vnode
2: boom

Since vget takes the interlock, a dirty & cheap trick might be to check that the reference count is still one before trying to clean the vnode in vrelel(), otherwise punting and letting the next release-to-0 reclaim it?

Blah, I didn't even want to think about this migrane-inducer now.
Maybe people who have recently worked on vnode reclaiming could instead
be the ones to comment?

Sorry I haven't read this thread until today. I think that it would be good to test my vreclaim patched kernel it might help to resolve your problem. But I don't think it is a solution see above.



Home | Main Index | Thread Index | Old Index