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: <1340026127.2451.7.camel@lade.trondhjem.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ