[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130326173747.GV21522@ZenIV.linux.org.uk>
Date: Tue, 26 Mar 2013 17:37:47 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: Toralf F??rster <toralf.foerster@....de>,
Linux NFS mailing list <linux-nfs@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: kernel 3.8.4 : kernel BUG at fs/locks.c:2093! part #2
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists