On Wed, Nov 08, 2017 at 04:42:14PM -0500, Andrew W Elble wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > > > On Tue, Nov 07, 2017 at 07:57:26PM -0500, Andrew Elble wrote: > >> The use of the st_mutex has been confusing the validator. Use the > >> proper nested notation so as to not produce warnings. > > > > Looking around, the usual pattern for simple nesting seems to be to use > > just mutex_lock() for the outer lock (equivalent to > > mutex_lock_nested(0)), and mutex_lock_nested(., SINGLE_DEPTH_NESTING) > > for the inner lock. > > > > Or we could define a new LOCK_STATEID_MUTEX, assuming the rule here is > > "lock stateid's are locked after open stateid's". Just a question of > > might be simpler to understand. > > I'm okay with whatever you think is best here - my thought was that the > mutex_lock_nested(0) called more attention to how it was working given > that acquiring that lock class the second time is now a little bit more > hidden in nfsd4_lock_ol_stateid(). I think I'd go for constants like OPEN_STATEID_MUTEX and LOCK_STATEID_MUTEX in that case. Maybe mild overkill, but it should explain what's going on? --b. -- 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
