* NeilBrown <[email protected]> wrote:
> Following 4 patches address issues with lockdep, particularly around
> bd_mutex.
>
> They are against 2.6.18-mm3 and do *not* apply against -linus as -mm
> already has some changes to the handling of bd_mutex nesting. 2-4
> probably apply on top of -linus plus
> -mm/broken-out/remove-the-old-bd_mutex-lockdep-annotation.patch
>
> I believe they are probably ok for 2.6.19.
agreed.
they look quite nice in that they also simplify the underlying locking.
(instead of just trying to clone whatever locking yuckiness there is,
into the lockdep space.)
> The last fixes a tangentially related lockdep problem in md - there is
> a false relationship between bd_mutex and md->reconfig_mutex which
> needs to be clarified.
> md_open takes ->reconfig_mutex which causes lockdep to complain. This
> (normally) doesn't have deadlock potential as the possible conflict is
> with a reconfig_mutex in a different device.
>
> I say "normally" because if a loop were created in the array->member
> hierarchy a deadlock could happen. However that causes bigger
> problems than a deadlock and should be fixed independently.
ok to me. Sidenote: shouldnt we algorithmically forbid that "loop"
scenario from occuring, as that possibility is what causes lockdep to
complain about the worst-case scenario?
Ingo
-
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]