Re: [PATCH v2 1/2] Replace if statement with WARN_ON_ONCE() in cmci_rediscover().

[Tang Chen]

On 10/20/2012 12:40 AM, Borislav Petkov wrote:
> On Fri, Oct 19, 2012 at 01:45:27PM +0800, Tang Chen wrote:
> > cmci_rediscover() is only called by the CPU_POST_DEAD event handler,
> > which means the corresponding cpu has already dead. As a result, it
> > won't be accessed in the for_each_online_cpu loop.
> > So, we could change the if(cpu == dying) statement into a WARN_ON_ONCE().
> >
> > Signed-off-by: Tang Chen<tangchen@xxxxxxxxxxxxxx>
> > ---
> >   arch/x86/kernel/cpu/mcheck/mce_intel.c |    4 ++--
> >   1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > index 38e49bc..481d152 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > @@ -180,8 +180,8 @@ void cmci_rediscover(int dying)
> >   	cpumask_copy(old,&current->cpus_allowed);
> >
> >   	for_each_online_cpu(cpu) {
> > -		if (cpu == dying)
> > -			continue;
> > +		WARN_ON_ONCE(cpu == dying);
>
> Ok, I don't understand that:
>
> we want to warn that the rediscovering is happening on a dying cpu?? And
> before that, we simply jumped over it and didn't do the rediscovering
> there? Why should we warn at all?

Hi Borislav,

As far as I know, cmci_rediscover() is only called in
mce_cpu_callback() to handle CPU_POST_DEAD event.

2362         if (action == CPU_POST_DEAD) {
2363                 /* intentionally ignoring frozen here */
2364                 cmci_rediscover(cpu);
2365         }

I didn't find anywhere else using this function. So I think the cpu
should be dead already when this function is called.

I don't why before we just jumped over it. But I think if we have an
online cpu == dying here, it must be wrong. So I think we should warn
it, not just jump over it.

Thanks. :)


> Huh?

--
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/