Both 2.2.x and the new VM (which, through Andrea, has a lot of the same
things) have this notion of a per-process "free pages list" that it
replenished by any freeing that the process does itself when it gets into
the "try_to_free_memory()" path.
The trigger for refilling this list is "current->flags & PF_FREE_PAGES".
The bug is that ytou can be in the middle of adding such a recently free'd
page to the per-process list of free pages, and an interrupt comes in.
The interrupt (or bottom half), in turn, might do something like
page = get_free_page(GFP_ATOMIC);
and now the free_page() inside the interrupt context will _also_ trigger
the PF_FREE_PAGES test, and _also_ add the page to the list. Except, of
course, the list is totally unprotected by any locks, so it may not be
valid at this point.
Fix is to only care about the PF_FREE_PAGES bit when not in an interrupt
Anyway, I seriously doubt this explains any real-world bad behaviour: the
window for the interrupt hitting a half-way updated list is something like
two instructions long out of the whole memory freeing path. AND most
interrupts don't actually do any allocation.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/