linux-kernel - Re: BUG in __key_instantiate_and_link(): unable to handle kernel paging request at 0000632e6472616f

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]

Date:	Mon, 18 Jun 2012 13:28:49 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Andre Tomt <andre@...t.net>
CC:	"Schumaker, Bryan" <Bryan.Schumaker@...app.com>,
	Linux-NFS <linux-nfs@...r.kernel.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	"David Howells" <dhowells@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: BUG in __key_instantiate_and_link(): unable to handle kernel
 paging request at 0000632e6472616f

On Mon, 2012-06-18 at 11:04 +0200, Andre Tomt wrote:
> On 16. juni 2012 21:59, Myklebust, Trond wrote:
> > It looks to me as if the legacy upcall code is assuming that there can
> > be no more than 1 upcall at a time: there is only a single
> > idmap->idmap_key_cons, which gets assigned in nfs_idmap_legacy_upcall
> > and then read in idmap_pipe_downcall.
> >
> > Bryan, can you look into this? I suspect that we need a mutex or
> > something like that (for the legacy upcall case only) to ensure that
> > nobody overwrites the idmap->idmap_key_cons while an upcall is in
> > progress.
> >
> > Andre, if you want idmapper scalability, then you should rather use the
> > new idmapper upcall. You need a recent version of the nfs-utils package,
> > the keyutils package, and they you should add an 'id_resolver' line
> > to /etc/request-keys.conf as per the nfsidmap manpage.
> 
> Indeed, using keyutils did avoid the crashes here, 40 hours and counting.
> 
> Are there any downsides of having keyutils w/ id_resolver on by default 
> in a distribution? Would it break older kernels or nfs-utils (just not 
> getting used is fine, obviously)?

Older kernels aren't able to use the keyutils mechanism, so they will
still require you to run the idmapd daemon, but there should be no
problems with just enabling it in /etc/request-key.conf.
Fedora 17 is supposed to install the id_resolver by default.

-- 
Trond Myklebust
Linux NFS client maintainer

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