From: Andrew Morton <akpm@osdl.org>
To: "Pawe__ Sikora" <pluto@agmk.net>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Pekka Enberg <penberg@cs.helsinki.fi>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
Martin Peschke <mp3@de.ibm.com>, Adrian Bunk <bunk@stusta.de>,
Andi Kleen <ak@suse.de>
Subject: Re: Linux 2.6.20-rc7
Date: Wed, 31 Jan 2007 16:14:14 -0800 [thread overview]
Message-ID: <20070131161414.06e98e4a.akpm@osdl.org> (raw)
In-Reply-To: <200702010037.48472.pluto@agmk.net>
On Thu, 1 Feb 2007 00:37:48 +0100
Pawe__ Sikora <pluto@agmk.net> wrote:
> On Wednesday 31 of January 2007 17:04:29 Linus Torvalds wrote:
> > On Wed, 31 Jan 2007, Pawe__ Sikora wrote:
> > > The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> > >
> > > [ an oops inside kmem_get_pages ]
> > > http://bugzilla.kernel.org/show_bug.cgi?id=7889
> >
> > Pabel, can you detail more exactly which kernels don't work, and which do?
>
> 2.6.18 works, 2.6.19-rc1 doesn't work.
> git bisect found this bad commit:
>
> commit e80ee884ae0e3794ef2b65a18a767d502ad712ee
> Author: Nick Piggin <nickpiggin@yahoo.com.au>
> Date: Wed Oct 4 02:15:23 2006 -0700
>
> [PATCH] mm: micro optimise zone_watermark_ok
>
> Having min be a signed quantity means gcc can't turn high latency divides
> into shifts. There happen to be two such divides for GFP_ATOMIC (ie.
> networking, ie. important) allocations, one of which depends on the
> other.
> Fixing this makes code smaller as a bonus.
>
> Shame on somebody (probably me).
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
>
> ------------------------- mm/page_alloc.c -----------------------
> @@ -900,7 +900,8 @@ int zone_watermark_ok(struct zone *z, int order, unsigned
> long mark,
> int classzone_idx, int alloc_flags)
> {
> /* free_pages my go negative - that's OK */
> - long min = mark, free_pages = z->free_pages - (1 << order) + 1;
> + unsigned long min = mark;
> + long free_pages = z->free_pages - (1 << order) + 1;
> int o;
>
> if (alloc_flags & ALLOC_HIGH)
>
>
> > Apparently it only happens with MEMORY_HOTPLUG (and possibly with just an
> > SMP kernel on UP), which probably explains why it's been around without
> > people really complaining very loudly.
>
> reverting mentioned commit removes the oops.
>
urgh. zone->free_pages is very small - probably zero. We shouldn't have
got here at all, so something else is wrong.
But local `free_pages' can go negative in normal operation. I guess
that'll cause us to incorrectly return `true' from zone_watermark_ok, thus
ignoring the watermarks.
The below, I guess. But we still don't know why this got called against an
empty zone.
Subject: zone_watermark_ok: signedness fix
From: Andrew Morton <akpm@osdl.org>
Local `free_pages' can go negative in normal operation. I guess that'll cause
us to incorrectly return `true' from zone_watermark_ok, thus ignoring the
watermarks.
Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
mm/page_alloc.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/page_alloc.c~zone_watermark_ok-signedness-fix mm/page_alloc.c
--- a/mm/page_alloc.c~zone_watermark_ok-signedness-fix
+++ a/mm/page_alloc.c
@@ -1013,7 +1013,7 @@ int zone_watermark_ok(struct zone *z, in
int classzone_idx, int alloc_flags)
{
/* free_pages my go negative - that's OK */
- unsigned long min = mark;
+ long min = mark;
long free_pages = zone_page_state(z, NR_FREE_PAGES)
- (1 << order) + 1;
int o;
_
next prev parent reply other threads:[~2007-02-01 0:17 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-31 4:28 Linux 2.6.20-rc7 Linus Torvalds
[not found] ` <45C05150.6000802@agmk.net>
2007-01-31 16:04 ` Linus Torvalds
2007-01-31 23:13 ` Andrew Morton
[not found] ` <200702010037.48472.pluto@agmk.net>
2007-02-01 0:14 ` Andrew Morton [this message]
2007-02-01 0:19 ` Linus Torvalds
2007-02-01 0:26 ` Andrew Morton
2007-02-01 0:39 ` Linus Torvalds
2007-02-01 0:44 ` Nick Piggin
2007-02-01 0:54 ` Linus Torvalds
2007-02-01 6:48 ` Pekka Enberg
2007-01-31 17:11 ` [PATCH] x86_64: Fix preprocessor condition Josef 'Jeff' Sipek
2007-01-31 17:16 ` Andi Kleen
2007-01-31 17:40 ` Josef Sipek
2007-01-31 18:15 ` Linux 2.6.20-rc7 Sunil Naidu
2007-02-01 2:16 ` S.Çağlar Onur
2007-02-01 2:36 ` Linus Torvalds
2007-02-01 3:01 ` S.Çağlar Onur
2007-02-01 3:31 ` Linus Torvalds
2007-02-01 5:44 ` H. Peter Anvin
2007-02-01 6:00 ` Linus Torvalds
2007-02-01 6:10 ` H. Peter Anvin
2007-02-01 6:38 ` Alexander E. Patrakov
2007-02-01 6:53 ` H. Peter Anvin
2007-02-02 20:52 ` S.Çağlar Onur
2007-02-01 21:06 ` H. Peter Anvin
2007-02-02 5:49 ` 2.6.20-rc7: known regressions Adrian Bunk
2007-02-02 5:49 ` Adrian Bunk
2007-02-02 5:49 ` Adrian Bunk
2007-02-03 1:55 ` Andrew Morton
2007-02-03 2:03 ` Jeff Garzik
2007-02-03 2:15 ` Andrew Morton
2007-02-03 9:19 ` Frédéric Riss
2007-02-03 9:24 ` Andrew Morton
2007-02-03 9:33 ` Andi Kleen
2007-02-03 9:49 ` Frédéric Riss
2007-02-03 9:58 ` Andi Kleen
2007-02-03 10:47 ` Frédéric Riss
2007-02-03 10:51 ` Andi Kleen
2007-02-03 10:57 ` Frédéric Riss
2007-02-03 11:08 ` Frédéric RISS
2007-02-04 13:13 ` Frédéric Riss
2007-02-04 14:37 ` Andi Kleen
2007-02-04 17:34 ` Linus Torvalds
2007-02-04 18:18 ` Frédéric Riss
2007-02-04 18:29 ` Linus Torvalds
2007-02-05 8:26 ` Andi Kleen
2007-02-05 9:35 ` Eric W. Biederman
2007-02-03 0:44 ` 2.6.20-rc7: known regressions (v2) (part 1) Adrian Bunk
2007-02-03 0:44 ` Adrian Bunk
2007-02-03 6:06 ` Auke Kok
2007-02-03 7:41 ` Eric W. Biederman
2007-02-03 18:06 ` Adam Kropelin
2007-02-03 20:43 ` Auke Kok
2007-02-03 21:00 ` Adam Kropelin
2007-02-03 21:26 ` Auke Kok
2007-02-03 22:24 ` Eric W. Biederman
2007-02-03 21:12 ` Eric W. Biederman
2007-02-03 23:20 ` Adam Kropelin
2007-02-04 1:14 ` Eric W. Biederman
2007-02-04 4:44 ` Adam Kropelin
2007-02-04 5:12 ` Eric W. Biederman
2007-02-03 0:47 ` 2.6.20-rc7: known regressions (v2) (part 2) Adrian Bunk
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=20070131161414.06e98e4a.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ak@suse.de \
--cc=bunk@stusta.de \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mp3@de.ibm.com \
--cc=penberg@cs.helsinki.fi \
--cc=pluto@agmk.net \
--cc=suresh.b.siddha@intel.com \
--cc=torvalds@linux-foundation.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.