Alexander Viro writes:
>
> On Wed, 14 Jun 2000, Richard Gooch wrote:
Sigh. It's taken me far to long to get back to this.
> > > Not only that, actually - order of invalidation was incorrect, IIRC.
> >
> > Let me check I understand what you mean. You're concerned about the
> > way I *invalidate*, rather than the way I *revalidate*?
>
> Watch for interaction between
> * your invalidation code
> * VFS revalidation stuff
> * your ->revalidate()
>
> > So, basically, the order in which I unregister devices and invalidate
> > dentries is where you see a problem?
>
> _one_ of the problems.
I've been looking at this, and while things aren't as elegant as I'd
like, there doesn't appear to be anything harmful that could happen.
I've come up with some situations. Note that I'm assuming the Big
Kernel Lock is not present (since it's on death row).
Case 1:
Process A does unlink(2)
A gets dir->i_sem
A kills dentry
Process B tries lookup()
B waits for dir->i_sem
A drops dentry
A yields dir->i_sem
B grabs dir->i_sem
A frees old (orphaned) dentry
B goes forth in peace
No problem.
Case 2:
A does lookup()
A gets dir->i_sem
A wakes devfsd
A hashes -ve dentry and unlocks dir->i_sem
A blocks in devfs_d_revalidate_wait()
B tries unlink(2)
B is blocked in devfs_d_revalidate_wait()
devfsd does it's thing, makes inode for dentry
devfsd wakes A and B
B grabs dir->i_sem
A blocks on dir->i_sem
B unregisters device entry
B drops dentry
B yields dir->i_sem
A grabs dir->i_sem
A finds dentry still has inode, so it returns from devfs_lookup()
A does whatever it wanted to do, then returns to user-space
A frees (orphaned) dentry
No problem.
Now, I would prefer it if real_lookup() made a call to
result->d_op->d_revalidate() for the case where it calls the lookup()
method. It would allow me to clean up the devfs code a bit. It would
also look more consistent.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
