Messages in this thread | | | Date | Mon, 18 Jun 2012 11:04:56 +0200 | From | Andre Tomt <> | Subject | Re: 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)?
| |