On Fri, 8 Dec 2017, Byungchul Park wrote: > I'm sorry to hear that.. If I were you, I would also get > annoyed. And.. thanks for explanation. > > But, I think assigning lock classes properly and checking > relationship of the classes to detect deadlocks is reasonable. > > In my opinion about the common lockdep stuff, there are 2 > problems on it. > > 1) Firstly, it's hard to assign lock classes *properly*. By > default, it relies on the caller site of lockdep_init_map(), > but we need to assign another class manually, where ordering > rules are complicated so cannot rely on the caller site. That > *only* can be done by experts of the subsystem. > > I think if they want to get benifit from lockdep, they have no > choice but to assign classes manually with the domain knowledge, > or use *lockdep_set_novalidate_class()* to invalidate locks > making the developers annoyed and not want to use the checking > for them. Lockdep's no_validate class is used when the locking patterns are too complicated for lockdep to understand. Basically, it tells lockdep to ignore those locks. The device core uses that class. The tree of struct devices, each with its own lock, gets used in many different and complicated ways. Lockdep can't understand this -- it doesn't have the ability to represent an arbitrarily deep hierarchical tree of locks -- so we tell it to ignore the device locks. It sounds like XFS may need to do the same thing with its semaphores. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
