mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: Leon Woestenberg <leon.woestenberg@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: get_user_pages() stores ERR_PTR() in pages[i] on failure
Date: Tue, 4 Aug 2009 13:00:07 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0908041245260.17734@sister.anvils> (raw)
In-Reply-To: <4A780FE6.9050704@inria.fr>

On Tue, 4 Aug 2009, Brice Goglin wrote:
> 
> >> I wonder if we should change get_user_pages to store ERR_PTR(ret)
> >> in page[i] when it fails to get page #i.
> >>     
> > Yes, I would see that as an improvement in finding out why rc <
> > nr_pages, in case rc > 0.
> >
> > Also I think it does not break existing users.
> >   
> 
> Only compile-tested (and not in the nommu case).
> 
> 
> 
> 
> When get_user_pages() fails to get a non-first page, it returns
> the number of successfully gotten pages. The caller has to call
> get_user_pages() again on the failed page to figure out the
> error code.
> 
> Store the error code with ERR_PTR() in pages[i] when we fail
> to get page #i.
> 
> The arch specific get_user_pages_fast() do not need to be changed
> since they revert to the main get_user_pages() on failure.
> 
> Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>

This is a nice idea, and it looks like a good patch to implement
it, and I wish get_user_pages() had done that from the start, but...

... some callers of get_user_pages() might expect it not to touch
entries in the page array beyond the fail point: for example, they
might start off with a zeroed array, then when they come to put_page
on the array afterwards, would skip any NULL entries found - without
having to have noted the returned number of pages.  I don't think
that way of working is supported by any guarantee in documentation,
but it's not unreasonable to expect it to behave in that way.

If there were nothing intree which worked that way, then I'd
say let's go ahead with your nice patch.  But I soon reached
drivers/gpu/drm/ttm/ttm_tt.c then drivers/gpu/drm/via/via_dmablit.c
which both appear to work in that way.  I've not looked beyond them,
but I suspect those two cases amount to a NAK on your patch, sadly.
Of course we _could_ fix individual callers to work with it, but
for me they sound a warning that it's too late to change now.

Hugh

  parent reply	other threads:[~2009-08-04 12:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-03 15:23 get_user_pages() on an mmap()ed file allowed? What to do if 0 < get_user_pages(..., nr_pages, ...) < nr_pages? Leon Woestenberg
2009-08-03 16:30 ` Hugh Dickins
2009-08-04  8:57   ` Leon Woestenberg
2009-08-04  9:50     ` KAMEZAWA Hiroyuki
2009-08-04 10:07       ` Leon Woestenberg
2009-08-04  9:18   ` Brice Goglin
2009-08-04  9:59     ` Leon Woestenberg
2009-08-04 10:39       ` [PATCH] mm: get_user_pages() stores ERR_PTR() in pages[i] on failure Brice Goglin
2009-08-04 11:20         ` Leon Woestenberg
2009-08-04 12:00         ` Hugh Dickins [this message]
2009-08-04 16:25           ` Leon Woestenberg

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=Pine.LNX.4.64.0908041245260.17734@sister.anvils \
    --to=hugh.dickins@tiscali.co.uk \
    --cc=Brice.Goglin@inria.fr \
    --cc=leon.woestenberg@gmail.com \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®