linux-kernel - Re: [patch 36/51] revert "mm: vmalloc use mutex for purge"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090127163443.1BEC.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date:	Mon, 26 Jan 2009 22:57:22 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Christophe Saout <christophe@...ut.de>
Cc:	kosaki.motohiro@...fujitsu.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org,
	Lee Schermerhorn <Lee.Schermerhorn@...com>
Subject: Re: [patch 36/51] revert "mm: vmalloc use mutex for purge"

(cc to Lee Schermerhorn)

sorry for late reply.
I returned from lca yesterday.

> > > From: Dean Roe <roe@....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@....com>
> > > Acked-by: mason@...e.de
> > > Acked-by: okir@...e.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?
> 
> This is a patch I also saw while trying to understand the problem with
> Xen and UNEVICTABLE_LRU.  This patch is actually in the SuSE kernel and
> claims to have something to do with kernel threads.
> 
> However for Xen, the problem is not a kernel threads, it's a regular
> process thread (reiserfsck in to be specific, which mlockall's itself
> into memory) and using this patch makes the null pointer deref Oops go
> away, but still leaves scary messages in the log (a bunch of WARN_ON's).

hm, I guess you test both UNEVICTABLE_LRU on/off and this problem 
happend only if CONFIG_UNEVICTABLE_LRU=y, right?

if so, I really wonder this result.
above mean the page have both following two condition.

 - vma of the page have VM_LOCKED flag.
 - pte of the page is NOT present

I can't imazine how to reproduce it.
Could you please tell me how to reproduce? (sorry, I don't know xen at all)

and, Can you post your bunch of WARN_ON list and .config?



> I fail to understand why __get_user_pages of mlock'ed pages wants to go
> into swap code, but then I'm not an expert in Linux mm.  Maybe this
> happens because current->mm is already down and some code gets confused.
> While googling around I found a comment that during mm teardown, the
> kernel shall better not try to access user pages, I can't remember what
> exactly it was about.





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/