[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4C9B168A.9000702@kernel.org>
Date: Thu, 23 Sep 2010 10:57:46 +0200
From: Tejun Heo <tj@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
lkml <linux-kernel@...r.kernel.org>,
CAI Qian <caiqian@...hat.com>
Subject: [GIT PULL] percpu: fixes for v2.6.36-rc5
Hello, Linus.
Please pull from the following branch to receive a percpu fix for
v2.6.36-rc5.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git for-linus
It contains only one patch to fix incorrect pcpu_last_unit_cpu
initialization. When the number of possible CPUs isn't power of two,
there can be unused holes at the end of each percpu chunk. Percpu
init code uses NR_CPUS to mark these holes. pcpu_last_unit_cpu should
contain the CPU which maps to the last unit in the chunk but when the
above condition occurs, it contained NR_CPUS instead, which makes
percpu code miscalculate the address range covered by a chunk for
per_cpu_ptr_to_phys() and tlb and v[un]map flushses and has potential
to cause weird issues especially on virtual cache architectures.
This problem was discovered by CAI Qian during kvm kdump testing.
Kudos to him for finding this subtle problem.
Thanks.
Tejun Heo (1):
percpu: fix pcpu_last_unit_cpu
mm/percpu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 58c572b..c76ef38 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1401,9 +1401,9 @@ int __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
if (pcpu_first_unit_cpu == NR_CPUS)
pcpu_first_unit_cpu = cpu;
+ pcpu_last_unit_cpu = cpu;
}
}
- pcpu_last_unit_cpu = cpu;
pcpu_nr_units = unit;
for_each_possible_cpu(cpu)
--
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