* Duncan Sands <[email protected]> wrote:
> > this patch-queue converts 66% of all semaphore users in 2.6.15-git9 to
> > mutexes.
>
> Hi Ingo, the changes to drivers/usb/atm/usbatm.[ch] conflict with a
> bunch of patches I just sent to Greg KH. How do you plan to handle
> this kind of thing? If you like, I can tweak this part of your patch
> so it applies on top of mine, and push it to Greg.
yeah, the best solution from our POV is if you pick it up and send it to
Greg on your own schedule. We'll probably still carry all the patches in
our tree up until your changes upstream, because it's hard to keep track
of who does what, and we try to cover all the conversions. In general,
the faster this phase is over, the better.
we expect there to be two types of bugs introduced by these patches:
- build error - if we forgot to add mutex.h somewhere.
We think we covered most of the build issues via allyesconfig QA, but
it's possible in theory under some .config's.
- we misidentified a semaphore and converted it to mutexes, albeit the
use was not purely mutex.
all such misidentifications should trigger runtime warnings if
CONFIG_DEBUG_MUTEXES is turned on. If this happens, then one of the
following 3 scenarios should trigger:
- it should stay a semaphore (if it's a genuine counting
semaphore)
- or it should get converted to a completion (if it's used as
a completion)
- or it should get converted to struct work (if it's used as a
workflow synchronizer).
we _think_ we've identified all the converted semaphores correctly
(and we have source-code-analyzing tools to underline that belief,
plus we have a track record in -rt, which runs with all these
semaphores converted to mutexes, plus we have done our own QA), but
at 500+ files changed, it would be quite over-confident to claim that
the patch is 100% perfect :-)
another thing raises the confidence in the analysis: none of the
runtime mutex checks ever triggered during the development of this
conversion patchset. We did find a handful of bugs in drivers, but
they were all caught at the source/analysis level. We occasionally
forgot to convert some affected .c or .h modules, which errors were
caught at the build stage.
famous last words? :-)
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]
