Messages in this thread | | | Subject | Re: [Fastboot] Re: kexec "problem" [and patch updates] | From | (Eric W. Biederman) | Date | 07 Mar 2004 17:32:00 -0700 |
| |
Hariprasad Nellitheertha <hari@in.ibm.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |