On Fri, Oct 22, 2010 at 03:46:57PM +1100, Nick Piggin wrote: > The difficulty with inode_lock breaking is not the data structures. > We know how to lock and modify them. The hardest part is verifying > that a particular inode has no new, unhandled concurrency introduced > to it (eg. the particular concurrency you pointed out in Dave's patch > just now). Agree? > > So in that case, I think it is much more natural to be able to take > an inode and with i_lock, cover it from all icache state concurrency. > I object to it being called over engineering -- it's actually just a > big hammer on the inode, compared with fiddling with more complex > rules. And yes, being a big hammer, it is actually ugly and clunky for the first pass. The intention is always that we can start steps to streamline it now. I had been looking at switching lock orders around, reducing i_lock coverage etc, but I found that with RCU, things got a lot cleaner without reducing i_lock coverage. With RCU the important part of the locking shifts back, from the read side, to the write side. Not surprisingly, this made my lock more natural, wheras it does nothing for a lock ordering which is the other way around. And I think you give too little credit to i_lock being used to protect all i_state. Sure it's not strictly needed, and we could start breaking bits and pieces. But it works really nicely, and is maintainable and easier to convince yourself of correctness. Have an inode? Want to do something to it? Take i_lock. You're done. We don't _need_ to ever think about concurrent modifications. Really, this is the "big dumb" approach IMO. Breaking things out finer than per-inode basis is premature optimisation at this point. Note that my series never precluded such incremental changes, in fact it makes them easier. -- 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
