Re: [PATCH] SGI 882960: Busy inodes after unmount, oops

[Greg Banks <gnb@melbourne.sgi.com>]

raven@themaw.net wrote:
> 
> This message has occasionally been seen for a very log time when using
> autofs but I've never seen an oops follow it???

Good luck, I guess.  The oopses aren't deterministic, but on an Altix I
get them seconds to minutes after one of every few dozen umounts which
give the message.

The failure mode is that the NFS inode of the parent dir of the silly
renamed file remains used (i_count=1 for the leaked dentry) but i_sb points
to freed memory.  This memory gets reused and overwritten with what appears
to be ASCII strings.  Later, prune_dcache comes along and tries to get rid
of the inode, and iput dies while trying to call inode->i_sb->s_op->put_inode.
I've seen three different stack traces in oopses, all going through
prune_dcache.

> About the only thing that I'm sure of is that this happens at umount time
> in autofs, and with my latest code, only when there is a accompanying
> directory removal.

There may well be another similar bug as well.

> This is very hard to trigger so testing is difficult.

You could try turning the autofs expiry timer down to <5 sec and doing
lots of automount/create/delete/umount cycles.  FWIW, it may be relevant
that for my tests the NFS server was a lot slower than the client and
was only connected by 100BaseT.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs