On Mon, 20 Jan 2014, Oleg Nesterov wrote: > On 01/17, Alan Stern wrote: > > > > On Fri, 17 Jan 2014, Oleg Nesterov wrote: > > > > > Yes, sure. This change assumes that the only problem in drivers/base is > > > dev->parent->mutex / dev->mutex dependency. If the locking is even more > > > "broken" (wrt lockdep), we can't replace lockdep_set_novalidate_class() > > > with lockdep_set_auto_nested(). > > > > I suspect it is even more "broken". But I can't point to specific > > examples. > > > > ... > > > > My guess is that if your change is deployed widely, there will be > > reports of violations. That's only a guess. > > OK, lets (try to) do this later. Let me send the changes which I hope > should be fine in any case. > > > Still, you could go ahead and try it, just to see what happens. > > Yes, perhaps it makes sense at least to test this change and see what > happens... We will see. > > > Also, take a look at commit 356c05d58af0. It's a similar situation > > (not exactly the same). > > At first glance, can't __ATTR_IGNORE_LOCKDEP() use no_validate too ? > (ignoring the fact checkpatch.pl won't be happy). This can simplify > the code, it seems.
Well, the macro itself doesn't specify the lockdep class. That happens implicitly in sysfs_get_active(), in the call to rwsem_acquire_read(). However, it ought to be possible to change the code so that when ignore_lockdep(sd) returns nonzero, we end up using no_validate. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
