From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kosaki.motohiro@gmail.com
Subject: Re: [RFC][PATCH] fix move/migrate_pages() race on task struct
Date: Fri, 24 Feb 2012 12:07:03 -0500 [thread overview]
Message-ID: <4F47C3B7.20109@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1202240859340.2621@router.home>
(2/24/12 10:20 AM), Christoph Lameter wrote:
> On Thu, 23 Feb 2012, Eric W. Biederman wrote:
>
>>> The bug in migrate_pages() is that we do a rcu_unlock and a rcu_lock. If
>>> we drop those then we should be safe if the use of a task pointer within a
>>> rcu section is safe without taking a refcount.
>>
>> Yes the user of a task_struct pointer found via a userspace pid is valid
>> for the life of an rcu critical section, and the bug is indeed that we
>> drop the rcu_lock and somehow expect the task to remain valid.
>>
>> The guarantee comes from release_task. In release_task we call
>> __exit_signal which calls __unhash_process, and then we call
>> delayed_put_task to guarantee that the task lives until the end of the
>> rcu interval.
>
> Ah. Ok. Great.
>
>> In migrate_pages we have a lot of task accesses outside of the rcu
>> critical section, and without a reference count on task.
>
> Yes but that is only of interesting for setup and verification of
> permissions. What matters during migration is that the mm_struct does not
> go away and we take a refcount on that one.
>
>> I tell you the truth trying to figure out what that code needs to be
>> correct if task != current makes my head hurt.
>
> Hmm...
>
>> I think we need to grab a reference on task_struct, to stop the task
>> from going away, and in addition we need to hold task_lock. To keep
>> task->mm from changing (see exec_mmap). But we can't do that and sleep
>> so I think the entire function needs to be rewritten, and the need for
>> task deep in the migrate_pages path needs to be removed as even with the
>> reference count held we can race with someone calling exec.
>
> We dont need the task during migration. We only need the mm. The task
> is safe until rcu_read_unlock therefore maybe the following should fix
> migrate pages:
>
>
> Subject: migration: Do not do rcu_read_unlock until the last time we need the task_struct pointer
>
> Migration functions perform the rcu_read_unlock too early. As a result the
> task pointed to may change. Bugs were introduced when adding security checks
> because rcu_unlock/lock sequences were inserted. Plus the security checks
> and do_move_pages used the task_struct pointer after rcu_unlock.
>
> Fix those issues by removing the unlock/lock sequences and moving the
> rcu_read_unlock after the last use of the task struct pointer.
>
> Signed-off-by: Christoph Lameter<cl@linux.com>
>
>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kosaki.motohiro@gmail.com
Subject: Re: [RFC][PATCH] fix move/migrate_pages() race on task struct
Date: Fri, 24 Feb 2012 12:07:03 -0500 [thread overview]
Message-ID: <4F47C3B7.20109@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1202240859340.2621@router.home>
(2/24/12 10:20 AM), Christoph Lameter wrote:
> On Thu, 23 Feb 2012, Eric W. Biederman wrote:
>
>>> The bug in migrate_pages() is that we do a rcu_unlock and a rcu_lock. If
>>> we drop those then we should be safe if the use of a task pointer within a
>>> rcu section is safe without taking a refcount.
>>
>> Yes the user of a task_struct pointer found via a userspace pid is valid
>> for the life of an rcu critical section, and the bug is indeed that we
>> drop the rcu_lock and somehow expect the task to remain valid.
>>
>> The guarantee comes from release_task. In release_task we call
>> __exit_signal which calls __unhash_process, and then we call
>> delayed_put_task to guarantee that the task lives until the end of the
>> rcu interval.
>
> Ah. Ok. Great.
>
>> In migrate_pages we have a lot of task accesses outside of the rcu
>> critical section, and without a reference count on task.
>
> Yes but that is only of interesting for setup and verification of
> permissions. What matters during migration is that the mm_struct does not
> go away and we take a refcount on that one.
>
>> I tell you the truth trying to figure out what that code needs to be
>> correct if task != current makes my head hurt.
>
> Hmm...
>
>> I think we need to grab a reference on task_struct, to stop the task
>> from going away, and in addition we need to hold task_lock. To keep
>> task->mm from changing (see exec_mmap). But we can't do that and sleep
>> so I think the entire function needs to be rewritten, and the need for
>> task deep in the migrate_pages path needs to be removed as even with the
>> reference count held we can race with someone calling exec.
>
> We dont need the task during migration. We only need the mm. The task
> is safe until rcu_read_unlock therefore maybe the following should fix
> migrate pages:
>
>
> Subject: migration: Do not do rcu_read_unlock until the last time we need the task_struct pointer
>
> Migration functions perform the rcu_read_unlock too early. As a result the
> task pointed to may change. Bugs were introduced when adding security checks
> because rcu_unlock/lock sequences were inserted. Plus the security checks
> and do_move_pages used the task_struct pointer after rcu_unlock.
>
> Fix those issues by removing the unlock/lock sequences and moving the
> rcu_read_unlock after the last use of the task struct pointer.
>
> Signed-off-by: Christoph Lameter<cl@linux.com>
>
>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
next prev parent reply other threads:[~2012-02-24 17:07 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 18:07 [RFC][PATCH] fix move/migrate_pages() race on task struct Dave Hansen
2012-02-23 18:07 ` Dave Hansen
2012-02-23 18:45 ` Andi Kleen
2012-02-23 18:45 ` Andi Kleen
2012-02-23 18:45 ` Christoph Lameter
2012-02-23 18:45 ` Christoph Lameter
2012-02-23 19:10 ` Dave Hansen
2012-02-23 19:10 ` Dave Hansen
2012-02-23 19:40 ` Christoph Lameter
2012-02-23 19:40 ` Christoph Lameter
2012-02-23 20:04 ` Dave Hansen
2012-02-23 20:04 ` Dave Hansen
2012-02-23 21:41 ` Christoph Lameter
2012-02-23 21:41 ` Christoph Lameter
2012-02-24 3:14 ` Eric W. Biederman
2012-02-24 3:14 ` Eric W. Biederman
2012-02-24 15:20 ` Christoph Lameter
2012-02-24 15:20 ` Christoph Lameter
2012-02-24 15:41 ` Eric W. Biederman
2012-02-24 15:41 ` Eric W. Biederman
2012-02-24 16:48 ` Dave Hansen
2012-02-24 16:48 ` Dave Hansen
2012-02-24 16:54 ` Christoph Lameter
2012-02-24 16:54 ` Christoph Lameter
2012-02-24 17:04 ` Dave Hansen
2012-02-24 17:04 ` Dave Hansen
2012-02-24 17:08 ` Christoph Lameter
2012-02-24 17:08 ` Christoph Lameter
2012-02-24 17:25 ` Dave Hansen
2012-02-24 17:25 ` Dave Hansen
2012-02-24 17:32 ` Christoph Lameter
2012-02-24 17:32 ` Christoph Lameter
2012-02-24 21:37 ` Dave Hansen
2012-02-24 21:37 ` Dave Hansen
2012-02-24 23:12 ` Eric W. Biederman
2012-02-24 23:12 ` Eric W. Biederman
2012-02-27 16:43 ` Christoph Lameter
2012-02-27 16:43 ` Christoph Lameter
2012-02-25 12:13 ` Eric W. Biederman
2012-02-25 12:13 ` Eric W. Biederman
2012-02-27 19:01 ` Christoph Lameter
2012-02-27 19:01 ` Christoph Lameter
2012-02-27 20:15 ` Eric W. Biederman
2012-02-27 20:15 ` Eric W. Biederman
2012-02-27 22:39 ` Christoph Lameter
2012-02-27 22:39 ` Christoph Lameter
2012-02-28 19:30 ` Christoph Lameter
2012-02-28 19:30 ` Christoph Lameter
2012-02-29 20:31 ` Andrew Morton
2012-02-29 20:31 ` Andrew Morton
2012-02-29 20:33 ` Christoph Lameter
2012-02-29 20:33 ` Christoph Lameter
2012-02-29 20:36 ` Dave Hansen
2012-02-29 20:36 ` Dave Hansen
2012-02-24 17:07 ` KOSAKI Motohiro [this message]
2012-02-24 17:07 ` 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=4F47C3B7.20109@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=cl@linux.com \
--cc=dave@linux.vnet.ibm.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.