Fwd: Inoffensive bug in mm/page_alloc.c

Fwd: Inoffensive bug in mm/page_alloc.c

[Paul Hamshere]

Is this of any interest here?
Paul
------------------------------
Hi
I was trawling through the mm sources to try and understand how linux tracks the
use of pages of memory, how kmalloc and vmalloc work, and I think there is a bug
in the kernel (2.0) - it doesn't affect anything, only waste a tiny amount of
memory....does anyone else think it looks wrong?
The problem is in free_area_init where it allocates the bitmaps - I think they
are twice the size they need to be.
The dodgy line is

            bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i );

which I think should be 

            bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i + 1);

because the bitmap refers to adjacent pages.
I've changed my kernel to the second line and it seems to work.
Paul


----------------------------------------------------

unsigned long free_area_init(unsigned long start_mem, unsigned long end_mem)
{
      mem_map_t * p;
      unsigned long mask = PAGE_MASK;
      int i;

      /*
       * select nr of pages we try to keep free for important stuff
       * with a minimum of 48 pages. This is totally arbitrary
       */
      i = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT+7);
      if (i < 24)
            i = 24;
      i += 24;   /* The limit for buffer pages in __get_free_pages is
                * decreased by 12+(i>>3) */
      min_free_pages = i;
      free_pages_low = i + (i>>1);
      free_pages_high = i + i;
      start_mem = init_swap_cache(start_mem, end_mem);
      mem_map = (mem_map_t *) start_mem;
      p = mem_map + MAP_NR(end_mem);
      start_mem = LONG_ALIGN((unsigned long) p);
      memset(mem_map, 0, start_mem - (unsigned long) mem_map);
      do {
            --p;
            p->flags = (1 << PG_DMA) | (1 << PG_reserved);
            p->map_nr = p - mem_map;
      } while (p > mem_map);

      for (i = 0 ; i < NR_MEM_LISTS ; i++) {
            unsigned long bitmap_size;
            init_mem_queue(free_area+i);
            mask += mask;
            end_mem = (end_mem + ~mask) & mask;
/* commented out because not correct ?? PH
            bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i);
*/
            bitmap_size = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT + i +1);
            bitmap_size = (bitmap_size + 7) >> 3;
            bitmap_size = LONG_ALIGN(bitmap_size);
            free_area[i].map = (unsigned int *) start_mem;
            memset((void *) start_mem, 0, bitmap_size);
            start_mem += bitmap_size;
      }
      return start_mem;
}




--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Fwd: Inoffensive bug in mm/page_alloc.c

[Benjamin C.R. LaHaise]

Hello Paul,

> Is this of any interest here?

Yep!

> Paul
> ------------------------------
> Hi
> I was trawling through the mm sources to try and understand how linux tracks the
> use of pages of memory, how kmalloc and vmalloc work, and I think there is a bug
> in the kernel (2.0) - it doesn't affect anything, only waste a tiny amount of
> memory....does anyone else think it looks wrong?
> The problem is in free_area_init where it allocates the bitmaps - I think they
> are twice the size they need to be.

If you search the mailing list archives from either a year, maybe two ago,
someone brought forth the same concern, but Linus rejected the patch on
the basis that it wasn't trivially proven correct for *all* sizes of
memory.  The amount of memory involved is insignificant, and I'd speculate
that we'll see a page allocator in 2.3 at which point that loss can
disappear.

		-ben (cleaning out the inbox)

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/