On Thu, 10 Jul 2014 03:53:43 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > Unfortunately there are a few (fairly trivial) merge conflicts later in > > the series due to this change. Bruce, do you want me to repost the > > whole set, or would you rather just cherry-pick them from my updated > > branch? > > Can you resend just the whole fi_fds and access/deny mode patches as a > series for the next step? This seems useful and complicated enough to > do a standalone review. I also don't think the additional few spinlocks > would have enough performance impact to avoid them until the big client > lock is gone, although all those logic changes could probably be done > easily enough without the new locking if someone cared enough (I don't). > Yes, that sounds reasonable. I'll go ahead and move the patches necessary for it to the front of the series and address your comments and we can see about getting them merged ahead of the rest. I agree that the extra spinlocking probably won't matter while the client_mutex is in play. If it does, then not needing to walk the whole stateids list in order to do deny mode enforcement may help make up for it. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
