mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Johannes Weiner <hannes@saeurebad.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	akpm@linuxfoundation.org, torvalds@linuxfoundation.org,
	npiggin@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: do not overrun page table ranges in gup
Date: Mon, 28 Jul 2008 17:33:46 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0807281721200.3486@nehalem.linux-foundation.org> (raw)
In-Reply-To: <87tze95yrk.fsf@saeurebad.de>



On Tue, 29 Jul 2008, Johannes Weiner wrote:
> 
> Actually, I think the prettier fix would be to just establish that
> garuantee:
>
> --- a/arch/x86/mm/gup.c
> +++ b/arch/x86/mm/gup.c
> @@ -223,7 +223,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>  			struct page **pages)
>  {
>  	struct mm_struct *mm = current->mm;
> -	unsigned long end = start + (nr_pages << PAGE_SHIFT);
> +	unsigned long end = PAGE_ALIGN(start + (nr_pages << PAGE_SHIFT));

Umm. 'end' is guaranteed to be page-aligned if 'start' is. 

So if this makes a difference, that implies that _start_ isn't 
page-aligned, and then you when you add PAGE_SIZE to 'addr', you are going 
to miss 'end' again.

So no, the right fix would be to align 'start' first, which means that 
everything else (including 'end') will be page-aligned. Aligning just one 
or the other is very very wrong.

But yeah, this looks like a nasty bug. It's also sad that the code 
that _should_ be architecture-independent, isn't - because every 
architecture defines the _whole_ "get_user_pages_fast()", even though part 
of it is very much arch-independent (the whole alignment/access_ok part).

It also shows a bug in that whole "access_ok()" check. The fact is, that 
thing is broken too - for the same reason. If you want to get a single 
page at the end of the address space, but don't use an aligned address, 
the "access_ok()" will fail.

Nick, how do you want to fix this? I was just about to cut an -rc1, but I 
would really like to see this one not make it into it..

		Linus

  reply	other threads:[~2008-07-29  0:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-28 18:49 2.6.26-$sha1: RIP gup_pte_range+0x54/0x120 Alexey Dobriyan
2008-07-28 18:53 ` Alexey Dobriyan
2008-07-29  0:00   ` [PATCH] x86: do not overrun page table ranges in gup Johannes Weiner
2008-07-29  0:18     ` Johannes Weiner
2008-07-29  0:33       ` Linus Torvalds [this message]
2008-07-29  0:39         ` Linus Torvalds
2008-07-29  0:51           ` Alexey Dobriyan
2008-07-29  1:25           ` Hugh Dickins
2008-07-29  1:37           ` Nick Piggin
2008-07-29  0:53         ` Johannes Weiner
2008-07-29  1:39         ` Nick Piggin
2008-07-29  0:26     ` Alexey Dobriyan

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=alpine.LFD.1.10.0807281721200.3486@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linuxfoundation.org \
    --cc=hannes@saeurebad.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=torvalds@linuxfoundation.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®