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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80341664FB79C2419999599F48F7384102273279C3@HKMAIL01.nvidia.com>
Date:	Thu, 17 Apr 2014 14:48:29 +0800
From:	Peter Chiang <pchiang@...dia.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	"ccross@...roid.com" <ccross@...roid.com>,
	"lizefan@...wei.com" <lizefan@...wei.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"tj@...nel.org" <tj@...nel.org>, "pavel@....cz" <pavel@....cz>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"guillaume@...infr.org" <guillaume@...infr.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mm : Avoid candidate task is equal to current task

You are right !!  It is not a right solution .

It is a speculation where the panic was.

[38261.652100] Call trace: 
[38261.654616] [<ffffffc000aa6fe0>] mm_update_next_owner+0x190/0x238 
[38261.660766] [<ffffffc000aa728c>] do_exit+0x204/0x924 
[38261.665790] [<ffffffc000aa7a1c>] do_group_exit+0x40/0xcc 
[38261.671169] [<ffffffc000ab59cc>] get_signal_to_deliver+0x218/0x57c 
[38261.677409] [<ffffffc000a87e6c>] do_signal+0x534/0x550 
[38261.682608] [<ffffffc000a88070>] do_notify_resume+0x20/0x58

-----Original Message-----
From: Oleg Nesterov [mailto:oleg@...hat.com] 
Sent: Wednesday, April 16, 2014 9:58 PM
To: Peter Chiang
Cc: ccross@...roid.com; lizefan@...wei.com; akpm@...ux-foundation.org; tj@...nel.org; pavel@....cz; ebiederm@...ssion.com; guillaume@...infr.org; linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm : Avoid candidate task is equal to current task

On 04/16, Peter Chiang wrote:
>
> mm_update_next_owner() call from exit_mm() , and exit_mm()  change 
> tsk->mm to NULL If p==c , It seems to be  impossible that mm == c->mm  (tsk->mm) .
> Because mm is non-NULL and  c->mm is NULL .

Confused, please see below.

> Fix kernel panic when finding a new owner for the mm and the new owner 
> is equal to current onwer

Did you actually observe the panic ?

> diff --git a/kernel/exit.c b/kernel/exit.c index 6ed6a1d..aa98422 
> 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -399,7 +399,7 @@ retry:
>  	 * here often
>  	 */
>  	do_each_thread(g, c) {
> -		if (c->mm == mm)
> +		if ((c != p) && (c->mm == mm))
>  			goto assign_new_owner;
>  	} while_each_thread(g, c);

p == current. This is always called with p->mm == NULL and mm != NULL.

So, if c->mm == mm then at least c->mm != NULL, and this means that c == p is not possible?

And it seems that this is exactly what you meant above. So why do you think we need this change?

Oleg.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ