Messages in this thread |  | | Date | Thu, 16 Jan 2014 19:09:44 +0100 | From | Peter Zijlstra <> | Subject | Re: check && lockdep_no_validate (Was: lockdep: Introduce wait-type checks) |
| |
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 ;-)
|  |