On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote: > > locking rule here is that we always lock pages in index increasing order. I > > don't think lockdep will be able to handle something like that. Probably we > > can just avoid lockdep checking in these functions (or just acquire the > > page lock class for the first page) but definitely there will be some > > You are right, I don't think lockdep would work with that, so just > checking the lock for the first page should be better than nothing. > It might require some lockdep support in order to add context so it > doesn't go mad when unlock_page is called (would rather not add any > page flags to track that). > > If we were really clever and able to get back to the address of > struct page that _is_ holding the lock, we could just do a simple > check to ensure its index is < the index of the page we are trying > to take. > > That would give reasonable nesting checking without requiring lockdep > to track new chains for every page (obviously not feasible). Right, so lockdep does indeed not fancy such recursion things. Since the page frames are static you could basically make each lock its own class, but that will run lockdep out of chain storage real quick. Another thing you can do is look at spin_lock_nest_lock() which basically refcounts the class, you could do something like that for the page frame class, where you teach lockdep about the index rule. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
