From: Paul Hamshere <ph@clara.net>
To: Linux-MM@kvack.org
Subject: Fwd: Inoffensive bug in mm/page_alloc.c
Date: Wed, 27 Jan 99 23:55:52 GMT [thread overview]
Message-ID: <990127235552.n0002181.ph@mail.clara.net> (raw)
In-Reply-To: 990119214302.n0001113.ph@mail.clara.net
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/
next parent reply other threads:[~1999-01-27 23:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <990119214302.n0001113.ph@mail.clara.net>
1999-01-27 23:55 ` Paul Hamshere [this message]
1999-01-30 1:52 ` Fwd: Inoffensive bug in mm/page_alloc.c Benjamin C.R. LaHaise
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=990127235552.n0002181.ph@mail.clara.net \
--to=ph@clara.net \
--cc=Linux-MM@kvack.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.