Re: Linux 2.6.20-rc7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 1 Feb 2007 00:37:48 +0100
Pawe__ Sikora <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>     Signed-off-by: Andrew Morton <[email protected]>
>     Signed-off-by: Linus Torvalds <[email protected]>
> 
> ------------------------- 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 <[email protected]>

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 <[email protected]>
Cc: Nick Piggin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

 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;
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux