On Wed, Aug 16, 2017 at 04:14:21PM +0900, Byungchul Park wrote: > On Wed, Aug 16, 2017 at 01:58:08PM +0800, Boqun Feng wrote: > > > I'm not sure this caused the lockdep warning but, if they belongs to the > > > same class even though they couldn't be the same instance as you said, I > > > also think that is another problem and should be fixed. > > > > > > > My point was more like this is a false positive case, which we should > > avoid as hard as we can, because this very case doesn't look like a > > deadlock to me. > > > > Maybe the pattern above does exist in current kernel, but we need to > > guide/adjust lockdep to find the real case showing it's happening. > > As long as they are initialized as a same class, there's no way to > distinguish between them within lockdep. > > And I also think we should avoid false positive cases. Do you think > there are many places where completions are initialized in a same place > even though they could never be the same instance? > > If no, it would be better to fix it whenever we face it, as you did. BTW, of course, the same problem would have occured when applying lockdep for the first time. How did you solve it? I mean that lockdep basically identifies classes even for typical locks with the call site. So two locks could be the same class even though they should not be the same. Of course, for now, we avoid the problemaic cases with sub-class. Anyway, the problems certainly would have arised for the first time. I want to follow that solution you did. Thanks, Byungchul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
