RE: hugetlb page patch for 2.5.48-bug fixes

["Seth, Rohit" <rohit.seth@intel.com>]

Thanks Bill for your comments. 

> Okay, first off why are you using a list linked through page->private?
> page->list is fully available for such tasks.

Don't really need a list_head kind of thing for always inorder complete
traversal. list_head (slightly) adds fat in data structures as well as
insertaion/removal. Please le me know if anything that prohibits the use of
page_private field for internal use.
> 
> Second, the if (key == NULL) check in hugetlb_release_key() 
> is bogus; someone is forgetting to check for NULL, probably 
> in alloc_shared_hugetlb_pages().
> 
This if condition will be removed.  It does not serve any purpose.  As there
is no way to release_key without a valid key.

> Third, the hugetlb_release_key() in unmap_hugepage_range() is 
> the one that should be removed [along with its corresponding 
> mark_key_busy()], not the one in sys_free_hugepages(). 
> unmap_hugepage_range() is doing neither setup nor teardown of 
> the key itself, only the pages and PTE's. I would say 
> key-level refcounting belongs to sys_free_hugepages().
> 
> Bill
> 
It is not mandatory that user app calls free_pages.  Or even in case of app
aborts this call will not be made.  The internal structures are always
released during the exit (with last ref count) along with free of underlying
physical pages.  

rohit
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/