lkml.org 
[lkml]   [2004]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Fastboot] Re: kexec "problem" [and patch updates]
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.301 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site