Re: linux-next: Tree for June 5
From: Mike Travis <hidden>
Date: 2008-06-06 14:13:36
Also in:
lkml
Vegard Nossum wrote:
quoted hunk ↗ jump to hunk
On Fri, Jun 6, 2008 at 3:33 PM, Mike Travis [off-list ref] wrote:quoted
Vegard Nossum wrote:quoted
I reproced it with gc 4.1.2. I think the error is somewhere in kernel/sched.c. static int __build_sched_domains(const cpumask_t *cpu_map, struct sched_domain_attr *attr) { ... for (i = 0; i < MAX_NUMNODES; i++) { ... sg = kmalloc_node(sizeof(struct sched_group), GFP_KERNEL, i); ... This code is calling into the allocator with a spurious value of i, which causes SLAB to use an index (of 4 in my case) that is out of bounds for its nodelist array (at least it hasn't been initialized). This bit of code (a bit further down, inside the same loop) is also dubious: sg = kmalloc_node(sizeof(struct sched_group), GFP_KERNEL, i); if (!sg) { printk(KERN_WARNING "Can not alloc domain group for node %d\n", j); goto error; } Where it passes i to kmalloc_node() but reports an allocation for node j. Which one is correct?Hm, I think I'm wrong and the code is correct. However...quoted
quoted
Hope this helps, will send an update if I find out more. VegardThanks Vegard for tracking this down. My thoughts were along the same wavelength... ;-)I applied this patch@@ -7133,6 +7133,14 @@ static int __build_sched_domains(constcpumask_t *cpu_map, cpus_clear(*covered); cpus_and(*nodemask, *nodemask, *cpu_map); + + printk("node %d\n", i); + for (j = 0; j < NR_CPUS; ++j) + printk("%c", cpu_isset(j, *nodemask) ? 'X' : '.'); + printk("\n"); + + printk("empty = %d\n", cpus_empty(*nodemask)); + if (cpus_empty(*nodemask)) { sched_group_nodes[i] = NULL; continue; and it shows some really strange output, maybe it makes sense to you: (the X means cpu is in the node) Total of 2 processors activated (11976.24 BogoMIPS). node 0 XX.............................................................................. ................................................................................ ................................................................................ ............... empty = 0 node 1 XX.............................................................................. ................................................................................ ................................................................................ ............... empty = 0 l3 = cachep->nodelists[0] (size-64) = ffff81003f824340 node 2 ................................................................................ ................................................................................ ................................................................................ ............... empty = 1 node 3 ................................................................................ ................................................................................ ................................................................................ ............... empty = 1 node 4 X............................................................................... ................................................................................ ................................................................................ ............... empty = 0 This is a P4 3.0GHz with 1 physical CPU (but HT, so two logical CPUs). Yet node 4 is claimed to have a cpu too. That's bogus! (But I don't think it's an error in sched.c any more, probably the code that sets up the node maps.) Vegard
Could you send me the full console log and your config file? The setup of the node_to_cpumask map is dependent on the early discovery (usually in the apic code) and there's been some changes in that area recently. Thanks, Mike