On Thu, 30 Oct 2008 12:51:03 -0500 "Steve French" <smfrench@xxxxxxxxx> wrote: > On Thu, Oct 30, 2008 at 12:42 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > I think we want to resist having locks that protect too many things. > > With that, we end up with the locks held over too much code. Not only is > > that generally worse for performance, but it can paper over race > > conditions. > > I agree that it is trivially worse for performance to have a single > spinlock protecting the three interrelated structures (cifs tcp, smb > and tree connection structs), but since they point to one another and > frequently have operations that require us to use all three lists - > to do things like iterate through all tree connections within a > particular smb session, or iterate across all cifs smb sessions within > each cifs tcp session - it makes code more complicated to have to grab > and unlock multiple spinlocks in the correct order every time across > all exit paths etc. > A fair point, but most of that is in rarely-traveled procfile code. One thing we could consider is some helper macros or functions. For instance, a for_all_tcons() function or something that would take a pointer to a function that takes a tcon arg. It would basically just walk over all the tcons and handle the locking correctly and call the function for each. In any case, I don't see the benefit of not using fine grained locking here. deadlock is a possibility, but I think having well-defined locking rules mitigates that danger. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
