[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1410438733.543594834@decadent.org.uk>
Date: Thu, 11 Sep 2014 13:32:13 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org, "David Rientjes" <rientjes@...gle.com>,
penberg@...nel.org, "Andi Kleen" <ak@...ux.intel.com>,
"David Mackey" <tdmackey@...tter.com>,
"KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>, cl@...ux.com,
"Arun Sharma" <asharma@...com>
Subject: [PATCH 3.2 121/131] slab/mempolicy: always use local policy from
interrupt context
3.2.63-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <ak@...ux.intel.com>
commit e7b691b085fda913830e5280ae6f724b2a63c824 upstream.
slab_node() could access current->mempolicy from interrupt context.
However there's a race condition during exit where the mempolicy
is first freed and then the pointer zeroed.
Using this from interrupts seems bogus anyways. The interrupt
will interrupt a random process and therefore get a random
mempolicy. Many times, this will be idle's, which noone can change.
Just disable this here and always use local for slab
from interrupts. I also cleaned up the callers of slab_node a bit
which always passed the same argument.
I believe the original mempolicy code did that in fact,
so it's likely a regression.
v2: send version with correct logic
v3: simplify. fix typo.
Reported-by: Arun Sharma <asharma@...com>
Cc: penberg@...nel.org
Cc: cl@...ux.com
Signed-off-by: Andi Kleen <ak@...ux.intel.com>
[tdmackey@...tter.com: Rework control flow based on feedback from
cl@...ux.com, fix logic, and cleanup current task_struct reference]
Acked-by: David Rientjes <rientjes@...gle.com>
Acked-by: Christoph Lameter <cl@...ux.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Signed-off-by: David Mackey <tdmackey@...tter.com>
Signed-off-by: Pekka Enberg <penberg@...nel.org>
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
include/linux/mempolicy.h | 2 +-
mm/mempolicy.c | 8 +++++++-
mm/slab.c | 4 ++--
mm/slub.c | 2 +-
4 files changed, 11 insertions(+), 5 deletions(-)
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -205,7 +205,7 @@ extern struct zonelist *huge_zonelist(st
extern bool init_nodemask_of_mempolicy(nodemask_t *mask);
extern bool mempolicy_nodemask_intersects(struct task_struct *tsk,
const nodemask_t *mask);
-extern unsigned slab_node(struct mempolicy *policy);
+extern unsigned slab_node(void);
extern enum zone_type policy_zone;
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1601,8 +1601,14 @@ static unsigned interleave_nodes(struct
* task can change it's policy. The system default policy requires no
* such protection.
*/
-unsigned slab_node(struct mempolicy *policy)
+unsigned slab_node(void)
{
+ struct mempolicy *policy;
+
+ if (in_interrupt())
+ return numa_node_id();
+
+ policy = current->mempolicy;
if (!policy || policy->flags & MPOL_F_LOCAL)
return numa_node_id();
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3270,7 +3270,7 @@ static void *alternate_node_alloc(struct
if (cpuset_do_slab_mem_spread() && (cachep->flags & SLAB_MEM_SPREAD))
nid_alloc = cpuset_slab_spread_node();
else if (current->mempolicy)
- nid_alloc = slab_node(current->mempolicy);
+ nid_alloc = slab_node();
if (nid_alloc != nid_here)
return ____cache_alloc_node(cachep, flags, nid_alloc);
return NULL;
@@ -3302,7 +3302,7 @@ static void *fallback_alloc(struct kmem_
retry_cpuset:
cpuset_mems_cookie = get_mems_allowed();
- zonelist = node_zonelist(slab_node(current->mempolicy), flags);
+ zonelist = node_zonelist(slab_node(), flags);
retry:
/*
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1608,7 +1608,7 @@ static struct page *get_any_partial(stru
do {
cpuset_mems_cookie = get_mems_allowed();
- zonelist = node_zonelist(slab_node(current->mempolicy), flags);
+ zonelist = node_zonelist(slab_node(), flags);
for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
struct kmem_cache_node *n;
--
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