linux-kernel - Re: kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1344352458.5781.8.camel@lade.trondhjem.org>
Date:	Tue, 7 Aug 2012 15:14:22 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	"Schumaker, Bryan" <Bryan.Schumaker@...app.com>
CC:	Joerg Roedel <joro@...tes.org>,
	Joerg Roedel <joerg.roedel@....com>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"wdauchy@...il.com" <wdauchy@...il.com>
Subject: Re: kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!

On Tue, 2012-08-07 at 10:36 -0400, Bryan Schumaker wrote:
> On 08/07/2012 10:27 AM, Joerg Roedel wrote:
> > On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
> >> On 08/07/2012 10:15 AM, Joerg Roedel wrote:
> >>> Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
> >>> Intel box with an NFSv3 directory mounted at boot. This is the only box
> >>> I have seen this so far, probably it depends on the config. I attach the
> >>> config of the failing box.
> >>
> >> Interesting.  Are you mounting v4, too?  This code shouldn't be
> >> running for v3... maybe that's why I haven't been able to hit it.
> > 
> > No, I am not using NFSv4 on the box where the BUG happens. I have
> > another box mounting the same directory where the BUG does not trigger
> > with v3.6-rc1. A difference I spotted between the kernels is, that on
> > the failing box NFS is compiled as a module whereas it is compiled into
> > the kernel on the box that works fine. Not sure if that has anything to
> > do with the problem...
> > 
> 
> Your stack trace is showing v4 calls on the failing box, those definitely shouldn't be happening if you're using v3.  Can you double check /etc/fstab and /proc/mounts on a working kernel to be sure?
> 
> My VM has nfs as a module, so I don't think that's the issue... I just started compiling your config to test on my own.

Joerg,

The stack trace definitely shows that the NFS client is attempting an
NFSv4 mount. Are you supplying a 'vers=3' mount option? If not, then
note that recent versions of nfs-utils can be configured to try NFSv4 as
the default mount option, so I'd guess this is why you are hitting an
NFSv4 path.

Bryan,

That said, when looking at the legacy upcall, it seems that if
rpc_queue_upcall fails, then we don't do anything to clear
idmap->idmap_key_cons. Ditto if the call times out, or if the pipe is
closed before the downcall.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com