From: Andrew Morton <akpm@linux-foundation.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Christophe Saout <christophe@saout.de>, linux-kernel@vger.kernel.org
Subject: Re: [patch 36/51] revert "mm: vmalloc use mutex for purge"
Date: Fri, 16 Jan 2009 08:13:59 -0800 [thread overview]
Message-ID: <20090116081359.567a4dc9.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090116094312.GD22810@wotan.suse.de>
On Fri, 16 Jan 2009 10:43:12 +0100 Nick Piggin <npiggin@suse.de> wrote:
> On Fri, Jan 16, 2009 at 10:38:56AM +0100, Christophe Saout wrote:
> > Hi Nick,
> >
> > > Weird. It seem to be something to do with Xen (and btrfs? or was it reproduced
> > > without?).
> >
> > I got this bug without btrfs. Seen on both Xen x86_32 and x86_64.
> >
> > Note that I also some a different issue with CONFIG_UNEVICTABLE_LRU.
> > Seems like Xen tears down current->mm early on process termination, so
> > that __get_user_pages in exit_mmap causes nasty messages when the
> > process had any mlocked pages. (in fact, it somehow manages to get into
> > the swapping code and produces a null pointer dereference trying to get
> > a swap token)
>
> There is an oops there, yes. I remember I patch we have, although it was
> specifically for kernel threads rather than this issue. Xen could easily
> have bigger issues if it is exiting the mm before that final get_user_pages.
>
>
>
> > > Anyway, I agree with the revert for the moment, but I'm worried that it might
> > > be hiding another bug... I might add a few might_sleep and in_atomic warnings
> > > around the place to see if it might find the culprit without crashing machines.
> >
> > If you need some testing, please tell me. On a dual-core machine this
> > bug happens within few minutes of a compiler run.
>
> Ok, thanks... I'll see if I can get to it next week.
>
> ---
>
> From: Dean Roe <roe@sgi.com>
> Subject: Prevent NULL pointer deref in grab_swap_token
> References: 159260
>
> grab_swap_token() assumes that the current process has an mm struct,
> which is not true for kernel threads invoking get_user_pages(). Since
> this should be extremely rare, just return from grab_swap_token()
> without doing anything.
>
> Signed-off-by: Dean Roe <roe@sgi.com>
> Acked-by: mason@suse.de
> Acked-by: okir@suse.de
>
>
> mm/thrash.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> --- a/mm/thrash.c
> +++ b/mm/thrash.c
> @@ -31,6 +31,9 @@ void grab_swap_token(void)
> int current_interval;
>
> global_faults++;
> + if (current->mm == NULL)
> + return;
> +
>
> current_interval = global_faults - current->mm->faultstamp;
>
Confused. Why was there a random, seemingly-unrelated patch at the end
of this email?
next prev parent reply other threads:[~2009-01-16 16:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200901152151.n0FLpFvI009218@imap1.linux-foundation.org>
[not found] ` <20090116025531.GI17810@wotan.suse.de>
[not found] ` <1232098736.4808.17.camel@leto.intern.saout.de>
2009-01-16 9:43 ` [patch 36/51] revert "mm: vmalloc use mutex for purge" Nick Piggin
2009-01-16 16:13 ` Andrew Morton [this message]
2009-01-16 16:39 ` Christophe Saout
2009-01-26 13:57 ` KOSAKI Motohiro
2009-01-26 15:07 ` Lee Schermerhorn
2009-01-27 11:27 ` KOSAKI Motohiro
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=20090116081359.567a4dc9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=christophe@saout.de \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
/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