On Thu, Jan 16, 2014 at 06:43:48PM +0100, Oleg Nesterov wrote: > But with or without this change the following code > > static DEFINE_MUTEX(m1); > static DEFINE_MUTEX(mx); > > lockdep_set_novalidate_class(&mx); > > // m1 -> mx > mutex_lock(&m1); > mutex_lock(&mx); > mutex_unlock(&mx); > mutex_unlock(&m1); > > // mx -> m1 ; should trigger the warning ??? > mutex_lock(&mx); > mutex_lock(&m1); > mutex_unlock(&m1); > mutex_unlock(&mx); > > doesn't trigger the warning too. This is correct because > lockdep_set_novalidate_class() means, well, no-validate. > The question is: do we really want to avoid all validations?
Good question. > Why lockdep_set_novalidate_class() was added? Unlees I missed > something the problem is that (say) __driver_attach() can take > the "same" lock twice, drivers/base/ lacks annotations. Indeed, the driver model locking always slips my mind but yes its creative. Alan Stern seems to have a good grasp on it though. > Perhaps we should change the meaning of lockdep_set_novalidate_class? > (perhaps with rename). What do you think about the patch below? > > With this patch __lockdep_no_validate__ means "automatically nested", Yes, I suppose that might work, it would allow some validation. > although I have to remind I can hardly understand the code I am > trying to change ;) You don't seem to be doing too badly ;-) -- 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/
