On 02/07/12 14:21, Myklebust, Trond wrote: > On Tue, 2012-02-07 at 14:12 -0500, Jeff Layton wrote: >> On a 32-bit box when you try to mount and low memory is heavily >> fragmented, you can get a NULL pointer back on that kzalloc with a >> nice stack trace headed by a message like this: >> >> mount.nfs: page allocation failure. order:4, mode:0xc0d0 >> >> Here's a RHBZ against RHEL6 if you're interested in gory details: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=730045 >> >> In any case, this problem was one of the reasons for pushing the new >> idmapper. A number of people have complained about this problem in the >> past and we told them "use the new idmapper". Now, with this patchset, >> that won't help. > > Wait. How is that true? The whole point of this patchset is that it > allows you to compile in support for _both_ idmappers, with the new > keyring-based idmapper being tried first. The client then falls back to > using the old idmapper if and only if the user has failed to set up the > new idmapper correctly. Because it still allocates the structures, they just go unused if the new idmapper works. This seems kind of wasteful now that I know about it... > >> I think the right solution is to probably look at breaking up the idmap >> structure in the legacy idmapper into multiple allocations. It's more >> complicated to deal with and will mean restructuring the code a bit, >> but it will allow for a relatively graceful transition to the new >> idmapper. > > I'd like to see the old idmapper code changed to use the new > keyring-based cache instead. I've asked Bryan to look into how we can do > this. This will probably be easier than splitting up the allocation. It should be possible to change whatever "actor" function the request_key code takes and then try again. What is the best way to handle the fallback? This patch always tries the new idmapper before falling back on the old one. I could also set it up to try the new idmapper once, change the function pointer if it fails, and never change it back (until NFS is restarted). - Bryan > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
