[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.037 / U:21.908 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site