Hi all,
In 2.4.20's __free_pages_ok function while joining buddies together, we free buddy1 from whatever list of which it's a member:
list_del(&buddy1->list);
Why we don't free buddy2 from its list as well? In half the cases buddy2 is added to the free area list, but in some cases it doesn't seem like we're doing any list clean up.
As an example, imagine that we're freeing an order three page. One page has PFN 64 and the other is PFN 72.
Case 1: "page" is PFN 64. "buddy1" is thus PFN 72 and "buddy2" is PFN 64. In the while loop we immediately remove PFN 72 (AKA "buddy1") from its list but leave PFN 64 on its list. But in this case it's cool because PFN 64 is added to the free list for order four pages after the loop exits.
Case 2: "page" is PFN 72. "buddy1" is thus PFN 64 and "buddy2" is PFN 72. In the while loop we immediately remove PFN 64 (AKA "buddy1") from its list but leave PFN 72 on its list (if any?). PFN 64 is added to the free list for order four pages after the loop exits. However, we didn't free the list of which PFN 72 may be a part at all. Isn't it possibly still on some list which could cause problems? Or is there some precondition in some other part of the codebase that ensures this isn't true (or isn't a problem)?
Thanks,
Kirk
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
