> 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