On Wed, Feb 22, 2006 at 02:09:09PM +1100, Nick Piggin wrote:
I mean a new core mm lock depenency (ie. lru_lock -> tree_lock).
But I must have been smoking something last night: for the life
of me I can't see why I thought there was already a hugetlb_lock
-> lru_lock dependency in there...?!
So I retract my statement. What you have there seems OK.
Sadly, you weren't smoking something, and it's not OK. As akpm
pointed out later, the lru_lock dependecy is via __free_pages() which
is called from update_and_free_page() with hugetlb_lock held.
Also, any thoughts on whether I need i_lock or i_mutex or something
else would be handy..
I'm not much of an fs guy. How come you don't use i_size?
i_size is already used for a hard limit on the file size - faulting a
page beyond i_size will SIGBUS, whereas faulting a page beyond
i_blocks just isn't guaranteed. In particular, we always extend
i_size when makiing a new mapping, whereas we only extend i_blocks
(and thus reserve pages) on a SHARED mapping (because space is being
guaranteed for things in the mapping, not for a random processes
MAP_PRIVATE copy).