Re: [patch 00/62] sem2mutex: -V1

[Ingo Molnar]

* Duncan Sands <baldrick@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/