All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bryan Schumaker <bjschuma@netapp.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Jeff Layton <jlayton@redhat.com>,
	"Schumaker, Bryan" <Bryan.Schumaker@netapp.com>,
	"bfields@fieldses.org" <bfields@fieldses.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 1/3] NFS: Fall back on old idmapper if request_key() fails
Date: Tue, 07 Feb 2012 14:29:37 -0500	[thread overview]
Message-ID: <4F317BA1.4050102@netapp.com> (raw)
In-Reply-To: <1328642485.4124.40.camel@lade.trondhjem.org>

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

> 
> 
> 



  reply	other threads:[~2012-02-07 19:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26 21:54 [PATCH 1/3] NFS: Fall back on old idmapper if request_key() fails bjschuma
2012-01-26 21:54 ` [PATCH 2/3] NFS: Keep idmapper include files in one place bjschuma
2012-02-06 23:05   ` Myklebust, Trond
2012-01-26 21:54 ` [PATCH 3/3] NFS: Update idmapper documentation bjschuma
2012-01-26 21:56 ` [PATCH 1/3] NFS: Fall back on old idmapper if request_key() fails J. Bruce Fields
2012-01-26 21:57   ` Bryan Schumaker
2012-02-06 23:05 ` Myklebust, Trond
2012-02-07 15:54   ` Bryan Schumaker
2012-02-07 19:12 ` Jeff Layton
2012-02-07 19:21   ` Myklebust, Trond
2012-02-07 19:29     ` Bryan Schumaker [this message]
2012-02-07 19:44       ` Myklebust, Trond
2012-02-07 20:05         ` Myklebust, Trond
2012-02-08 12:04           ` Jeff Layton
2012-02-08 13:50             ` Myklebust, Trond
2012-02-08 18:56               ` Myklebust, Trond
2012-02-08 19:30                 ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F317BA1.4050102@netapp.com \
    --to=bjschuma@netapp.com \
    --cc=Bryan.Schumaker@netapp.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.