On 9/14/06, Jiri Kosina <[email protected]> wrote:
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 think it is - as far as I understand the reason for not tracking
every lock individually is just that it is too expensive to do by
default.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
