Re: [PATCH 5/6] memcg: fix broken boolen expression

[Kirill A. Shutemov]

On Wed, Apr 04, 2012 at 02:34:03PM -0700, Andrew Morton wrote:
> On Sat, 24 Dec 2011 05:00:18 +0200
> "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> wrote:
> 
> > From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
> > 
> > action != CPU_DEAD || action != CPU_DEAD_FROZEN is always true.
> > 
> > Signed-off-by: Kirill A. Shutemov <kirill@xxxxxxxxxxxxx>
> > ---
> >  mm/memcontrol.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index b27ce0f..3833a7b 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -2100,7 +2100,7 @@ static int __cpuinit memcg_cpu_hotplug_callback(struct notifier_block *nb,
> >  		return NOTIFY_OK;
> >  	}
> >  
> > -	if ((action != CPU_DEAD) || action != CPU_DEAD_FROZEN)
> > +	if (action != CPU_DEAD && action != CPU_DEAD_FROZEN)
> >  		return NOTIFY_OK;
> >  
> >  	for_each_mem_cgroup(iter)
> 
> This spent too long in the backlog, sorry.
> 
> I don't want to merge this patch into either mainline or -stable until
> I find out what it does!
> 
> afacit the patch will newly cause the kernel to drain various resource
> counters away from the target CPU when the CPU_DEAD or CPU_DEAD_FROZEN
> events occur for thet CPU, yes?

Yes.

> So the user-visible effects of the bug whcih was just fixed is that
> these counters will be somewhat inaccurate after a CPU is taken down,
> yes?

Correct.

> Why wasn't this bug noticed before?

I guess CPU hotplug is not a usual test case for memcg changes. And the
result of the bug is inaccurate statistics, but not something dramatic
(oops, panic, etc.).

> Has anyone tested the patch and
> confirmed that the numbers are now correct?

I haven't. I found the bug with sparse.

> Given that this bug has been present for 1.5 years and nobody noticed,
> I don't think a backport into -stable is warranted?
> 

-- 
 Kirill A. Shutemov
--
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/