On Thu, Jul 01, 2010 at 05:54:26PM +1000, Nick Piggin wrote: > On Thu, Jul 01, 2010 at 12:36:18PM +1000, Dave Chinner wrote: > If there is a > difficulty with locking pops up in future, I'd prefer to look at it > then. > > I don't think any filesystems cared at all when I converted them. What I mean by this is that _today_ no filesystems seemed to have any problems with how I did it. I did touch quota and notify code, which iterates inode sb lists, but it was pretty trivial. Not many others are about inode locking details enough to care about any of the locks in fs/inode.c. And so instead of adding another lock now when I already have a (IMO) nice and working code, I will prefer to wait until some fs development runs into problem with locking. There are several things that can be done. Using RCU for more of the inode lists is a possibility, and can improve lock order problems while actually reducing the amount of locking rather than adding locks. -- 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
