Re: [PATCH] Busy inodes after unmount, be more verbose in generic_shutdown_super

[Neil Brown]

On Monday March 6, bsingharora@xxxxxxxxx wrote:
> > Somewhere in among the comments (thanks), I realised that I was only
> > closing half the race.  I had tried to make sure there were no stray
> > references to any dentries, but there is still the inode which is
> > being iput which can cause problem.
> >
> > The following patch takes a totally different approach, is based on an
> > idea from Jan Kara, and is much less intrusive.
> >
> > We:
> >   - keep track of "who" is calling prune_dcache, and when a filesystem
> >     is being unmounted (s_root == NULL) we only allow the unmount thread
> >     to prune dentries.
> >   - keep track of how many dentries are in the process of having
> >     dentry_iput called on them for pruning
> >   - don't allow umount to proceed until that count hits zero
> >   - bias the count this way and that to make sure we get a wake_up at
> >     the right time
> >   - reuse 's_wait_unfrozen' to wait on the iput to complete.
> >
> > Again, I'm very keen on feedback.  This race is very hard to trigger,
> > so code review is the only real way to evaluate that patch.
> >
> > Thanks,
> > NeilBrown
> >
> 
> The code changes look big, have you looked at
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113817279225962&w=2

No I haven't.  I like it.
 - Holding the semaphore shouldn't be a problem.
 - calling down_read_trylock ought to be fast
 - I *think* the unwanted calls to prune_dcache are always under
   PF_MEMALLOC - they certainly seem to be.

And it is a nice small change.
Have you had any other feedback on this?


> 
> Some top of the head feedback below. Will try and do a detailed review later.
> 

> > +               /* avoid further wakeups */
> > +               sb->s_pending_iputs = 65000;
> 
> This looks a bit ugly, what is 65000?

Just the first big number that came to by head... probably not needed.


NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/