Messages in this thread | | | Date | Wed, 3 Nov 1999 08:26:10 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [patch] bigmem fix for random out of memory (for 2.3.25) |
| |
On Wed, 3 Nov 1999, Andrea Arcangeli wrote: > > Leonard spotted a bug in the bigmem initialization code. I couldn't debug > it as it can't trigger with the bigmem emulation. > > Actually GFP will return NULL if RMQUEUE grabbed the physical page at > address -PAGE_OFFSET. Lenonard fixed this to just avoid to put the > bigmem in the freelist and I would do the same too as one page is not a > big deal with real bigmem hardware.
Hmm.. This is really still not enough.
What about machines with more than 4GB of physical memory?
The fact is, that if you use GFP_BIGMEM, you really should use the __get_pages() function, instead of using any function that returns a virtual address. And __get_pages() will correctly return a "struct page *", which doesn't have any of these wrap-around issues..
(or you can use the "get_free_highpage()" function that is just a wrapper around __get_pages() to get a single page).
> I merged his plain fix in my 2.2.13 bigmem and I reworked it for 2.3.25.
It's needed in the original bigmem set, but as far as I can tell, for the extended bigmem (ie "highmem") that we use in the current 2.3.x, this isn't even an issue any more..
> The other cleaner way to fix this bug is to change GFP to return a `struct > page *' or the `pfn' and the other way is definitely not a one-liner ;).
Well, the "other way" is what 2.3.x does already..
I certainly agree that it was more than a one-liner change to do the "bigmem" to "highmem" conversion, and I hated doing it this late in the 2.3.x game, but exactly because of these kinds of issues it was also obviously the right thing to do - we're going to have to live with high memory for the 2.4.x lifetime, and I wanted it to be done right..
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |