* [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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.