From: Christoph Lameter <cl@linux.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] fix move/migrate_pages() race on task struct
Date: Mon, 27 Feb 2012 10:43:47 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.00.1202271039320.29787@router.home> (raw)
In-Reply-To: <87zkc7eshq.fsf@xmission.com>
On Fri, 24 Feb 2012, Eric W. Biederman wrote:
> Taking a quick look it does appear that in cpuset_mems_allowed and it's
> cousins we never sleep under "callback_mutex" so that lock looks like it
> could become a spinlock.
>
> But I have to say something just bothers me about the permissions for
> modifying an mm living in the task. We can have different rules
> for modifying an mm depending on the path to tme mm?
Yes. Permissions are associated with pids which refer to tasks. Tasks have
address spaces and tasks may share address spaces.
> Especially in things like which numa nodes we can put pages in?
Things = address spaces? The page migration functionality is about moving
the location of physical memory from one numa node to the other. It does
not affect the execution just the latencies experienced by the processes.
> So by specifying a different pid to access them mm through the call can
> either work or succeed? Are these checks really sane?
Yes if you can create two pids with the same address space and give
those those pids to different owners then the permission checks on one
may fail and succeed on the other. We have no way to refer to address
spaces from user space outside of a pid.
--
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>
next prev parent reply other threads:[~2012-02-27 16:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 18:07 Dave Hansen
2012-02-23 18:45 ` Andi Kleen
2012-02-23 18:45 ` Christoph Lameter
2012-02-23 19:10 ` Dave Hansen
2012-02-23 19:40 ` Christoph Lameter
2012-02-23 20:04 ` Dave Hansen
2012-02-23 21:41 ` Christoph Lameter
2012-02-24 3:14 ` Eric W. Biederman
2012-02-24 15:20 ` Christoph Lameter
2012-02-24 15:41 ` Eric W. Biederman
2012-02-24 16:48 ` Dave Hansen
2012-02-24 16:54 ` Christoph Lameter
2012-02-24 17:04 ` Dave Hansen
2012-02-24 17:08 ` Christoph Lameter
2012-02-24 17:25 ` Dave Hansen
2012-02-24 17:32 ` Christoph Lameter
2012-02-24 21:37 ` Dave Hansen
2012-02-24 23:12 ` Eric W. Biederman
2012-02-27 16:43 ` Christoph Lameter [this message]
2012-02-25 12:13 ` Eric W. Biederman
2012-02-27 19:01 ` Christoph Lameter
2012-02-27 20:15 ` Eric W. Biederman
2012-02-27 22:39 ` Christoph Lameter
2012-02-28 19:30 ` Christoph Lameter
2012-02-29 20:31 ` Andrew Morton
2012-02-29 20:33 ` Christoph Lameter
2012-02-29 20:36 ` Dave Hansen
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=alpine.DEB.2.00.1202271039320.29787@router.home \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox