From: Andre Tomt <andre@tomt.net>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "Schumaker, Bryan" <Bryan.Schumaker@netapp.com>,
Linux-NFS <linux-nfs@vger.kernel.org>,
Fengguang Wu <fengguang.wu@intel.com>,
David Howells <dhowells@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: BUG in __key_instantiate_and_link(): unable to handle kernel paging request at 0000632e6472616f
Date: Mon, 18 Jun 2012 11:04:56 +0200 [thread overview]
Message-ID: <4FDEEF38.8030101@tomt.net> (raw)
In-Reply-To: <1339876739.8267.96.camel@lade.trondhjem.org>
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)?
next prev parent reply other threads:[~2012-06-18 9:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120601034114.GA9248@localhost>
2012-06-01 14:34 ` BUG in __key_instantiate_and_link(): unable to handle kernel paging request at 0000632e6472616f Fengguang Wu
2012-06-02 2:25 ` ethan zhao
2012-06-16 2:32 ` Andre Tomt
2012-06-16 18:43 ` Andre Tomt
2012-06-16 19:59 ` Myklebust, Trond
2012-06-18 9:04 ` Andre Tomt [this message]
2012-06-18 13:28 ` Myklebust, Trond
2012-06-18 16:11 ` Bryan Schumaker
2012-06-20 18:27 ` Bryan Schumaker
2012-06-26 7:24 ` Andre Tomt
2012-06-26 12:42 ` Bryan Schumaker
2012-06-18 12:44 ` Bryan Schumaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FDEEF38.8030101@tomt.net \
--to=andre@tomt.net \
--cc=Bryan.Schumaker@netapp.com \
--cc=Trond.Myklebust@netapp.com \
--cc=dhowells@redhat.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).