Re: [PATCH 0/3] Synaptics - fix lockdep warnings

[Jiri Kosina <jikos@jikos.cz>]

On Thu, 14 Sep 2006, Dmitry Torokhov wrote:

> Well, we do not really care about nestiness do we? What we trying to 
> achieve is to teach lockdep that 2 locks while appear as the lame lock 
> in fact are different and protect 2 different structures. Ideally 
> lockdep should track every lock individually (based for example on its 
> address) but that would be too taxing so we need to help it. In your 
> implementation you embed this data into structure/code using lock, but 
> this information could be instilled into the lock itself upon 
> initialization and spin_[un]lock() implementation could be taught to use 
> this data thus making specialized spin_[un]lock*_nested() functions 
> unnecessary.

Hi Dmitry,

IMHO this is exactly what the nested locking primitives were introduced in 
lockdep for (we even have natural hierarchy here), so I am not sure if 
this is compliant with lockdep design. I definitely could do a patch that 
would introduce {spin,mutex..}_lock_init_subclass(), which would 
initialize the lock together with defining it's 'class', so that it could 
be distinguishable from any other lock of the same type during proving of 
correctness ... but this is a step towards distinguishing every single 
lock from all others (even of a same type), which I am not sure is the 
right direction.

I added Ingo to CC.

Thanks,

-- 
JiKos.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/