From: Greg KH <gregkh@suse.de>
To: Stefan Lippers-Hollmann <s.L-H@gmx.de>
Cc: linux-kernel@vger.kernel.org, kosaki.motohiro@jp.fujitsu.com,
akpm@linux-foundation.org, cl@linux-foundation.org,
dave@linux.vnet.ibm.com, ebmunson@us.ibm.com, mel@csn.ul.ie,
stable@kernel.org
Subject: Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree
Date: Tue, 5 May 2009 13:53:09 -0700 [thread overview]
Message-ID: <20090505205309.GA7141@suse.de> (raw)
In-Reply-To: <200905052036.24106.s.L-H@gmx.de>
On Tue, May 05, 2009 at 08:36:19PM +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Dienstag, 5. Mai 2009, gregkh@suse.de wrote:
> [...]
> > From 00a62ce91e554198ef28234c91c36f850f5a3bc9 Mon Sep 17 00:00:00 2001
> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > Date: Thu, 30 Apr 2009 15:08:51 -0700
> > Subject: mm: fix Committed_AS underflow on large NR_CPUS environment
> >
> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> >
> > commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream.
> >
> > The Committed_AS field can underflow in certain situations:
> >
> > > # while true; do cat /proc/meminfo | grep _AS; sleep 1; done | uniq -c
> > > 1 Committed_AS: 18446744073709323392 kB
> > > 11 Committed_AS: 18446744073709455488 kB
> > > 6 Committed_AS: 35136 kB
> > > 5 Committed_AS: 18446744073709454400 kB
> > > 7 Committed_AS: 35904 kB
> > > 3 Committed_AS: 18446744073709453248 kB
> > > 2 Committed_AS: 34752 kB
> > > 9 Committed_AS: 18446744073709453248 kB
> > > 8 Committed_AS: 34752 kB
> > > 3 Committed_AS: 18446744073709320960 kB
> > > 7 Committed_AS: 18446744073709454080 kB
> > > 3 Committed_AS: 18446744073709320960 kB
> > > 5 Committed_AS: 18446744073709454080 kB
> > > 6 Committed_AS: 18446744073709320960 kB
> >
> > Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
> > not check for underflow.
> >
> > But NR_CPUS proportional isn't good calculation. In general,
> > possibility of lock contention is proportional to the number of online
> > cpus, not theorical maximum cpus (NR_CPUS).
> >
> > The current kernel has generic percpu-counter stuff. using it is right
> > way. it makes code simplify and percpu_counter_read_positive() don't
> > make underflow issue.
>
> This patch reproducably panics on all systems I could test so far on
> 2.6.29.2 + the current stable queue:
> - Acer Aspire One, Intel Atom N270, Intel 945GC chipset (i386)
> - AMD64 3200+, nVidia nforce3 chipset (amd64)
> - AMD64 X2 4200+, nVidia nforce4 chipset (amd64)
>
> Kernel panic (sorry, this is from a bad webcam and only the last part of
> the messages scrolling by - I can try to get a serial console tomorrow),
> taken from an AMD64 3200+, nVidia nforce3 chipset (amd64).
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/panic.gif [198 KB]
>
> Reverting just this patch fixes the problem for me.
>
> Kernel configurations:
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.3-sidux-686 [96 KB]
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.6-sidux-amd64 [91 KB]
Thanks for the report, I'm also getting some oopses on boot and am
bisecting down the tree right now. The error looks a bit like yours,
but not identical enough for me to declare that it is the same thing
just yet.
Give me a few more hours...
thanks,
greg k-h
next parent reply other threads:[~2009-05-05 21:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090504220454.3F71148FB8@coco.kroah.org>
[not found] ` <200905052036.24106.s.L-H@gmx.de>
2009-05-05 20:53 ` Greg KH [this message]
2009-05-05 22:14 ` patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree Greg KH
2009-05-05 22:26 ` KOSAKI Motohiro
2009-05-05 22:40 ` Greg KH
2009-05-05 22:58 ` KOSAKI Motohiro
2009-05-05 22:59 ` Greg KH
2009-05-05 23:12 ` KOSAKI Motohiro
2009-05-06 6:20 ` Greg KH
2009-05-06 16:37 ` [stable] " Greg KH
2009-05-06 16:46 ` Stefan Lippers-Hollmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090505205309.GA7141@suse.de \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=ebmunson@us.ibm.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=s.L-H@gmx.de \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.