Messages in this thread | | | Date | Mon, 23 Mar 1998 13:38:11 -0500 (EST) | From | "Benjamin C.R. LaHaise" <> | Subject | Re: Some bugs in swap_state.c |
| |
On Mon, 23 Mar 1998, Chirayu Patel wrote:
> This function will concern only the swap cache pages. and if you see the > code...free_page(addr) is free_pages (addr, 0) which eventually does a > free_pages_ok(map_nr, 0) call the same as done in __free_pages.
Yeap, but swap cache pages *are* in the page cache now.
> I found that the free_pages is quite tolerant and will ignore calls to > free an already freed. But I need confirmation on this......
Perhaps, but it certainly isn't a valid assumption for any code to make. Just change __free_page/free_pages to do something like:
if (!PageReserved(page) && (atomic_read(&page->count) < 0)) panic("tried to free free page!\n");
Although doing a *(char *)0 = 0; would be more useful. (Alas, there isn't a portable way of triggering an Oops w/backtrace yet.)
> > > 3. I have removed a trivial check from the function lookup_swap_cache as > > > it seems to be unnecessary after the call to find_page. > > ... > > It is a debugging/stanity check item -> without the comparison of > > page->inode against &swapper_inode, the check is not so useful. > > So, when are this debugging checks suppossed to be removed? :-)
Probably after the code is considered stable -- the page cache based swap cache is very new code. Perhaps some of the mm sanity checks should be wrapped with a macro so that they can be easily turned off, although this may not be a good idea as many of the single-bit memory corruption errors that people have reported were only diagnosed because of the sanity checks. There is still a fair amount of work to go into the mm system before 2.2 to resolve the fragmentation problem...
-ben
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |