Re: [Fastboot] Re: kexec "problem" [and patch updates]

[Eric W. Biederman]

Hariprasad Nellitheertha <hari@xxxxxxxxxx> writes:

> Hello,
> 
> I recreated this on a UNI system running an SMP kernel as well. 
> 
> The problem is because we now initialize cpu_vm_mask for init_mm with 
> CPU_MASK_ALL (from 2.6.3 onwards) which makes all bits in cpumask 1. 
> Hence BUG_ON(!cpus_equal(cpumask,tmp) fails. The change to set 
> cpu_vm_mask to CPU_MASK_ALL was done to remove tlb flush optimizations 
> for ppc64. On UNI kernels, CPU_MASK_ALL is 1 and hence the problem 
> does not occur.

So the problem is that CPU_MASK_ALL includes cpus that are not currently
online.  So it has gone from being wrong by including too few cpus
to being wrong by including too many cpus.
 
> I made a small patch which fixes this problem. The change is, essentially,
> to use "tmp" instead of "cpumask". This ensures that only the (other) online 
> cpus are sent the IPI. 
> 
> I have done some testing with this patch. Kexec loads fine and I haven't seen
> anything untoward. 
> 
> Comments please.

Any chance we can fix this right and get a proper value in cpu_vm_mask
for init_mm?  All that needs to happen is that each cpu as it is
started up is included in cpu_vm_mask.

The reason kexec sees this is that it is possibly the only generic
modifier of init_mm. 

If fixing this needs to be kexec specific we need to simply remove
using init_mm.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/