From: akpm@linux-foundation.org
To: mm-commits@vger.kernel.org
Cc: miaox@cn.fujitsu.com, andi@firstfloor.org,
cl@linux-foundation.org, hugh.dickins@tiscali.co.uk,
kiran@scalex86.org, kosaki.motohiro@jp.fujitsu.com,
lee.schermerhorn@hp.com, menage@google.com, npiggin@suse.de,
rientjes@google.com
Subject: + cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2.patch added to -mm tree
Date: Wed, 12 May 2010 00:27:56 -0400 [thread overview]
Message-ID: <201005120729.o4C7TOYe016173@imap1.linux-foundation.org> (raw)
The patch titled
cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2
has been added to the -mm tree. Its filename is
cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2
From: Miao Xie <miaox@cn.fujitsu.com>
- cleanup unnecessary header file
- fix the race between set_mempolicy() and cpuset_change_task_nodemask()
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Miao Xie <miaox@cn.fujitsu.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Paul Menage <menage@google.com>
Cc: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/cpuset.c | 3 +--
kernel/exit.c | 1 -
kernel/fork.c | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)
diff -puN kernel/cpuset.c~cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2 kernel/cpuset.c
--- a/kernel/cpuset.c~cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2
+++ a/kernel/cpuset.c
@@ -963,7 +963,6 @@ repeat:
task_lock(tsk);
nodes_or(tsk->mems_allowed, tsk->mems_allowed, *newmems);
mpol_rebind_task(tsk, newmems, MPOL_REBIND_STEP1);
- task_unlock(tsk);
/*
@@ -985,6 +984,7 @@ repeat:
* for the read-side.
*/
while (ACCESS_ONCE(tsk->mems_allowed_change_disable)) {
+ task_unlock(tsk);
if (!task_curr(tsk))
yield();
goto repeat;
@@ -999,7 +999,6 @@ repeat:
*/
smp_mb();
- task_lock(tsk);
mpol_rebind_task(tsk, newmems, MPOL_REBIND_STEP2);
tsk->mems_allowed = *newmems;
task_unlock(tsk);
diff -puN kernel/exit.c~cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2 kernel/exit.c
--- a/kernel/exit.c~cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2
+++ a/kernel/exit.c
@@ -16,7 +16,6 @@
#include <linux/key.h>
#include <linux/security.h>
#include <linux/cpu.h>
-#include <linux/cpuset.h>
#include <linux/acct.h>
#include <linux/tsacct_kern.h>
#include <linux/file.h>
diff -puN kernel/fork.c~cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2 kernel/fork.c
--- a/kernel/fork.c~cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2
+++ a/kernel/fork.c
@@ -31,7 +31,6 @@
#include <linux/nsproxy.h>
#include <linux/capability.h>
#include <linux/cpu.h>
-#include <linux/cpuset.h>
#include <linux/cgroup.h>
#include <linux/security.h>
#include <linux/hugetlb.h>
_
Patches currently in -mm which might be from miaox@cn.fujitsu.com are
mempolicy-restructure-rebinding-mempolicy-functions.patch
cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems.patch
cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix.patch
cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-fix2.patch
cpusetmm-fix-no-node-to-alloc-memory-when-changing-cpusets-mems-spelling.patch
reply other threads:[~2010-05-12 7:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=201005120729.o4C7TOYe016173@imap1.linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kiran@scalex86.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=miaox@cn.fujitsu.com \
--cc=mm-commits@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=rientjes@google.com \
/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