On 4/15/06, Andrew Morton <akpm@xxxxxxxx> wrote:
> "Bharata B Rao" <bharata.rao@xxxxxxxxx> wrote:
> >
> > > OT, I'm a bit curious about this:
> > >
> > > list_del_init(tmp);
> > > spin_lock(&dentry->d_lock);
> > > if (atomic_read(&dentry->d_count)) {
> > > spin_unlock(&dentry->d_lock);
> > > continue;
> > > }
> > >
> > > So we rip the dentry off dcache_unused and just leave it floating about?
> > > Dipankar, do you remember why that change was made, and why it's not a bug?
> >
> > Due to lazy updating of the LRU list, there can be some dentries with non-zero
> > ref counts on LRU list. This is one of the places where such dentries are
> > removed from the LRU list. (Basically such dentries will be both on
> > hash list and LRU
> > list and here they get removed from the LRU list)
>
> OK. But what guarantees that these live-but-detached dentries are
> appropriately destroyed before the unmount completes?
These are live dentries but not really detached, they are still attached to
the hash list. And yes I don't see shrink_dcache_sb holding the umount
because of these dentries. I assume dput of such dentries will happen
from different paths. But I am not sure if we could even end up in this
situation where we have landed up in shrink_dcache_sb from unmount path
and there are still some inuse dentries present. Need some clarification here.
>
> Or... if these dentries will be freed by RCU callbacks potentially after
> the unmount, are we sure that they will always be in a state which will
> permit them to be freed?
When a dentry is queued for RCU freeing, there will be no references to
it from anywhere. It wouldn't be on hash list or on lru list. So I would think
only those dentries which are really freeable are queued for RCU freeing.
I see that shrink_dcache_sb is being called from the remount path
(do_remount_sb).
I couldn't understand why we do this. AFAICS we anyway don't modify the
mountpoint or the mount root during remount. Woudn't it be advantageous to
leave those dentries on LRU ?
Regards,
Bharata.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
