[lkml]   [2012]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BUG in __key_instantiate_and_link(): unable to handle kernel paging request at 0000632e6472616f
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)?

 \ /
  Last update: 2012-06-18 11:42    [W:0.039 / U:15.920 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site