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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox