* [patch 00/62] sem2mutex: -V1
@ 2006-01-13 12:44 Ingo Molnar
2006-01-13 12:59 ` Duncan Sands
2006-01-13 13:23 ` Ingo Molnar
0 siblings, 2 replies; 16+ messages in thread
From: Ingo Molnar @ 2006-01-13 12:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Arjan van de Ven, Jes Sorensen, linux-kernel
this patch-queue converts 66% of all semaphore users in 2.6.15-git9 to
mutexes.
The conversion was done by Arjan van de Ven, Jes Sorensen and myself,
via automatic tools, and the result was verified automatically as well.
Only minimal manual editing was done. We only converted semaphores that
are used as mutexes. The known "is not a mutex" list of semaphores
collected in the -rt tree in past year was automatically added to the
do-not-convert list as well. We also reviewed the resulting changes
manually, and did testbuilds and test-boots.
the GIT tree can be pulled from:
master.kernel.org/pub/scm/linux/kernel/git/mingo/mutex-2.6.git/
or:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/mingo/mutex-2.6.git/
(once master has resynced)
the patch-queue can also be downloaded from:
http://redhat.com/~mingo/generic-mutex-subsystem/
and a 'combo' patch is at:
http://redhat.com/~mingo/generic-mutex-subsystem/combo.patch
which is useful to people who'd like to test the whole patchqueue at
once.
the patch-queue has been build-tested with allyesconfig, and booted on 4
separate x86 systems.
Ingo
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 12:44 [patch 00/62] sem2mutex: -V1 Ingo Molnar
@ 2006-01-13 12:59 ` Duncan Sands
2006-01-13 13:06 ` Arjan van de Ven
2006-01-13 13:44 ` Ingo Molnar
2006-01-13 13:23 ` Ingo Molnar
1 sibling, 2 replies; 16+ messages in thread
From: Duncan Sands @ 2006-01-13 12:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Linus Torvalds, Arjan van de Ven, Jes Sorensen,
linux-kernel, Greg KH
> 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.
Best wishes,
Duncan.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 12:59 ` Duncan Sands
@ 2006-01-13 13:06 ` Arjan van de Ven
2006-01-13 13:44 ` Ingo Molnar
1 sibling, 0 replies; 16+ messages in thread
From: Arjan van de Ven @ 2006-01-13 13:06 UTC (permalink / raw)
To: Duncan Sands
Cc: Ingo Molnar, Andrew Morton, Linus Torvalds, Jes Sorensen,
linux-kernel, Greg KH
On Fri, 2006-01-13 at 13:59 +0100, Duncan Sands 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.
ideally you merge the patch into your queue and send it (via gregkh) on
its way to the final kernel.org merge.
This queue isn't meant to be "this is all going direct to linus
bypassing everyone"; we're trying to get as much as possible sent via
the maintainers. So if you as maintainer want to pick up a patch, we're
very happy about that!
Greetings,
Arjan van de Ven
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 12:59 ` Duncan Sands
2006-01-13 13:06 ` Arjan van de Ven
@ 2006-01-13 13:44 ` Ingo Molnar
2006-01-13 18:25 ` Ingo Oeser
1 sibling, 1 reply; 16+ messages in thread
From: Ingo Molnar @ 2006-01-13 13:44 UTC (permalink / raw)
To: Duncan Sands
Cc: Andrew Morton, Linus Torvalds, Arjan van de Ven, Jes Sorensen,
linux-kernel, Greg KH
* Duncan Sands <baldrick@free.fr> 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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 13:44 ` Ingo Molnar
@ 2006-01-13 18:25 ` Ingo Oeser
2006-01-13 19:56 ` Ingo Molnar
0 siblings, 1 reply; 16+ messages in thread
From: Ingo Oeser @ 2006-01-13 18:25 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Andrew Morton, Linus Torvalds, Arjan van de Ven,
Jes Sorensen, Greg KH
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
Hi there,
On Friday 13 January 2006 14:44, Ingo Molnar wrote:
> - 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).
Could we get for each of these and a mutex:
- description
- common use case
- small argument why this and nothing else should be used there
This would help driver writers a lot deciding what to use when, I think.
PS: After reading the Linux Kernel one could write a PhD thesis
just containing explanations, examples and measurements
of sychronization primitives, since Linux implements at least
most of them AFAIK :-)
Thanks & Regards
Ingo Oeser
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 18:25 ` Ingo Oeser
@ 2006-01-13 19:56 ` Ingo Molnar
2006-01-13 21:04 ` Matan Peled
2006-01-14 13:16 ` Ingo Oeser
0 siblings, 2 replies; 16+ messages in thread
From: Ingo Molnar @ 2006-01-13 19:56 UTC (permalink / raw)
To: Ingo Oeser
Cc: linux-kernel, Andrew Morton, Linus Torvalds, Arjan van de Ven,
Jes Sorensen, Greg KH
* Ingo Oeser <ioe-lkml@rameria.de> wrote:
> Hi there,
>
> On Friday 13 January 2006 14:44, Ingo Molnar wrote:
> > - 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).
>
> Could we get for each of these and a mutex:
>
> - description
> - common use case
> - small argument why this and nothing else should be used there
like ... Documentation/mutex-design.txt?
Ingo
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 19:56 ` Ingo Molnar
@ 2006-01-13 21:04 ` Matan Peled
2006-01-13 21:25 ` Arjan van de Ven
2006-01-14 13:22 ` Ingo Oeser
2006-01-14 13:16 ` Ingo Oeser
1 sibling, 2 replies; 16+ messages in thread
From: Matan Peled @ 2006-01-13 21:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ingo Oeser, linux-kernel, Andrew Morton, Linus Torvalds,
Arjan van de Ven, Jes Sorensen, Greg KH
Ingo Molnar wrote:
> Ingo Oeser wrote:
>> Could we get for each of these and a mutex:
>>
>> - description
>> - common use case
>> - small argument why this and nothing else should be used there
>
> like ... Documentation/mutex-design.txt?
I think what he wanted was an explanation for the change of each and every
sem... Which is kind of hard with automated tools.
--
[Name ] :: [Matan I. Peled ]
[Location ] :: [Israel ]
[Public Key] :: [0xD6F42CA5 ]
[Keyserver ] :: [keyserver.kjsl.com]
encrypted/signed plain text preferred
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 21:04 ` Matan Peled
@ 2006-01-13 21:25 ` Arjan van de Ven
2006-01-13 22:09 ` Junio C Hamano
2006-01-14 13:22 ` Ingo Oeser
1 sibling, 1 reply; 16+ messages in thread
From: Arjan van de Ven @ 2006-01-13 21:25 UTC (permalink / raw)
To: chaosite
Cc: Ingo Molnar, Ingo Oeser, linux-kernel, Andrew Morton,
Linus Torvalds, Jes Sorensen, Greg KH
On Fri, 2006-01-13 at 23:04 +0200, Matan Peled wrote:
> Ingo Molnar wrote:
> > Ingo Oeser wrote:
> >> Could we get for each of these and a mutex:
> >>
> >> - description
> >> - common use case
> >> - small argument why this and nothing else should be used there
> >
> > like ... Documentation/mutex-design.txt?
>
> I think what he wanted was an explanation for the change of each and every
> sem... Which is kind of hard with automated tools.
`
it's also HIGHLY repetitive.
1) The process is : Look at semaphore and it's uses.
2) Decide it's a mutex
3) Run script to convert to mutex
4) Run script to validate the conversion
5) build+boot test
I can't think of a way to describe that uniquely different for each
one ;0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 21:25 ` Arjan van de Ven
@ 2006-01-13 22:09 ` Junio C Hamano
2006-01-13 22:13 ` Arjan van de Ven
0 siblings, 1 reply; 16+ messages in thread
From: Junio C Hamano @ 2006-01-13 22:09 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Ingo Molnar, Ingo Oeser, linux-kernel, Andrew Morton,
Linus Torvalds, Jes Sorensen, Greg KH, chaosite
Arjan van de Ven <arjan@infradead.org> writes:
> On Fri, 2006-01-13 at 23:04 +0200, Matan Peled wrote:
>> Ingo Molnar wrote:
>> > Ingo Oeser wrote:
>> >> Could we get for each of these and a mutex:
>> >>
>> >> - description
>> >> - common use case
>> >> - small argument why this and nothing else should be used there
>> >
>> > like ... Documentation/mutex-design.txt?
>>
>> I think what he wanted was an explanation for the change of each and every
>> sem... Which is kind of hard with automated tools.
> `
> it's also HIGHLY repetitive.
> 1) The process is : Look at semaphore and it's uses.
> 2) Decide it's a mutex
> 3) Run script to convert to mutex
> 4) Run script to validate the conversion
> 5) build+boot test
>
> I can't think of a way to describe that uniquely different for each
> one ;0
I do not read Ingo Oeser's request as such, but if somebody does
1) and 2), ideally, the knowledge obtained during that process,
i.e. what is being protected and what the invariants are, and
the reasoning why it is a mutex, could serve as a good
documentation for people who want to further work on that code
being converted to use mutex.
However, I think demanding Ingo (Molnar) to do all that is
unfair.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 22:09 ` Junio C Hamano
@ 2006-01-13 22:13 ` Arjan van de Ven
0 siblings, 0 replies; 16+ messages in thread
From: Arjan van de Ven @ 2006-01-13 22:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ingo Molnar, Ingo Oeser, linux-kernel, Andrew Morton,
Linus Torvalds, Jes Sorensen, Greg KH, chaosite
On Fri, 2006-01-13 at 14:09 -0800, Junio C Hamano wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
>
> > On Fri, 2006-01-13 at 23:04 +0200, Matan Peled wrote:
> >> Ingo Molnar wrote:
> >> > Ingo Oeser wrote:
> >> >> Could we get for each of these and a mutex:
> >> >>
> >> >> - description
> >> >> - common use case
> >> >> - small argument why this and nothing else should be used there
> >> >
> >> > like ... Documentation/mutex-design.txt?
> >>
> >> I think what he wanted was an explanation for the change of each and every
> >> sem... Which is kind of hard with automated tools.
> > `
> > it's also HIGHLY repetitive.
> > 1) The process is : Look at semaphore and it's uses.
> > 2) Decide it's a mutex
> > 3) Run script to convert to mutex
> > 4) Run script to validate the conversion
> > 5) build+boot test
> >
> > I can't think of a way to describe that uniquely different for each
> > one ;0
>
> I do not read Ingo Oeser's request as such, but if somebody does
> 1) and 2), ideally, the knowledge obtained during that process,
> i.e. what is being protected and what the invariants are, and
> the reasoning why it is a mutex, could serve as a good
> documentation for people who want to further work on that code
> being converted to use mutex.
Again that is almost a generic answer, the *vast* majority of
mutex-semaphores is used in such a way that the down() and up() are
always in the same function, eg the pattern is
down(semaphore);
do_stuff();
up(semaphore);
all the time. That's then a mutex... and the most basic use pattern.
Sure this isn't always the case but it's very common.
(there have been 2 cases that accidentally did
up(semaphore);
do_stuff();
down(semaphore);
.. which is legal with semaphores but not what was intended ;)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 21:04 ` Matan Peled
2006-01-13 21:25 ` Arjan van de Ven
@ 2006-01-14 13:22 ` Ingo Oeser
2006-01-14 13:49 ` Thomas Gleixner
1 sibling, 1 reply; 16+ messages in thread
From: Ingo Oeser @ 2006-01-14 13:22 UTC (permalink / raw)
To: linux-kernel, chaosite
Cc: Ingo Molnar, Andrew Morton, Linus Torvalds, Arjan van de Ven,
Jes Sorensen, Greg KH
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Friday 13 January 2006 22:04, Matan Peled wrote:
> Ingo Molnar wrote:
> > Ingo Oeser wrote:
> >> Could we get for each of these and a mutex:
> >>
> >> - description
> >> - common use case
> >> - small argument why this and nothing else should be used there
> >
> > like ... Documentation/mutex-design.txt?
>
> I think what he wanted was an explanation for the change of each and every
> sem... Which is kind of hard with automated tools.
No this is too much! I wouldn't expect this.
Just example conversions for each 3 conversion types with full discussion
(or discussion at all) like we do for all other patches would be enough.
semaphore -> mutex is explained a bit in Documentation/mutex-design.txt
Still missing:
- semaphore -> completion
- semaphore -> struct work
Regards
Ingo Oeser
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-14 13:22 ` Ingo Oeser
@ 2006-01-14 13:49 ` Thomas Gleixner
0 siblings, 0 replies; 16+ messages in thread
From: Thomas Gleixner @ 2006-01-14 13:49 UTC (permalink / raw)
To: Ingo Oeser
Cc: linux-kernel, chaosite, Ingo Molnar, Andrew Morton,
Linus Torvalds, Arjan van de Ven, Jes Sorensen, Greg KH
Ingo,
> semaphore -> mutex is explained a bit in Documentation/mutex-design.txt
>
> Still missing:
> - semaphore -> completion
Sempahore to completion is rather simple to explain.
The pattern is mostly like this
threadA
init_MUTEX_LOCKED(&shared_data_struct.mutex);
kick_off_threadB();
down(&shared_data_struct.mutex);
threadB
wait_for_kick_off();
do_some_work();
up(&shared_data_struct.mutex);
The conversion is:
threadA
init_completion(&shared_data_struct.completion);
kick_off_threadB();
wait_for_completion(&shared_data_struct.completion);
threadB
wait_for_kick_off();
do_some_work();
complete(&shared_data_struct.completion);
Note, that a completion is only useful, when there are only two parties
involved. The one which initiates an action and the one which signals
completion of the requested action. The action can be some deferred
workload or synchronization of startup / shutdown of related threads.
Its a synchronization mechanism not a concurrency control in the sense
of data protection across multiple potential users of a data structure.
Real life example:
> --- jffs2_fs_sb.h 28 Feb 2005 08:21:06 -0000 1.51
> +++ jffs2_fs_sb.h 19 May 2005 16:12:17 -0000 1.52
> @@ -32,7 +32,7 @@
> unsigned int flags;
>
> struct task_struct *gc_task; /* GC task struct */
> - struct semaphore gc_thread_start; /* GC thread start mutex */
> + struct completion gc_thread_start; /* GC thread start completion */
> struct completion gc_thread_exit; /* GC thread exit completion port */
>
> struct semaphore alloc_sem; /* Used to protect all the following
>
>
> --- background.c 17 Mar 2005 20:15:58 -0000 1.51
> +++ background.c 19 May 2005 16:18:08 -0000 1.52
> @@ -37,7 +37,7 @@
> if (c->gc_task)
> BUG();
ThreadA
> - init_MUTEX_LOCKED(&c->gc_thread_start);
> + init_completion(&c->gc_thread_start);
> init_completion(&c->gc_thread_exit);
>
> pid = kernel_thread(jffs2_garbage_collect_thread, c, CLONE_FS|CLONE_FILES);
> @@ -48,7 +48,7 @@
> } else {
> /* Wait for it... */
> D1(printk(KERN_DEBUG "JFFS2: Garbage collect thread is pid %d\n", pid));
> - down(&c->gc_thread_start);
> + wait_for_completion(&c->gc_thread_start);
> }
>
> return ret;
> @@ -75,7 +75,7 @@
> allow_signal(SIGCONT);
ThreadB
> c->gc_task = current;
> - up(&c->gc_thread_start);
> + complete(&c->gc_thread_start);
>
> set_user_nice(current, 10);
>
Hope that helps
tglx
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 19:56 ` Ingo Molnar
2006-01-13 21:04 ` Matan Peled
@ 2006-01-14 13:16 ` Ingo Oeser
2006-01-14 13:31 ` Arjan van de Ven
1 sibling, 1 reply; 16+ messages in thread
From: Ingo Oeser @ 2006-01-14 13:16 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Andrew Morton, Linus Torvalds, Arjan van de Ven,
Jes Sorensen, Greg KH
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
On Friday 13 January 2006 20:56, Ingo Molnar wrote:
> * Ingo Oeser <ioe-lkml@rameria.de> wrote:
> > On Friday 13 January 2006 14:44, Ingo Molnar wrote:
> > Could we get for each of these and a mutex:
> >
> > - description
> > - common use case
> > - small argument why this and nothing else should be used there
>
> like ... Documentation/mutex-design.txt?
Much simpler.
Take your favorite conversion and optionally a discussable
conversion. Now describe why mutex/completion/struct work can do
the same and still reach the same level of safety.
Sth. like extending Documentation/DocBook/kernel-locking.tmpl
which still misses completions and struct work queues,
how all works together, possible nesting and so on.
It all boils down to discussion one conversion of each type.
If one could point me to such discussions in the archives
I could write sth. up.
Regards
Ingo Oeser
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-14 13:16 ` Ingo Oeser
@ 2006-01-14 13:31 ` Arjan van de Ven
2006-01-14 13:38 ` Ingo Molnar
0 siblings, 1 reply; 16+ messages in thread
From: Arjan van de Ven @ 2006-01-14 13:31 UTC (permalink / raw)
To: Ingo Oeser
Cc: linux-kernel, Ingo Molnar, Andrew Morton, Linus Torvalds,
Jes Sorensen, Greg KH
On Sat, 2006-01-14 at 14:16 +0100, Ingo Oeser wrote:
> On Friday 13 January 2006 20:56, Ingo Molnar wrote:
> > * Ingo Oeser <ioe-lkml@rameria.de> wrote:
> > > On Friday 13 January 2006 14:44, Ingo Molnar wrote:
> > > Could we get for each of these and a mutex:
> > >
> > > - description
> > > - common use case
> > > - small argument why this and nothing else should be used there
> >
> > like ... Documentation/mutex-design.txt?
>
> Much simpler.
>
> Take your favorite conversion
ok the most simple case is really simple.
ALL uses of it have a down() ..... ip() scenario, where all down's are
matched with up's in the same function, no trylocks in sight.
That case is the simple (and most common) case. Since it uses down()
only, it can't be irq context. (trylock could be a sign of irq context
use), and all up()'s are 1) not in irq context either because they're in
the same function as the down() which isn;t and 2) perfectly matched to
the down(), eg each down gets one up ---> perfect semaphore.
The other case on the other side of the spectrum is a down in one
function and an up in an irq function. Which is a pretty good sign of a
completion.... (same is true for a specific scenario where kernel thread
creation is involved and the up() is done in the just created thread).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-14 13:31 ` Arjan van de Ven
@ 2006-01-14 13:38 ` Ingo Molnar
0 siblings, 0 replies; 16+ messages in thread
From: Ingo Molnar @ 2006-01-14 13:38 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Ingo Oeser, linux-kernel, Andrew Morton, Linus Torvalds,
Jes Sorensen, Greg KH
* Arjan van de Ven <arjan@infradead.org> wrote:
> That case is the simple (and most common) case. Since it uses down()
> only, it can't be irq context. (trylock could be a sign of irq context
> use), and all up()'s are 1) not in irq context either because they're
> in the same function as the down() which isn;t and 2) perfectly
> matched to the down(), eg each down gets one up ---> perfect
> semaphore.
one of the most frequent exceptions to the 'up in a separate function'
rule are seqfile implementations, which all have start(), mid(), stop()
methods, where start() does the down(), stop() does the up(). These can
still be converted to mutexes (and i converted a couple of them), after
manual review.
> The other case on the other side of the spectrum is a down in one
> function and an up in an irq function. Which is a pretty good sign of
> a completion.... (same is true for a specific scenario where kernel
> thread creation is involved and the up() is done in the just created
> thread).
another good sign of completion type of semaphores is the use of
DECLARE_MUTEX_LOCKED(), init_MUTEX_LOCKED(), or sema_init(&sem, 0). In
95% of these cases these signal semaphores used as completions. That is
one reason why i did not add DEFINE_MUTEX_LOCKED(), nor
mutex_init_locked() to the mutex APIs.
the 'struct work' conversion is rare, i've only seen it in XFS so far.
Ingo
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch 00/62] sem2mutex: -V1
2006-01-13 12:44 [patch 00/62] sem2mutex: -V1 Ingo Molnar
2006-01-13 12:59 ` Duncan Sands
@ 2006-01-13 13:23 ` Ingo Molnar
1 sibling, 0 replies; 16+ messages in thread
From: Ingo Molnar @ 2006-01-13 13:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Arjan van de Ven, Jes Sorensen, linux-kernel
* Ingo Molnar <mingo@elte.hu> wrote:
> this patch-queue converts 66% of all semaphore users in 2.6.15-git9 to
> mutexes.
since we are not sending these patches to lkml, here's the diffstat:
518 files changed, 5518 insertions(+), 5183 deletions(-)
arch/arm26/kernel/traps.c | 12 -
arch/i386/kernel/cpu/cpufreq/powernow-k8.c | 9
arch/i386/kernel/cpu/mtrr/main.c | 11
arch/i386/kernel/microcode.c | 7
arch/ia64/hp/sim/simserial.c | 1
arch/ia64/ia32/sys_ia32.c | 28 +-
arch/ia64/kernel/perfmon.c | 11
arch/mips/lasat/sysctl.c | 63 ++---
arch/powerpc/kernel/kprobes.c | 4
arch/powerpc/mm/imalloc.c | 18 -
arch/powerpc/platforms/cell/spu_base.c | 22 -
arch/powerpc/platforms/powermac/cpufreq_64.c | 7
arch/ppc/4xx_io/serial_sicc.c | 3
arch/x86_64/kernel/kprobes.c | 4
block/genhd.c | 25 +-
block/ioctl.c | 22 -
drivers/acpi/processor_perflib.c | 23 +
drivers/acpi/scan.c | 3
drivers/base/attribute_container.c | 27 +-
drivers/base/bus.c | 16 -
drivers/base/class.c | 22 -
drivers/base/core.c | 2
drivers/base/dd.c | 36 +--
drivers/base/dmapool.c | 15 -
drivers/base/firmware_class.c | 21 -
drivers/base/map.c | 20 -
drivers/base/memory.c | 6
drivers/base/power/resume.c | 4
drivers/base/power/suspend.c | 4
drivers/base/sys.c | 23 +
drivers/block/floppy.c | 17 -
drivers/block/loop.c | 18 -
drivers/block/nbd.c | 16 -
drivers/block/pktcdvd.c | 27 +-
drivers/block/rd.c | 4
drivers/cdrom/cdu31a.c | 51 ++--
drivers/char/agp/frontend.c | 28 +-
drivers/char/amiserial.c | 3
drivers/char/drm/drmP.h | 5
drivers/char/drm/drm_auth.c | 20 -
drivers/char/drm/drm_bufs.c | 80 +++---
drivers/char/drm/drm_context.c | 52 ++--
drivers/char/drm/drm_drv.c | 4
drivers/char/drm/drm_fops.c | 12 -
drivers/char/drm/drm_ioctl.c | 18 -
drivers/char/drm/drm_irq.c | 16 -
drivers/char/drm/drm_proc.c | 28 +-
drivers/char/drm/drm_stub.c | 4
drivers/char/drm/drm_vm.c | 12 -
drivers/char/esp.c | 3
drivers/char/generic_serial.c | 4
drivers/char/istallion.c | 3
drivers/char/n_tty.c | 10
drivers/char/nwflash.c | 11
drivers/char/raw.c | 23 +
drivers/char/riscom8.c | 3
drivers/char/specialix.c | 5
drivers/char/stallion.c | 3
drivers/char/synclink.c | 3
drivers/char/tty_io.c | 52 ++--
drivers/char/vt.c | 14 -
drivers/char/watchdog/pcwd_usb.c | 7
drivers/connector/connector.c | 15 -
drivers/cpufreq/cpufreq.c | 19 -
drivers/cpufreq/cpufreq_conservative.c | 52 ++--
drivers/cpufreq/cpufreq_ondemand.c | 41 +--
drivers/cpufreq/cpufreq_userspace.c | 25 +-
drivers/firmware/dcdbas.c | 23 +
drivers/hwmon/adm1021.c | 13 -
drivers/hwmon/adm1025.c | 25 +-
drivers/hwmon/adm1026.c | 87 +++----
drivers/hwmon/adm1031.c | 49 ++--
drivers/hwmon/adm9240.c | 29 +-
drivers/hwmon/asb100.c | 45 +--
drivers/hwmon/atxp1.c | 9
drivers/hwmon/ds1621.c | 13 -
drivers/hwmon/fscher.c | 41 +--
drivers/hwmon/fscpos.c | 29 +-
drivers/hwmon/gl518sm.c | 25 +-
drivers/hwmon/gl520sm.c | 45 +--
drivers/hwmon/hdaps.c | 37 +--
drivers/hwmon/it87.c | 61 ++---
drivers/hwmon/lm63.c | 29 +-
drivers/hwmon/lm75.c | 13 -
drivers/hwmon/lm77.c | 21 -
drivers/hwmon/lm78.c | 47 ++-
drivers/hwmon/lm80.c | 27 +-
drivers/hwmon/lm83.c | 13 -
drivers/hwmon/lm85.c | 67 ++---
drivers/hwmon/lm87.c | 39 +--
drivers/hwmon/lm90.c | 21 -
drivers/hwmon/lm92.c | 17 -
drivers/hwmon/max1619.c | 13 -
drivers/hwmon/pc87360.c | 61 ++---
drivers/hwmon/sis5595.c | 47 ++-
drivers/hwmon/smsc47b397.c | 17 -
drivers/hwmon/smsc47m1.c | 41 +--
drivers/hwmon/via686a.c | 33 +-
drivers/hwmon/vt8231.c | 51 ++--
drivers/hwmon/w83627ehf.c | 33 +-
drivers/hwmon/w83627hf.c | 57 ++--
drivers/hwmon/w83781d.c | 55 ++--
drivers/hwmon/w83792d.c | 9
drivers/hwmon/w83l785ts.c | 9
drivers/i2c/busses/i2c-ali1535.c | 7
drivers/i2c/chips/ds1374.c | 11
drivers/i2c/chips/m41t00.c | 11
drivers/i2c/i2c-core.c | 23 +
drivers/ide/ide-cd.c | 11
drivers/ide/ide-disk.c | 11
drivers/ide/ide-floppy.c | 11
drivers/ide/ide-tape.c | 19 -
drivers/ieee1394/hosts.c | 7
drivers/infiniband/core/device.c | 22 -
drivers/infiniband/core/ucm.c | 23 +
drivers/infiniband/core/uverbs.h | 5
drivers/infiniband/core/uverbs_cmd.c | 150 ++++++------
drivers/infiniband/core/uverbs_main.c | 8
drivers/infiniband/ulp/ipoib/ipoib.h | 6
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 19 -
drivers/infiniband/ulp/ipoib/ipoib_main.c | 12 -
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 27 +-
drivers/infiniband/ulp/ipoib/ipoib_verbs.c | 8
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 10
drivers/input/gameport/gameport.c | 21 -
drivers/input/input.c | 15 -
drivers/input/joystick/amijoy.c | 11
drivers/input/serio/serio.c | 31 +-
drivers/input/serio/serio_raw.c | 23 +
drivers/isdn/capi/kcapi.c | 17 -
drivers/macintosh/smu.c | 9
drivers/md/dm-table.c | 11
drivers/md/dm.c | 19 -
drivers/md/kcopyd.c | 27 +-
drivers/md/md.c | 11
drivers/media/dvb/dvb-core/dvbdev.c | 21 -
drivers/media/video/bttv-driver.c | 60 ++---
drivers/media/video/bttvp.h | 5
drivers/media/video/cx88/cx88-core.c | 15 -
drivers/media/video/em28xx/em28xx-video.c | 7
drivers/media/video/saa7134/saa7134-core.c | 19 -
drivers/media/video/videodev.c | 26 +-
drivers/media/video/zoran.h | 2
drivers/media/video/zoran_card.c | 11
drivers/media/video/zoran_driver.c | 227 +++++++++----------
drivers/mtd/devices/blkmtd.c | 10
drivers/mtd/devices/block2mtd.c | 13 -
drivers/mtd/devices/doc2000.c | 37 +--
drivers/mtd/mtd_blkdevs.c | 32 +-
drivers/mtd/mtdblock.c | 14 -
drivers/mtd/mtdcore.c | 32 +-
drivers/net/8139too.c | 2
drivers/net/cassini.c | 40 +--
drivers/net/cassini.h | 2
drivers/net/irda/irtty-sir.c | 19 -
drivers/net/irda/sir_dongle.c | 19 -
drivers/net/ppp_generic.c | 25 +-
drivers/net/sungem.c | 37 +--
drivers/net/sungem.h | 6
drivers/net/wan/dscc4.c | 7
drivers/net/wireless/ipw2100.c | 119 +++++-----
drivers/net/wireless/ipw2100.h | 4
drivers/net/wireless/ipw2200.c | 294 ++++++++++++-------------
drivers/net/wireless/ipw2200.h | 3
drivers/parport/share.c | 19 -
drivers/pci/hotplug/rpadlpar_core.c | 12 -
drivers/pci/hotplug/sgi_hotplug.c | 19 -
drivers/pcmcia/cs.c | 40 +--
drivers/pcmcia/ds.c | 15 -
drivers/pcmcia/pcmcia_ioctl.c | 12 -
drivers/pcmcia/rsrc_nonstatic.c | 41 +--
drivers/pcmcia/socket_sysfs.c | 8
drivers/pnp/isapnp/core.c | 7
drivers/s390/block/dasd_ioctl.c | 8
drivers/s390/char/raw3270.c | 39 +--
drivers/sbus/char/aurora.c | 3
drivers/scsi/3w-9xxx.c | 7
drivers/scsi/3w-9xxx.h | 2
drivers/scsi/3w-xxxx.c | 7
drivers/scsi/3w-xxxx.h | 2
drivers/scsi/ch.c | 33 +-
drivers/scsi/dpt_i2o.c | 35 +-
drivers/scsi/hosts.c | 8
drivers/scsi/ide-scsi.c | 11
drivers/scsi/iscsi_tcp.c | 37 +--
drivers/scsi/iscsi_tcp.h | 2
drivers/scsi/megaraid.c | 6
drivers/scsi/megaraid.h | 4
drivers/scsi/megaraid/megaraid_sas.c | 7
drivers/scsi/scsi.c | 13 -
drivers/scsi/scsi_proc.c | 11
drivers/scsi/scsi_scan.c | 16 -
drivers/scsi/scsi_sysfs.c | 4
drivers/scsi/scsi_transport_iscsi.c | 17 -
drivers/scsi/scsi_transport_spi.c | 10
drivers/scsi/sd.c | 21 -
drivers/scsi/sr.c | 17 -
drivers/scsi/st.c | 17 -
drivers/serial/pmac_zilog.c | 9
drivers/serial/serial_core.c | 60 ++---
drivers/telephony/phonedev.c | 21 -
drivers/usb/atm/cxacru.c | 9
drivers/usb/atm/ueagle-atm.c | 27 +-
drivers/usb/atm/usbatm.c | 24 +-
drivers/usb/atm/usbatm.h | 3
drivers/usb/class/cdc-acm.c | 19 -
drivers/usb/class/usblp.c | 15 -
drivers/usb/core/devices.c | 7
drivers/usb/core/devio.c | 4
drivers/usb/core/hcd.c | 25 +-
drivers/usb/core/hcd.h | 2
drivers/usb/core/hub.c | 11
drivers/usb/core/notify.c | 15 -
drivers/usb/core/usb.c | 5
drivers/usb/image/mdc800.c | 63 ++---
drivers/usb/input/ati_remote.c | 2
drivers/usb/media/dabusb.c | 31 +-
drivers/usb/media/dabusb.h | 2
drivers/usb/media/ov511.c | 91 +++----
drivers/usb/media/ov511.h | 11
drivers/usb/media/se401.c | 12 -
drivers/usb/media/se401.h | 3
drivers/usb/media/sn9c102.h | 5
drivers/usb/media/sn9c102_core.c | 158 ++++++-------
drivers/usb/media/stv680.c | 13 -
drivers/usb/media/stv680.h | 2
drivers/usb/media/usbvideo.c | 28 +-
drivers/usb/media/usbvideo.h | 5
drivers/usb/media/vicam.c | 21 -
drivers/usb/media/w9968cf.c | 94 +++----
drivers/usb/media/w9968cf.h | 10
drivers/usb/misc/idmouse.c | 25 +-
drivers/usb/misc/ldusb.c | 11
drivers/usb/misc/legousbtower.c | 11
drivers/usb/mon/mon_main.c | 19 -
drivers/usb/mon/mon_text.c | 21 -
drivers/usb/mon/usb_mon.h | 2
drivers/usb/serial/pl2303.c | 2
drivers/usb/storage/scsiglue.c | 9
drivers/usb/storage/usb.c | 25 +-
drivers/usb/storage/usb.h | 5
fs/9p/mux.c | 11
fs/block_dev.c | 28 +-
fs/buffer.c | 6
fs/char_dev.c | 17 -
fs/cifs/dir.c | 8
fs/cifs/fcntl.c | 4
fs/cifs/file.c | 4
fs/cifs/inode.c | 16 -
fs/cifs/link.c | 16 -
fs/cifs/readdir.c | 4
fs/cifs/xattr.c | 16 -
fs/cramfs/inode.c | 31 +-
fs/dcookies.c | 19 -
fs/dquot.c | 124 +++++-----
fs/eventpoll.c | 23 +
fs/ext3/super.c | 4
fs/inode.c | 18 -
fs/inotify.c | 116 ++++-----
fs/jbd/checkpoint.c | 4
fs/jbd/journal.c | 4
fs/jbd/transaction.c | 4
fs/jffs2/compr_zlib.c | 19 -
fs/jfs/jfs_logmgr.c | 27 +-
fs/libfs.c | 14 -
fs/lockd/host.c | 19 -
fs/lockd/svc.c | 17 -
fs/lockd/svcsubs.c | 17 -
fs/namei.c | 12 -
fs/nfs/callback.c | 11
fs/nfsd/nfs4state.c | 9
fs/ocfs2/buffer_head_io.c | 10
fs/ocfs2/inode.c | 4
fs/ocfs2/inode.h | 4
fs/ocfs2/journal.c | 14 -
fs/ocfs2/ocfs2.h | 3
fs/ocfs2/super.c | 8
fs/ocfs2/uptodate.c | 10
fs/partitions/devfs.c | 12 -
fs/quota.c | 6
fs/quota_v2.c | 2
fs/seq_file.c | 10
fs/super.c | 17 -
include/linux/agpgart.h | 3
include/linux/audit.h | 2
include/linux/device.h | 5
include/linux/fs.h | 10
include/linux/input.h | 2
include/linux/jbd.h | 7
include/linux/kobj_map.h | 4
include/linux/kprobes.h | 3
include/linux/loop.h | 3
include/linux/memory.h | 5
include/linux/mtd/blktrans.h | 4
include/linux/mtd/doc2000.h | 4
include/linux/nbd.h | 3
include/linux/quota.h | 7
include/linux/rtnetlink.h | 13 -
include/linux/seq_file.h | 4
include/linux/serial_core.h | 3
include/linux/sunrpc/svcsock.h | 2
include/linux/tty.h | 8
include/linux/usb.h | 6
include/net/af_unix.h | 3
include/net/xfrm.h | 3
include/pcmcia/ss.h | 3
include/scsi/scsi_host.h | 3
include/scsi/scsi_transport_spi.h | 2
include/sound/ac97_codec.h | 4
include/sound/ad1848.h | 2
include/sound/ak4531_codec.h | 2
include/sound/core.h | 8
include/sound/cs4231.h | 4
include/sound/cs46xx.h | 2
include/sound/emu10k1.h | 4
include/sound/emux_synth.h | 2
include/sound/gus.h | 6
include/sound/hwdep.h | 2
include/sound/i2c.h | 10
include/sound/info.h | 2
include/sound/mixer_oss.h | 2
include/sound/opl3.h | 3
include/sound/pcm.h | 2
include/sound/pcm_oss.h | 2
include/sound/rawmidi.h | 4
include/sound/sb16_csp.h | 2
include/sound/seq_instr.h | 2
include/sound/soundfont.h | 2
include/sound/util_mem.h | 4
include/sound/vx_core.h | 2
ipc/compat.c | 2
ipc/mqueue.c | 4
ipc/msg.c | 18 -
ipc/sem.c | 78 +++---
ipc/shm.c | 27 +-
ipc/util.c | 30 +-
ipc/util.h | 4
kernel/audit.c | 6
kernel/auditsc.c | 10
kernel/cpu.c | 10
kernel/cpuset.c | 192 ++++++++--------
kernel/exit.c | 4
kernel/kprobes.c | 14 -
kernel/kthread.c | 7
kernel/module.c | 56 ++--
kernel/posix-timers.c | 1
kernel/power/pm.c | 21 -
kernel/profile.c | 11
kernel/rcupdate.c | 10
kernel/sys.c | 4
lib/reed_solomon/reed_solomon.c | 11
mm/slab.c | 46 +--
mm/swapfile.c | 17 -
net/atm/common.c | 4
net/atm/ioctl.c | 15 -
net/atm/resources.c | 32 +-
net/atm/resources.h | 3
net/bluetooth/rfcomm/core.c | 8
net/bridge/netfilter/ebtables.c | 91 +++----
net/core/dev.c | 7
net/core/flow.c | 7
net/core/pktgen.c | 7
net/core/rtnetlink.c | 8
net/ipv4/ipcomp.c | 17 -
net/ipv4/ipvs/ip_vs_app.c | 19 -
net/ipv4/ipvs/ip_vs_ctl.c | 11
net/ipv4/netfilter/arp_tables.c | 57 ++--
net/ipv4/netfilter/ip_queue.c | 11
net/ipv4/netfilter/ip_tables.c | 79 +++---
net/ipv4/netfilter/ipt_hashlimit.c | 9
net/ipv4/xfrm4_tunnel.c | 11
net/ipv6/ipcomp6.c | 15 -
net/ipv6/netfilter/ip6_queue.c | 11
net/ipv6/netfilter/ip6_tables.c | 79 +++---
net/ipv6/xfrm6_tunnel.c | 11
net/key/af_key.c | 4
net/netfilter/nf_conntrack_core.c | 16 -
net/netfilter/nf_sockopt.c | 25 +-
net/netlink/genetlink.c | 9
net/socket.c | 31 +-
net/sunrpc/cache.c | 17 -
net/sunrpc/sched.c | 11
net/sunrpc/svcsock.c | 8
net/unix/af_unix.c | 22 -
net/unix/garbage.c | 7
net/xfrm/xfrm_policy.c | 4
net/xfrm/xfrm_user.c | 4
security/keys/process_keys.c | 7
security/selinux/selinuxfs.c | 19 -
security/selinux/ss/services.c | 7
sound/arm/aaci.c | 10
sound/arm/aaci.h | 2
sound/arm/pxa2xx-ac97.c | 12 -
sound/core/hwdep.c | 43 +--
sound/core/info.c | 27 +-
sound/core/info_oss.c | 13 -
sound/core/init.c | 2
sound/core/memalloc.c | 22 -
sound/core/oss/mixer_oss.c | 14 -
sound/core/oss/pcm_oss.c | 30 +-
sound/core/pcm.c | 39 +--
sound/core/pcm_native.c | 12 -
sound/core/rawmidi.c | 57 ++--
sound/core/seq/oss/seq_oss.c | 27 +-
sound/core/seq/seq_clientmgr.c | 40 +--
sound/core/seq/seq_clientmgr.h | 2
sound/core/seq/seq_device.c | 53 ++--
sound/core/seq/seq_instr.c | 6
sound/core/seq/seq_midi.c | 20 -
sound/core/seq/seq_ports.c | 12 -
sound/core/seq/seq_queue.c | 6
sound/core/seq/seq_queue.h | 2
sound/core/sound.c | 23 +
sound/core/sound_oss.c | 23 +
sound/core/timer.c | 77 +++---
sound/drivers/opl3/opl3_lib.c | 2
sound/drivers/opl3/opl3_seq.c | 10
sound/drivers/opl3/opl3_synth.c | 10
sound/drivers/opl4/opl4_lib.c | 2
sound/drivers/opl4/opl4_local.h | 2
sound/drivers/opl4/opl4_proc.c | 10
sound/drivers/opl4/opl4_seq.c | 12 -
sound/drivers/vx/vx_core.c | 2
sound/drivers/vx/vx_mixer.c | 72 +++---
sound/i2c/i2c.c | 2
sound/isa/ad1848/ad1848_lib.c | 14 -
sound/isa/cs423x/cs4231_lib.c | 30 +-
sound/isa/cs423x/cs4236_lib.c | 4
sound/isa/gus/gus_dma.c | 10
sound/isa/gus/gus_main.c | 2
sound/isa/gus/gus_mem.c | 14 -
sound/isa/gus/gus_synth.c | 14 -
sound/isa/sb/sb16_csp.c | 12 -
sound/oss/ac97_codec.c | 24 +-
sound/oss/aci.c | 11
sound/oss/ad1889.c | 7
sound/oss/ad1889.h | 2
sound/oss/ali5455.c | 8
sound/oss/au1000.c | 44 +--
sound/oss/au1550_ac97.c | 44 +--
sound/oss/btaudio.c | 36 +--
sound/oss/cmpci.c | 20 -
sound/oss/cs4281/cs4281m.c | 54 ++--
sound/oss/cs46xx.c | 75 +++---
sound/oss/dmasound/dmasound_awacs.c | 10
sound/oss/emu10k1/hwaccess.h | 2
sound/oss/emu10k1/main.c | 2
sound/oss/emu10k1/midi.c | 14 -
sound/oss/es1370.c | 71 +++---
sound/oss/es1371.c | 71 +++---
sound/oss/esssolo1.c | 50 ++--
sound/oss/forte.c | 11
sound/oss/hal2.c | 22 +
sound/oss/i810_audio.c | 8
sound/oss/ite8172.c | 20 -
sound/oss/maestro.c | 26 +-
sound/oss/maestro3.c | 20 -
sound/oss/nec_vrc5477.c | 20 -
sound/oss/rme96xx.c | 17 -
sound/oss/sonicvibes.c | 48 ++--
sound/oss/swarm_cs4297a.c | 39 +--
sound/oss/trident.c | 62 ++---
sound/oss/via82cxxx_audio.c | 49 ++--
sound/oss/vwsnd.c | 61 ++---
sound/oss/ymfpci.c | 14 -
sound/oss/ymfpci.h | 3
sound/pci/ac97/ac97_codec.c | 45 +--
sound/pci/ac97/ac97_patch.c | 10
sound/pci/ac97/ac97_pcm.c | 6
sound/pci/ac97/ac97_proc.c | 14 -
sound/pci/ac97/ak4531_codec.c | 28 +-
sound/pci/atiixp.c | 21 -
sound/pci/atiixp_modem.c | 13 -
sound/pci/cmipci.c | 25 +-
sound/pci/cs46xx/cs46xx_lib.c | 52 ++--
sound/pci/cs46xx/dsp_spos.c | 58 ++--
sound/pci/cs46xx/dsp_spos_scb_lib.c | 6
sound/pci/emu10k1/emu10k1_main.c | 5
sound/pci/emu10k1/emufx.c | 22 +
sound/pci/emu10k1/memory.c | 26 +-
sound/pci/ens1370.c | 32 +-
sound/pci/es1968.c | 22 +
sound/pci/hda/hda_codec.c | 51 ++--
sound/pci/hda/hda_codec.h | 4
sound/pci/hda/hda_intel.c | 17 -
sound/pci/hda/patch_analog.c | 28 +-
sound/pci/ice1712/aureon.c | 38 +--
sound/pci/ice1712/delta.c | 26 +-
sound/pci/ice1712/hoontech.c | 26 +-
sound/pci/ice1712/ice1712.c | 7
sound/pci/ice1712/ice1712.h | 10
sound/pci/ice1712/ice1724.c | 37 +--
sound/pci/ice1712/phase.c | 10
sound/pci/ice1712/pontis.c | 86 +++----
sound/pci/korg1212/korg1212.c | 17 -
sound/pci/mixart/mixart.c | 21 -
sound/pci/mixart/mixart.h | 7
sound/pci/mixart/mixart_core.c | 18 -
sound/pci/mixart/mixart_mixer.c | 52 ++--
sound/pci/nm256/nm256.c | 16 -
sound/pci/pcxhr/pcxhr.c | 36 +--
sound/pci/pcxhr/pcxhr.h | 5
sound/pci/pcxhr/pcxhr_mixer.c | 75 +++---
sound/pci/trident/trident_memory.c | 36 +--
sound/pci/vx222/vx222_ops.c | 18 -
sound/pcmcia/vx/vxp_mixer.c | 12 -
sound/sparc/cs4231.c | 34 +-
sound/synth/emux/emux.c | 2
sound/synth/emux/emux_oss.c | 12 -
sound/synth/emux/emux_proc.c | 8
sound/synth/emux/emux_seq.c | 12 -
sound/synth/emux/soundfont.c | 6
sound/synth/util_mem.c | 15 -
sound/usb/usbaudio.c | 15 -
sound/usb/usx2y/usbusx2y.c | 2
sound/usb/usx2y/usbusx2y.h | 2
sound/usb/usx2y/usbusx2yaudio.c | 8
sound/usb/usx2y/usx2yhwdeppcm.c | 12 -
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-01-14 13:49 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-13 12:44 [patch 00/62] sem2mutex: -V1 Ingo Molnar
2006-01-13 12:59 ` Duncan Sands
2006-01-13 13:06 ` Arjan van de Ven
2006-01-13 13:44 ` Ingo Molnar
2006-01-13 18:25 ` Ingo Oeser
2006-01-13 19:56 ` Ingo Molnar
2006-01-13 21:04 ` Matan Peled
2006-01-13 21:25 ` Arjan van de Ven
2006-01-13 22:09 ` Junio C Hamano
2006-01-13 22:13 ` Arjan van de Ven
2006-01-14 13:22 ` Ingo Oeser
2006-01-14 13:49 ` Thomas Gleixner
2006-01-14 13:16 ` Ingo Oeser
2006-01-14 13:31 ` Arjan van de Ven
2006-01-14 13:38 ` Ingo Molnar
2006-01-13 13:23 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®