On Tue, Mar 26, 2013 at 10:46:40AM -0400, J. Bruce Fields wrote:
> > fs/locks.c:2093 says that we did the final fput of a file that still had
> > posix locks held on it.
> >
> > I can't see how that would happen, but admittedly the nfsd4 code here is
> > much too complicated for its own good.
> >
> > If it were possible it would be useful to know what lead up to this. A
> > network trace (tcpdump -s0 -wtmp.pcap, then send me tmp.pcap) would be
> > useful for that, but I fear it's probably too huge by the time you hit
> > the bug.
> >
> > (The following warning ("rcu_sched self-detected stall") looks like the
> > result of BUGing while holding file_lock_lock. That BUG should probably
> > be downgraded to a WARN_ON_ONCE.)
>
> Can you run with test patches?
>
> This just makes nfsd's fput calls synchronous so that we see in the
> backtrace who called them.
>
> (But assuming it does turn out to be one of these callers, we may then
> need some more printk's in the nfsd code...).
Might also be a good idea to dump the offending struct file_lock, while
we are at it...
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
