On Tue, 2012-02-07 at 14:29 -0500, Bryan Schumaker wrote: > 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... One way to easily shrink the size of that allocation is to convert the ih_name string into a pointer, and have the downcall allocate the storage for that string dynamically... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
