linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/19] MUTEX: Introduce simple mutex implementation
@ 2005-12-12 23:45 David Howells
  2005-12-12 23:45 ` [PATCH 2/19] MUTEX: i386 arch mutex David Howells
                   ` (32 more replies)
  0 siblings, 33 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch introduces a simple mutex implementation as an alternative
to the usual semaphore implementation where simple mutex functionality is all
that is required.

This is useful in two ways:

 (1) A number of archs only provide very simple atomic instructions (such as
     XCHG on i386, TAS on M68K, SWAP on FRV) which aren't sufficient to
     implement full semaphore support directly. Instead spinlocks must be
     employed to implement fuller functionality.

 (2) This makes it obvious in what way the semaphore is being used: whether
     it's being used as a mutex or being used as a counter.

This patch set does the following:

 (1) Provides a simple xchg() based semaphore as a default for all
     architectures that don't wish to override it and provide their own.

     Overriding is possible by setting CONFIG_ARCH_IMPLEMENTS_MUTEX and
     supplying asm/mutex.h

     Partial overriding is possible by #defining mutex_grab(), mutex_release()
     and is_mutex_locked() to perform the appropriate optimised functions.

 (2) Provides linux/mutex.h as a common include for gaining access to mutex
     semaphores.

 (3) Provides linux/semaphore.h as a common include for gaining access to all
     the different types of semaphore that may be used from within the kernel.

 (4) Renames down*() to down_sem*() and up() to up_sem() for the traditional
     semaphores, and removes init_MUTEX*() and DECLARE_MUTEX*() from
     asm/semaphore.h

 (5) Redirects the following to apply to the new mutexes rather than the
     traditional semaphores:

	down()
	down_trylock()
	down_interruptible()
	up()
	init_MUTEX()
     	init_MUTEX_LOCKED()
	DECLARE_MUTEX()
	DECLARE_MUTEX_LOCKED()

     On the basis that most usages of semaphores are as mutexes, this makes
     sense for in most cases it's just then a matter of changing the type from
     struct semaphore to struct mutex. In some cases, sema_init() has to be
     changed to init_MUTEX*() also.

 (6) Generally include linux/semaphore.h in place of asm/semaphore.h.

 (7) Provides a debugging config option CONFIG_DEBUG_MUTEX_OWNER by which the
     mutex owner can be tracked and by which over-upping can be detected.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-simple-2615rc5.diff
 include/linux/mutex-simple.h |  194 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/mutex.h        |   32 +++++++
 include/linux/semaphore.h    |   30 ++++++
 lib/Kconfig.debug            |    8 +
 lib/Makefile                 |    4 
 lib/mutex-simple.c           |  178 +++++++++++++++++++++++++++++++++++++++
 lib/semaphore-sleepers.c     |    8 -
 7 files changed, 450 insertions(+), 4 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/semaphore.h linux-2.6.15-rc5-mutex/include/linux/semaphore.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/semaphore.h	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/semaphore.h	2005-12-12 22:03:53.000000000 +0000
@@ -0,0 +1,30 @@
+/* semaphore.h: include the various types of semaphore in one package
+ *
+ * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _LINUX_SEMAPHORE_H
+#define _LINUX_SEMAPHORE_H
+
+/*
+ * simple mutex semaphores
+ */
+#include <linux/mutex.h>
+
+/*
+ * multiple-count semaphores
+ */
+#include <asm/semaphore.h>
+
+/*
+ * read/write semaphores
+ */
+#include <linux/rwsem.h>
+
+#endif /* _LINUX_SEMAPHORE_H */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/mutex.h linux-2.6.15-rc5-mutex/include/linux/mutex.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/mutex.h	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/mutex.h	2005-12-12 22:13:30.000000000 +0000
@@ -0,0 +1,32 @@
+/* mutex.h: mutex semaphore implementation base
+ *
+ * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#ifndef _LINUX_MUTEX_H
+#define _LINUX_MUTEX_H
+
+#include <linux/config.h>
+
+#ifdef CONFIG_ARCH_IMPLEMENTS_MUTEX
+
+/*
+ * the arch wants to implement the whole mutex itself
+ */
+#include <asm/mutex.h>
+#else
+
+/*
+ * simple exchange-based mutex
+ * - the arch may override mutex_grab(), mutex_release() and is_mutex_locked()
+ *   to use something other than xchg() by #defining mutex_grab
+ */
+#include <linux/mutex-simple.h>
+#endif
+
+#endif /* _LINUX_MUTEX_H */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/mutex-simple.h linux-2.6.15-rc5-mutex/include/linux/mutex-simple.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/mutex-simple.h	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/mutex-simple.h	2005-12-12 22:26:11.000000000 +0000
@@ -0,0 +1,194 @@
+/* mutex-simple.h: simple exchange-based mutexes
+ *
+ * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ *
+ * This doesn't require the arch to do anything for straightforward xchg()
+ * based mutexes
+ *
+ * If the sets CONFIG_ARCH_IMPLEMENTS_MUTEX then this implementation will not
+ * be used, and the arch should supply asm/mutex.h.
+ *
+ * If the arch defines mutex_grab(), mutex_release() and is_mutex_locked() for
+ * itself, then those will be used to provide the appropriate functionality
+ *
+ * See lib/mutex-simple.c for the slow-path implementation.
+ */
+#ifndef _LINUX_MUTEX_SIMPLE_H
+#define _LINUX_MUTEX_SIMPLE_H
+
+#ifndef _LINUX_MUTEX_H
+#error linux/mutex-xchg.h should not be included directly; use linux/mutex.h instead
+#endif
+
+#ifndef __ASSEMBLY__
+
+#include <linux/linkage.h>
+#include <linux/wait.h>
+#include <linux/spinlock.h>
+#include <asm/system.h>
+
+/*
+ * the mutex semaphore definition
+ * - if state is 0, then the mutex is available
+ * - if state is non-zero, then the mutex is busy
+ * - if wait_list is not empty, then there are processes waiting for the mutex
+ */
+struct mutex {
+	int			state;
+	spinlock_t		wait_lock;
+	struct list_head	wait_list;
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+	struct task_struct	*__owner;
+#endif
+};
+
+#ifndef mutex_grab
+/*
+ * mutex_grab() attempts to grab the mutex and returns true if successful
+ */
+#define mutex_grab(mutex)	(xchg(&(mutex)->state, 1) == 0)
+
+/*
+ * mutex_release() releases the mutex
+ */
+#define mutex_release(mutex)	do { (mutex)->state = 0; } while(0)
+
+/*
+ * is_mutex_locked() returns non-zero if the mutex is locked
+ */
+#define is_mutex_locked(mutex)	((mutex)->state)
+#endif
+
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+# define __MUTEX_OWNER_INIT(owner) , .__owner = (owner)
+#else
+# define __MUTEX_OWNER_INIT(owner)
+#endif
+
+#define __MUTEX_INITIALISER(name,_state,owner)			\
+{								\
+	.state		= (_state),				\
+	.wait_lock	= SPIN_LOCK_UNLOCKED,			\
+	.wait_list	= LIST_HEAD_INIT((name).wait_list)	\
+	__MUTEX_OWNER_INIT(owner)				\
+}
+
+#define __DECLARE_MUTEX_GENERIC(name, owner, state)			\
+	struct mutex name = __MUTEX_INITIALISER(name, owner, state)
+
+#define DECLARE_MUTEX(name) \
+	__DECLARE_MUTEX_GENERIC(name, 0, NULL)
+
+#define DECLARE_MUTEX_LOCKED(name, owner) \
+	__DECLARE_MUTEX_GENERIC(name, 1, (owner))
+
+static inline void mutex_init(struct mutex *mutex,
+			      unsigned state,
+			      struct task_struct *owner)
+{
+	mutex->state = state;
+	spin_lock_init(&mutex->wait_lock);
+	INIT_LIST_HEAD(&mutex->wait_list);
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+	mutex->__owner = owner;
+#endif
+}
+
+static inline void init_MUTEX(struct mutex *mutex)
+{
+	mutex_init(mutex, 0, NULL);
+}
+
+static inline void init_MUTEX_LOCKED (struct mutex *mutex)
+{
+	mutex_init(mutex, 1, current);
+}
+
+extern void __down(struct mutex *mutex);
+extern int  __down_interruptible(struct mutex *mutex);
+extern void __up(struct mutex *mutex);
+
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+extern void __up_bad(struct mutex *mutex);
+#endif
+
+/*
+ * sleep until we get the mutex
+ */
+static inline void down(struct mutex *mutex)
+{
+	if (mutex_grab(mutex)) {
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+		mutex->__owner = current;
+#endif
+	}
+	else {
+		__down(mutex);
+	}
+}
+
+/*
+ * sleep interruptibly until we get the mutex
+ * - return 0 if successful, -EINTR if interrupted
+ */
+static inline int down_interruptible(struct mutex *mutex)
+{
+	if (mutex_grab(mutex)) {
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+		mutex->__owner = current;
+#endif
+		return 0;
+	}
+
+	return __down_interruptible(mutex);
+}
+
+/*
+ * attempt to grab the mutex without waiting for it to become available
+ * - returns zero if we acquired it
+ */
+static inline int down_trylock(struct mutex *mutex)
+{
+	if (mutex_grab(mutex)) {
+		/* success */
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+		mutex->__owner = current;
+#endif
+		return 0;
+	}
+
+	/* failure */
+	return 1;
+}
+
+/*
+ * release the mutex
+ */
+static inline void up(struct mutex *mutex)
+{
+	unsigned long flags;
+
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+	if (mutex->__owner != current)
+		__up_bad(mutex);
+	mutex->__owner = NULL;
+#endif
+
+	/* must prevent a race */
+	spin_lock_irqsave(&mutex->wait_lock, flags);
+	if (!list_empty(&mutex->wait_list))
+		__up(mutex);
+	else
+		mutex_release(mutex);
+	spin_unlock_irqrestore(&mutex->wait_lock, flags);
+}
+
+#endif /* __ASSEMBLY__ */
+#endif /* _LINUX_MUTEX_SIMPLE_H */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/lib/Kconfig.debug linux-2.6.15-rc5-mutex/lib/Kconfig.debug
--- /warthog/kernels/linux-2.6.15-rc5/lib/Kconfig.debug	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/lib/Kconfig.debug	2005-12-12 16:59:35.000000000 +0000
@@ -111,6 +111,14 @@ config DEBUG_SPINLOCK_SLEEP
 	  If you say Y here, various routines which may sleep will become very
 	  noisy if they are called with a spinlock held.
 
+config DEBUG_MUTEX_OWNER
+	bool "Mutex owner tracking and checking"
+	depends on DEBUG_KERNEL
+	help
+	  If you say Y here, the process currently owning a mutex will be
+	  remembered, and a warning will be issued if anyone other than that
+	  process releases it.
+
 config DEBUG_KOBJECT
 	bool "kobject debugging"
 	depends on DEBUG_KERNEL
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/lib/Makefile linux-2.6.15-rc5-mutex/lib/Makefile
--- /warthog/kernels/linux-2.6.15-rc5/lib/Makefile	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/lib/Makefile	2005-12-12 18:59:21.000000000 +0000
@@ -28,6 +28,10 @@ ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
   lib-y += dec_and_lock.o
 endif
 
+ifneq ($(CONFIG_ARCH_IMPLEMENTS_MUTEX),y)
+  lib-y += mutex-simple.o
+endif
+
 obj-$(CONFIG_CRC_CCITT)	+= crc-ccitt.o
 obj-$(CONFIG_CRC16)	+= crc16.o
 obj-$(CONFIG_CRC32)	+= crc32.o
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/lib/mutex-simple.c linux-2.6.15-rc5-mutex/lib/mutex-simple.c
--- /warthog/kernels/linux-2.6.15-rc5/lib/mutex-simple.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.15-rc5-mutex/lib/mutex-simple.c	2005-12-12 22:27:00.000000000 +0000
@@ -0,0 +1,178 @@
+/* mutex-simple.c: simple mutex slow paths
+ *
+ * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/sched.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+
+struct mutex_waiter {
+	struct list_head	list;
+	struct task_struct	*task;
+};
+
+/*
+ * wait for a token to be granted from a mutex
+ */
+void __down(struct mutex *mutex)
+{
+	struct mutex_waiter waiter;
+	struct task_struct *tsk = current;
+	unsigned long flags;
+
+	/* set up my own style of waitqueue */
+	waiter.task = tsk;
+
+	spin_lock_irqsave(&mutex->wait_lock, flags);
+
+	if (mutex_grab(mutex)) {
+		/* we got the mutex anyway */
+		spin_unlock_irqrestore(&mutex->wait_lock, flags);
+		return;
+	}
+
+	/* need to sleep */
+	get_task_struct(tsk);
+	list_add_tail(&waiter.list, &mutex->wait_list);
+
+	/* we don't need to touch the mutex struct anymore */
+	spin_unlock_irqrestore(&mutex->wait_lock, flags);
+
+	/* wait to be given the mutex */
+	set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+
+	for (;;) {
+		if (list_empty(&waiter.list))
+			break;
+		schedule();
+		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+	}
+
+	tsk->state = TASK_RUNNING;
+}
+
+EXPORT_SYMBOL(__down);
+
+/*
+ * interruptibly wait for a token to be granted from a mutex
+ */
+int __down_interruptible(struct mutex *mutex)
+{
+	struct mutex_waiter waiter;
+	struct task_struct *tsk = current;
+	unsigned long flags;
+	int ret;
+
+	/* set up my own style of waitqueue */
+	waiter.task = tsk;
+
+	spin_lock_irqsave(&mutex->wait_lock, flags);
+
+	if (mutex_grab(mutex)) {
+		/* we got the mutex anyway */
+		spin_unlock_irqrestore(&mutex->wait_lock, flags);
+		return 0;
+	}
+
+	/* need to sleep */
+	get_task_struct(tsk);
+	list_add_tail(&waiter.list, &mutex->wait_list);
+
+	/* we don't need to touch the mutex struct anymore */
+	set_task_state(tsk, TASK_INTERRUPTIBLE);
+
+	spin_unlock_irqrestore(&mutex->wait_lock, flags);
+
+	/* wait to be given the mutex */
+	for (;;) {
+		if (list_empty(&waiter.list))
+			break;
+		if (unlikely(signal_pending(current)))
+			goto interrupted;
+		schedule();
+		set_task_state(tsk, TASK_INTERRUPTIBLE);
+	}
+
+	tsk->state = TASK_RUNNING;
+	return 0;
+
+interrupted:
+	spin_lock_irqsave(&mutex->wait_lock, flags);
+
+	/* we may still have been given the mutex */
+	ret = 0;
+	if (!list_empty(&waiter.list)) {
+		list_del(&waiter.list);
+		ret = -EINTR;
+	}
+
+	spin_unlock_irqrestore(&mutex->wait_lock, flags);
+	if (ret == -EINTR)
+		put_task_struct(current);
+	return ret;
+}
+
+EXPORT_SYMBOL(__down_interruptible);
+
+/*
+ * release a single token back to a mutex
+ * - entered with lock held and interrupts disabled
+ * - the queue will not be empty
+ */
+void __up(struct mutex *mutex)
+{
+	struct mutex_waiter *waiter;
+	struct task_struct *tsk;
+
+	/* grant the token to the process at the front of the queue */
+	waiter = list_entry(mutex->wait_list.next, struct mutex_waiter, list);
+
+	/* we must be careful not to touch 'waiter' after we set ->task = NULL.
+	 * - it is an allocated on the waiter's stack and may become invalid at
+	 *   any time after that point (due to a wakeup from another source).
+	 */
+	list_del_init(&waiter->list);
+	tsk = waiter->task;
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+	mutex->__owner = tsk;
+#endif
+	mb();
+	waiter->task = NULL;
+	wake_up_process(tsk);
+	put_task_struct(tsk);
+}
+
+EXPORT_SYMBOL(__up);
+
+/*
+ * report an up() that doesn't match a down()
+ */
+#ifdef CONFIG_DEBUG_MUTEX_OWNER
+void __up_bad(struct mutex *mutex)
+{
+	if (!mutex->__owner) {
+		printk(KERN_ERR
+		       "BUG: process %d [%s] releasing unowned mutex\n",
+		       current->pid,
+		       current->comm);
+	}
+	else {
+		printk(KERN_ERR
+		       "BUG: process %d [%s] releasing mutex owned by %d [%s]\n",
+		       current->pid,
+		       current->comm,
+		       mutex->__owner->pid,
+		       mutex->__owner->comm);
+	}
+}
+
+EXPORT_SYMBOL(__up_bad);
+#endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/lib/semaphore-sleepers.c linux-2.6.15-rc5-mutex/lib/semaphore-sleepers.c
--- /warthog/kernels/linux-2.6.15-rc5/lib/semaphore-sleepers.c	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/lib/semaphore-sleepers.c	2005-12-12 17:58:35.000000000 +0000
@@ -49,12 +49,12 @@
  *    we cannot lose wakeup events.
  */
 
-fastcall void __up(struct semaphore *sem)
+fastcall void __up_sem(struct semaphore *sem)
 {
 	wake_up(&sem->wait);
 }
 
-fastcall void __sched __down(struct semaphore * sem)
+fastcall void __sched __down_sem(struct semaphore * sem)
 {
 	struct task_struct *tsk = current;
 	DECLARE_WAITQUEUE(wait, tsk);
@@ -91,7 +91,7 @@ fastcall void __sched __down(struct sema
 	tsk->state = TASK_RUNNING;
 }
 
-fastcall int __sched __down_interruptible(struct semaphore * sem)
+fastcall int __sched __down_sem_interruptible(struct semaphore * sem)
 {
 	int retval = 0;
 	struct task_struct *tsk = current;
@@ -154,7 +154,7 @@ fastcall int __sched __down_interruptibl
  * single "cmpxchg" without failure cases,
  * but then it wouldn't work on a 386.
  */
-fastcall int __down_trylock(struct semaphore * sem)
+fastcall int __down_sem_trylock(struct semaphore * sem)
 {
 	int sleepers;
 	unsigned long flags;

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 2/19] MUTEX: i386 arch mutex
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 8/19] MUTEX: Drivers I-K changes David Howells
                   ` (31 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch renames the functions of the i386 traditional semaphore
implementation to include "_sem" in their names and to remove the MUTEX macros
that are now provided by the new mutex facility.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-i386-2615rc5.diff
 arch/i386/kernel/cpu/proc.c   |    2 -
 arch/i386/kernel/i386_ksyms.c |   12 ++++++---
 arch/i386/kernel/semaphore.c  |   24 +++++++++---------
 include/asm-i386/mmu.h        |    4 +--
 include/asm-i386/semaphore.h  |   55 ++++++++++++++++--------------------------
 include/asm-i386/voyager.h    |    2 -
 6 files changed, 45 insertions(+), 54 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/asm-i386/mmu.h linux-2.6.15-rc5-mutex/include/asm-i386/mmu.h
--- /warthog/kernels/linux-2.6.15-rc5/include/asm-i386/mmu.h	2004-06-18 13:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/asm-i386/mmu.h	2005-12-12 18:49:34.000000000 +0000
@@ -1,7 +1,7 @@
 #ifndef __i386_MMU_H
 #define __i386_MMU_H
 
-#include <asm/semaphore.h>
+#include <linux/mutex.h>
 /*
  * The i386 doesn't have a mmu context, but
  * we put the segment information here.
@@ -10,7 +10,7 @@
  */
 typedef struct { 
 	int size;
-	struct semaphore sem;
+	struct mutex sem;
 	void *ldt;
 } mm_context_t;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/asm-i386/semaphore.h linux-2.6.15-rc5-mutex/include/asm-i386/semaphore.h
--- /warthog/kernels/linux-2.6.15-rc5/include/asm-i386/semaphore.h	2005-12-08 16:23:52.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/asm-i386/semaphore.h	2005-12-12 17:02:03.000000000 +0000
@@ -58,9 +58,6 @@ struct semaphore {
 #define __DECLARE_SEMAPHORE_GENERIC(name,count) \
 	struct semaphore name = __SEMAPHORE_INITIALIZER(name,count)
 
-#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name,1)
-#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0)
-
 static inline void sema_init (struct semaphore *sem, int val)
 {
 /*
@@ -74,37 +71,27 @@ static inline void sema_init (struct sem
 	init_waitqueue_head(&sem->wait);
 }
 
-static inline void init_MUTEX (struct semaphore *sem)
-{
-	sema_init(sem, 1);
-}
-
-static inline void init_MUTEX_LOCKED (struct semaphore *sem)
-{
-	sema_init(sem, 0);
-}
-
-fastcall void __down_failed(void /* special register calling convention */);
-fastcall int  __down_failed_interruptible(void  /* params in registers */);
-fastcall int  __down_failed_trylock(void  /* params in registers */);
-fastcall void __up_wakeup(void /* special register calling convention */);
+fastcall void __down_sem_failed(void /* special register calling convention */);
+fastcall int  __down_sem_failed_interruptible(void  /* params in registers */);
+fastcall int  __down_sem_failed_trylock(void  /* params in registers */);
+fastcall void __up_sem_wakeup(void /* special register calling convention */);
 
 /*
  * This is ugly, but we want the default case to fall through.
  * "__down_failed" is a special asm handler that calls the C
  * routine that actually waits. See arch/i386/kernel/semaphore.c
  */
-static inline void down(struct semaphore * sem)
+static inline void down_sem(struct semaphore * sem)
 {
 	might_sleep();
 	__asm__ __volatile__(
-		"# atomic down operation\n\t"
+		"# atomic down_sem operation\n\t"
 		LOCK "decl %0\n\t"     /* --sem->count */
 		"js 2f\n"
 		"1:\n"
 		LOCK_SECTION_START("")
 		"2:\tlea %0,%%eax\n\t"
-		"call __down_failed\n\t"
+		"call __down_sem_failed\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=m" (sem->count)
@@ -113,23 +100,23 @@ static inline void down(struct semaphore
 }
 
 /*
- * Interruptible try to acquire a semaphore.  If we obtained
- * it, return zero.  If we were interrupted, returns -EINTR
+ * Interrup_semtible try to acquire a semaphore.  If we obtained
+ * it, return zero.  If we were interrup_semted, returns -EINTR
  */
-static inline int down_interruptible(struct semaphore * sem)
+static inline int down_sem_interrup_semtible(struct semaphore * sem)
 {
 	int result;
 
 	might_sleep();
 	__asm__ __volatile__(
-		"# atomic interruptible down operation\n\t"
+		"# atomic interrup_semtible down_sem operation\n\t"
 		LOCK "decl %1\n\t"     /* --sem->count */
 		"js 2f\n\t"
 		"xorl %0,%0\n"
 		"1:\n"
 		LOCK_SECTION_START("")
 		"2:\tlea %1,%%eax\n\t"
-		"call __down_failed_interruptible\n\t"
+		"call __down_sem_failed_interrup_semtible\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=a" (result), "=m" (sem->count)
@@ -139,22 +126,22 @@ static inline int down_interruptible(str
 }
 
 /*
- * Non-blockingly attempt to down() a semaphore.
+ * Non-blockingly attempt to down_sem() a semaphore.
  * Returns zero if we acquired it
  */
-static inline int down_trylock(struct semaphore * sem)
+static inline int down_sem_trylock(struct semaphore * sem)
 {
 	int result;
 
 	__asm__ __volatile__(
-		"# atomic interruptible down operation\n\t"
+		"# atomic interrup_semtible down_sem operation\n\t"
 		LOCK "decl %1\n\t"     /* --sem->count */
 		"js 2f\n\t"
 		"xorl %0,%0\n"
 		"1:\n"
 		LOCK_SECTION_START("")
 		"2:\tlea %1,%%eax\n\t"
-		"call __down_failed_trylock\n\t"
+		"call __down_sem_failed_trylock\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=a" (result), "=m" (sem->count)
@@ -164,21 +151,21 @@ static inline int down_trylock(struct se
 }
 
 /*
- * Note! This is subtle. We jump to wake people up only if
+ * Note! This is subtle. We jump to wake people up_sem only if
  * the semaphore was negative (== somebody was waiting on it).
  * The default case (no contention) will result in NO
- * jumps for both down() and up().
+ * jumps for both down_sem() and up_sem().
  */
-static inline void up(struct semaphore * sem)
+static inline void up_sem(struct semaphore * sem)
 {
 	__asm__ __volatile__(
-		"# atomic up operation\n\t"
+		"# atomic up_sem operation\n\t"
 		LOCK "incl %0\n\t"     /* ++sem->count */
 		"jle 2f\n"
 		"1:\n"
 		LOCK_SECTION_START("")
 		"2:\tlea %0,%%eax\n\t"
-		"call __up_wakeup\n\t"
+		"call __up_sem_wakeup\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		".subsection 0\n"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/asm-i386/voyager.h linux-2.6.15-rc5-mutex/include/asm-i386/voyager.h
--- /warthog/kernels/linux-2.6.15-rc5/include/asm-i386/voyager.h	2004-06-18 13:42:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/asm-i386/voyager.h	2005-12-12 19:51:20.000000000 +0000
@@ -489,7 +489,7 @@ extern struct voyager_SUS *voyager_SUS;
 /* variables exported always */
 extern int voyager_level;
 extern int kvoyagerd_running;
-extern struct semaphore kvoyagerd_sem;
+extern struct mutex kvoyagerd_sem;
 extern struct voyager_status voyager_status;
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/i386/kernel/cpu/proc.c linux-2.6.15-rc5-mutex/arch/i386/kernel/cpu/proc.c
--- /warthog/kernels/linux-2.6.15-rc5/arch/i386/kernel/cpu/proc.c	2005-12-08 16:23:33.000000000 +0000
+++ linux-2.6.15-rc5-mutex/arch/i386/kernel/cpu/proc.c	2005-12-12 18:50:39.000000000 +0000
@@ -1,7 +1,7 @@
 #include <linux/smp.h>
 #include <linux/timex.h>
 #include <linux/string.h>
-#include <asm/semaphore.h>
+#include <linux/mutex.h>
 #include <linux/seq_file.h>
 
 /*
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/i386/kernel/i386_ksyms.c linux-2.6.15-rc5-mutex/arch/i386/kernel/i386_ksyms.c
--- /warthog/kernels/linux-2.6.15-rc5/arch/i386/kernel/i386_ksyms.c	2005-08-30 13:56:11.000000000 +0100
+++ linux-2.6.15-rc5-mutex/arch/i386/kernel/i386_ksyms.c	2005-12-12 18:50:31.000000000 +0000
@@ -1,15 +1,19 @@
 #include <linux/config.h>
 #include <linux/module.h>
+#include <linux/mutex.h>
 #include <asm/checksum.h>
 #include <asm/desc.h>
 
 /* This is definitely a GPL-only symbol */
 EXPORT_SYMBOL_GPL(cpu_gdt_table);
 
-EXPORT_SYMBOL(__down_failed);
-EXPORT_SYMBOL(__down_failed_interruptible);
-EXPORT_SYMBOL(__down_failed_trylock);
-EXPORT_SYMBOL(__up_wakeup);
+EXPORT_SYMBOL(__down);
+EXPORT_SYMBOL(__down_interruptible);
+EXPORT_SYMBOL(__up);
+EXPORT_SYMBOL(__down_sem_failed);
+EXPORT_SYMBOL(__down_sem_failed_interruptible);
+EXPORT_SYMBOL(__down_sem_failed_trylock);
+EXPORT_SYMBOL(__up_sem_wakeup);
 /* Networking helper routines. */
 EXPORT_SYMBOL(csum_partial_copy_generic);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/i386/kernel/semaphore.c linux-2.6.15-rc5-mutex/arch/i386/kernel/semaphore.c
--- /warthog/kernels/linux-2.6.15-rc5/arch/i386/kernel/semaphore.c	2005-11-01 13:18:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/arch/i386/kernel/semaphore.c	2005-12-12 18:08:03.000000000 +0000
@@ -28,15 +28,15 @@
 asm(
 ".section .sched.text\n"
 ".align 4\n"
-".globl __down_failed\n"
-"__down_failed:\n\t"
+".globl __down_sem_failed\n"
+"__down_sem_failed:\n\t"
 #if defined(CONFIG_FRAME_POINTER)
 	"pushl %ebp\n\t"
 	"movl  %esp,%ebp\n\t"
 #endif
 	"pushl %edx\n\t"
 	"pushl %ecx\n\t"
-	"call __down\n\t"
+	"call __down_sem\n\t"
 	"popl %ecx\n\t"
 	"popl %edx\n\t"
 #if defined(CONFIG_FRAME_POINTER)
@@ -49,15 +49,15 @@ asm(
 asm(
 ".section .sched.text\n"
 ".align 4\n"
-".globl __down_failed_interruptible\n"
-"__down_failed_interruptible:\n\t"
+".globl __down_sem_failed_interruptible\n"
+"__down_sem_failed_interruptible:\n\t"
 #if defined(CONFIG_FRAME_POINTER)
 	"pushl %ebp\n\t"
 	"movl  %esp,%ebp\n\t"
 #endif
 	"pushl %edx\n\t"
 	"pushl %ecx\n\t"
-	"call __down_interruptible\n\t"
+	"call __down_sem_interruptible\n\t"
 	"popl %ecx\n\t"
 	"popl %edx\n\t"
 #if defined(CONFIG_FRAME_POINTER)
@@ -70,15 +70,15 @@ asm(
 asm(
 ".section .sched.text\n"
 ".align 4\n"
-".globl __down_failed_trylock\n"
-"__down_failed_trylock:\n\t"
+".globl __down_sem_failed_trylock\n"
+"__down_sem_failed_trylock:\n\t"
 #if defined(CONFIG_FRAME_POINTER)
 	"pushl %ebp\n\t"
 	"movl  %esp,%ebp\n\t"
 #endif
 	"pushl %edx\n\t"
 	"pushl %ecx\n\t"
-	"call __down_trylock\n\t"
+	"call __down_sem_trylock\n\t"
 	"popl %ecx\n\t"
 	"popl %edx\n\t"
 #if defined(CONFIG_FRAME_POINTER)
@@ -91,11 +91,11 @@ asm(
 asm(
 ".section .sched.text\n"
 ".align 4\n"
-".globl __up_wakeup\n"
-"__up_wakeup:\n\t"
+".globl __up_sem_wakeup\n"
+"__up_sem_wakeup:\n\t"
 	"pushl %edx\n\t"
 	"pushl %ecx\n\t"
-	"call __up\n\t"
+	"call __up_sem\n\t"
 	"popl %ecx\n\t"
 	"popl %edx\n\t"
 	"ret"

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 3/19] MUTEX: x86_64 arch mutex
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (3 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 6/19] MUTEX: Drivers A-E changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 5/19] MUTEX: Core kernel changes David Howells
                   ` (27 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch renames the functions of the x86_64 traditional semaphore
implementation to include "_sem" in their names and to remove the MUTEX macros
that are now provided by the new mutex facility.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-x86_64-2615rc5.diff
 arch/x86_64/kernel/x8664_ksyms.c |   10 +++----
 arch/x86_64/lib/thunk.S          |    8 +++---
 include/asm-x86_64/mmu.h         |    4 +--
 include/asm-x86_64/semaphore.h   |   49 ++++++++++++++-------------------------
 4 files changed, 29 insertions(+), 42 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/asm-x86_64/mmu.h linux-2.6.15-rc5-mutex/include/asm-x86_64/mmu.h
--- /warthog/kernels/linux-2.6.15-rc5/include/asm-x86_64/mmu.h	2004-06-18 13:42:14.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/asm-x86_64/mmu.h	2005-12-12 19:50:13.000000000 +0000
@@ -2,7 +2,7 @@
 #define __x86_64_MMU_H
 
 #include <linux/spinlock.h>
-#include <asm/semaphore.h>
+#include <linux/mutex.h>
 
 /*
  * The x86_64 doesn't have a mmu context, but
@@ -14,7 +14,7 @@ typedef struct { 
 	void *ldt;
 	rwlock_t ldtlock; 
 	int size;
-	struct semaphore sem; 
+	struct mutex sem; 
 } mm_context_t;
 
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/asm-x86_64/semaphore.h linux-2.6.15-rc5-mutex/include/asm-x86_64/semaphore.h
--- /warthog/kernels/linux-2.6.15-rc5/include/asm-x86_64/semaphore.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/asm-x86_64/semaphore.h	2005-12-12 22:28:09.000000000 +0000
@@ -59,9 +59,6 @@ struct semaphore {
 #define __DECLARE_SEMAPHORE_GENERIC(name,count) \
 	struct semaphore name = __SEMAPHORE_INITIALIZER(name,count)
 
-#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name,1)
-#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0)
-
 static inline void sema_init (struct semaphore *sem, int val)
 {
 /*
@@ -75,32 +72,22 @@ static inline void sema_init (struct sem
 	init_waitqueue_head(&sem->wait);
 }
 
-static inline void init_MUTEX (struct semaphore *sem)
-{
-	sema_init(sem, 1);
-}
-
-static inline void init_MUTEX_LOCKED (struct semaphore *sem)
-{
-	sema_init(sem, 0);
-}
-
-asmlinkage void __down_failed(void /* special register calling convention */);
-asmlinkage int  __down_failed_interruptible(void  /* params in registers */);
-asmlinkage int  __down_failed_trylock(void  /* params in registers */);
-asmlinkage void __up_wakeup(void /* special register calling convention */);
-
-asmlinkage void __down(struct semaphore * sem);
-asmlinkage int  __down_interruptible(struct semaphore * sem);
-asmlinkage int  __down_trylock(struct semaphore * sem);
-asmlinkage void __up(struct semaphore * sem);
+asmlinkage void __down_sem_failed(void /* special register calling convention */);
+asmlinkage int  __down_sem_failed_interruptible(void  /* params in registers */);
+asmlinkage int  __down_sem_failed_trylock(void  /* params in registers */);
+asmlinkage void __up_sem_wakeup(void /* special register calling convention */);
+
+asmlinkage void __down_sem(struct semaphore * sem);
+asmlinkage int  __down_sem_interruptible(struct semaphore * sem);
+asmlinkage int  __down_sem_trylock(struct semaphore * sem);
+asmlinkage void __up_sem(struct semaphore * sem);
 
 /*
  * This is ugly, but we want the default case to fall through.
- * "__down_failed" is a special asm handler that calls the C
+ * "__down_sem_failed" is a special asm handler that calls the C
  * routine that actually waits. See arch/x86_64/kernel/semaphore.c
  */
-static inline void down(struct semaphore * sem)
+static inline void down_sem(struct semaphore * sem)
 {
 	might_sleep();
 
@@ -110,7 +97,7 @@ static inline void down(struct semaphore
 		"js 2f\n"
 		"1:\n"
 		LOCK_SECTION_START("")
-		"2:\tcall __down_failed\n\t"
+		"2:\tcall __down_sem_failed\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=m" (sem->count)
@@ -122,7 +109,7 @@ static inline void down(struct semaphore
  * Interruptible try to acquire a semaphore.  If we obtained
  * it, return zero.  If we were interrupted, returns -EINTR
  */
-static inline int down_interruptible(struct semaphore * sem)
+static inline int down_sem_interruptible(struct semaphore * sem)
 {
 	int result;
 
@@ -135,7 +122,7 @@ static inline int down_interruptible(str
 		"xorl %0,%0\n"
 		"1:\n"
 		LOCK_SECTION_START("")
-		"2:\tcall __down_failed_interruptible\n\t"
+		"2:\tcall __down_sem_failed_interruptible\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=a" (result), "=m" (sem->count)
@@ -148,7 +135,7 @@ static inline int down_interruptible(str
  * Non-blockingly attempt to down() a semaphore.
  * Returns zero if we acquired it
  */
-static inline int down_trylock(struct semaphore * sem)
+static inline int down_sem_trylock(struct semaphore * sem)
 {
 	int result;
 
@@ -159,7 +146,7 @@ static inline int down_trylock(struct se
 		"xorl %0,%0\n"
 		"1:\n"
 		LOCK_SECTION_START("")
-		"2:\tcall __down_failed_trylock\n\t"
+		"2:\tcall __down_sem_failed_trylock\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=a" (result), "=m" (sem->count)
@@ -174,7 +161,7 @@ static inline int down_trylock(struct se
  * The default case (no contention) will result in NO
  * jumps for both down() and up().
  */
-static inline void up(struct semaphore * sem)
+static inline void up_sem(struct semaphore * sem)
 {
 	__asm__ __volatile__(
 		"# atomic up operation\n\t"
@@ -182,7 +169,7 @@ static inline void up(struct semaphore *
 		"jle 2f\n"
 		"1:\n"
 		LOCK_SECTION_START("")
-		"2:\tcall __up_wakeup\n\t"
+		"2:\tcall __up_sem_wakeup\n\t"
 		"jmp 1b\n"
 		LOCK_SECTION_END
 		:"=m" (sem->count)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/x86_64/kernel/x8664_ksyms.c linux-2.6.15-rc5-mutex/arch/x86_64/kernel/x8664_ksyms.c
--- /warthog/kernels/linux-2.6.15-rc5/arch/x86_64/kernel/x8664_ksyms.c	2005-12-08 16:23:37.000000000 +0000
+++ linux-2.6.15-rc5-mutex/arch/x86_64/kernel/x8664_ksyms.c	2005-12-12 22:33:36.000000000 +0000
@@ -14,8 +14,8 @@
 #include <linux/syscalls.h>
 #include <linux/tty.h>
 #include <linux/ioctl32.h>
+#include <linux/semaphore.h>
 
-#include <asm/semaphore.h>
 #include <asm/processor.h>
 #include <asm/i387.h>
 #include <asm/uaccess.h>
@@ -62,10 +62,10 @@ EXPORT_SYMBOL(pm_idle);
 EXPORT_SYMBOL(pm_power_off);
 EXPORT_SYMBOL(get_cmos_time);
 
-EXPORT_SYMBOL(__down_failed);
-EXPORT_SYMBOL(__down_failed_interruptible);
-EXPORT_SYMBOL(__down_failed_trylock);
-EXPORT_SYMBOL(__up_wakeup);
+EXPORT_SYMBOL(__down_sem_failed);
+EXPORT_SYMBOL(__down_sem_failed_interruptible);
+EXPORT_SYMBOL(__down_sem_failed_trylock);
+EXPORT_SYMBOL(__up_sem_wakeup);
 /* Networking helper routines. */
 EXPORT_SYMBOL(csum_partial_copy_nocheck);
 EXPORT_SYMBOL(ip_compute_csum);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/x86_64/lib/thunk.S linux-2.6.15-rc5-mutex/arch/x86_64/lib/thunk.S
--- /warthog/kernels/linux-2.6.15-rc5/arch/x86_64/lib/thunk.S	2004-06-18 13:41:13.000000000 +0100
+++ linux-2.6.15-rc5-mutex/arch/x86_64/lib/thunk.S	2005-12-12 22:32:51.000000000 +0000
@@ -44,10 +44,10 @@
 #endif	
 	thunk do_softirq_thunk,do_softirq
 	
-	thunk __down_failed,__down
-	thunk_retrax __down_failed_interruptible,__down_interruptible
-	thunk_retrax __down_failed_trylock,__down_trylock
-	thunk __up_wakeup,__up
+	thunk __down_sem_failed,__down_sem
+	thunk_retrax __down_sem_failed_interruptible,__down_sem_interruptible
+	thunk_retrax __down_sem_failed_trylock,__down_sem_trylock
+	thunk __up_sem_wakeup,__up_sem
 	
 	/* SAVE_ARGS below is used only for the .cfi directives it contains. */
 	CFI_STARTPROC

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 5/19] MUTEX: Core kernel changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (4 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 3/19] MUTEX: x86_64 arch mutex David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 4/19] MUTEX: FRV arch mutex David Howells
                   ` (26 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the core files of the kernel to use the new mutex
functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-core-2615rc5.diff
 kernel/cpu.c                    |    2 +-
 kernel/cpuset.c                 |    2 +-
 kernel/kexec.c                  |    2 +-
 kernel/kthread.c                |    4 ++--
 kernel/module.c                 |    2 +-
 kernel/posix-timers.c           |    2 +-
 kernel/power/power.h            |    3 ++-
 kernel/printk.c                 |   32 ++++++++++++++++----------------
 kernel/profile.c                |    2 +-
 kernel/stop_machine.c           |    2 +-
 lib/reed_solomon/reed_solomon.c |    2 +-
 mm/slab.c                       |    2 +-
 12 files changed, 29 insertions(+), 28 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/cpu.c linux-2.6.15-rc5-mutex/kernel/cpu.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/cpu.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/cpu.c	2005-12-12 22:12:50.000000000 +0000
@@ -13,7 +13,7 @@
 #include <linux/module.h>
 #include <linux/kthread.h>
 #include <linux/stop_machine.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* This protects CPUs going up and down... */
 static DECLARE_MUTEX(cpucontrol);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/cpuset.c linux-2.6.15-rc5-mutex/kernel/cpuset.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/cpuset.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/cpuset.c	2005-12-12 22:12:50.000000000 +0000
@@ -52,7 +52,7 @@
 
 #include <asm/uaccess.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define CPUSET_SUPER_MAGIC 		0x27e0eb
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/kexec.c linux-2.6.15-rc5-mutex/kernel/kexec.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/kexec.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/kexec.c	2005-12-12 22:12:50.000000000 +0000
@@ -19,12 +19,12 @@
 #include <linux/syscalls.h>
 #include <linux/ioport.h>
 #include <linux/hardirq.h>
+#include <linux/semaphore.h>
 
 #include <asm/page.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/system.h>
-#include <asm/semaphore.h>
 
 /* Location of the reserved area for the crash kernel */
 struct resource crashk_res = {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/kthread.c linux-2.6.15-rc5-mutex/kernel/kthread.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/kthread.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/kthread.c	2005-12-12 22:12:50.000000000 +0000
@@ -12,7 +12,7 @@
 #include <linux/unistd.h>
 #include <linux/file.h>
 #include <linux/module.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /*
  * We dont want to execute off keventd since it might
@@ -169,7 +169,7 @@ int kthread_stop(struct task_struct *k)
 }
 EXPORT_SYMBOL(kthread_stop);
 
-int kthread_stop_sem(struct task_struct *k, struct semaphore *s)
+int kthread_stop_sem(struct task_struct *k, struct mutex *s)
 {
 	int ret;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/module.c linux-2.6.15-rc5-mutex/kernel/module.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/module.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/module.c	2005-12-12 22:12:50.000000000 +0000
@@ -38,8 +38,8 @@
 #include <linux/device.h>
 #include <linux/string.h>
 #include <linux/sched.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
 #include <asm/cacheflush.h>
 
 #if 0
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/posix-timers.c linux-2.6.15-rc5-mutex/kernel/posix-timers.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/posix-timers.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/posix-timers.c	2005-12-12 22:12:50.000000000 +0000
@@ -37,7 +37,7 @@
 #include <linux/time.h>
 
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/list.h>
 #include <linux/init.h>
 #include <linux/compiler.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/power/power.h linux-2.6.15-rc5-mutex/kernel/power/power.h
--- /warthog/kernels/linux-2.6.15-rc5/kernel/power/power.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/power/power.h	2005-12-12 22:12:50.000000000 +0000
@@ -1,5 +1,6 @@
 #include <linux/suspend.h>
 #include <linux/utsname.h>
+#include <linux/semaphore.h>
 
 /* With SUSPEND_CONSOLE defined suspend looks *really* cool, but
    we probably do not take enough locks for switching consoles, etc,
@@ -35,7 +36,7 @@ static inline int pm_suspend_disk(void)
 	return -EPERM;
 }
 #endif
-extern struct semaphore pm_sem;
+extern struct mutex pm_sem;
 #define power_attr(_name) \
 static struct subsys_attribute _name##_attr = {	\
 	.attr	= {				\
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/printk.c linux-2.6.15-rc5-mutex/kernel/printk.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/printk.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/printk.c	2005-12-12 18:29:14.000000000 +0000
@@ -62,11 +62,11 @@ int oops_in_progress;
 EXPORT_SYMBOL(oops_in_progress);
 
 /*
- * console_sem protects the console_drivers list, and also
+ * console_mutex protects the console_drivers list, and also
  * provides serialisation for access to the entire console
  * driver system.
  */
-static DECLARE_MUTEX(console_sem);
+static DECLARE_MUTEX(console_mutex);
 struct console *console_drivers;
 /*
  * This is used for debugging the mess that is the VT code by
@@ -81,7 +81,7 @@ static int console_locked;
 /*
  * logbuf_lock protects log_buf, log_start, log_end, con_start and logged_chars
  * It is also used in interesting ways to provide interlocking in
- * release_console_sem().
+ * release_console_mutex().
  */
 static DEFINE_SPINLOCK(logbuf_lock);
 
@@ -391,7 +391,7 @@ static void _call_console_drivers(unsign
 /*
  * Call the console drivers, asking them to write out
  * log_buf[start] to log_buf[end - 1].
- * The console_sem must be held.
+ * The console_mutex must be held.
  */
 static void call_console_drivers(unsigned long start, unsigned long end)
 {
@@ -467,7 +467,7 @@ static void zap_locks(void)
 	/* If a crash is occurring, make sure we can't deadlock */
 	spin_lock_init(&logbuf_lock);
 	/* And make sure that we print immediately */
-	init_MUTEX(&console_sem);
+	init_MUTEX(&console_mutex);
 }
 
 #if defined(CONFIG_PRINTK_TIME)
@@ -497,10 +497,10 @@ __attribute__((weak)) unsigned long long
  *
  * This is printk.  It can be called from any context.  We want it to work.
  *
- * We try to grab the console_sem.  If we succeed, it's easy - we log the output and
+ * We try to grab the console_mutex.  If we succeed, it's easy - we log the output and
  * call the console drivers.  If we fail to get the semaphore we place the output
- * into the log buffer and return.  The current holder of the console_sem will
- * notice the new output in release_console_sem() and will send it to the
+ * into the log buffer and return.  The current holder of the console_mutex will
+ * notice the new output in release_console_mutex() and will send it to the
  * consoles before releasing the semaphore.
  *
  * One effect of this deferred printing is that code which calls printk() and
@@ -540,7 +540,7 @@ asmlinkage int vprintk(const char *fmt, 
 		 * make sure we can't deadlock */
 		zap_locks();
 
-	/* This stops the holder of console_sem just where we want him */
+	/* This stops the holder of console_mutex just where we want him */
 	spin_lock_irqsave(&logbuf_lock, flags);
 	printk_cpu = smp_processor_id();
 
@@ -615,11 +615,11 @@ asmlinkage int vprintk(const char *fmt, 
 		spin_unlock_irqrestore(&logbuf_lock, flags);
 		goto out;
 	}
-	if (!down_trylock(&console_sem)) {
+	if (!down_trylock(&console_mutex)) {
 		console_locked = 1;
 		/*
 		 * We own the drivers.  We can drop the spinlock and let
-		 * release_console_sem() print the text
+		 * release_console_mutex() print the text
 		 */
 		printk_cpu = UINT_MAX;
 		spin_unlock_irqrestore(&logbuf_lock, flags);
@@ -710,7 +710,7 @@ void acquire_console_sem(void)
 {
 	if (in_interrupt())
 		BUG();
-	down(&console_sem);
+	down(&console_mutex);
 	console_locked = 1;
 	console_may_schedule = 1;
 }
@@ -718,7 +718,7 @@ EXPORT_SYMBOL(acquire_console_sem);
 
 int try_acquire_console_sem(void)
 {
-	if (down_trylock(&console_sem))
+	if (down_trylock(&console_mutex))
 		return -1;
 	console_locked = 1;
 	console_may_schedule = 0;
@@ -739,7 +739,7 @@ EXPORT_SYMBOL(is_console_locked);
  * and the console driver list.
  *
  * While the semaphore was held, console output may have been buffered
- * by printk().  If this is the case, release_console_sem() emits
+ * by printk().  If this is the case, release_console_mutex() emits
  * the output prior to releasing the semaphore.
  *
  * If there is output waiting for klogd, we wake it up.
@@ -766,7 +766,7 @@ void release_console_sem(void)
 	}
 	console_locked = 0;
 	console_may_schedule = 0;
-	up(&console_sem);
+	up(&console_mutex);
 	spin_unlock_irqrestore(&logbuf_lock, flags);
 	if (wake_klogd && !oops_in_progress && waitqueue_active(&log_wait))
 		wake_up_interruptible(&log_wait);
@@ -804,7 +804,7 @@ void console_unblank(void)
 	 * oops_in_progress is set to 1..
 	 */
 	if (oops_in_progress) {
-		if (down_trylock(&console_sem) != 0)
+		if (down_trylock(&console_mutex) != 0)
 			return;
 	} else
 		acquire_console_sem();
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/profile.c linux-2.6.15-rc5-mutex/kernel/profile.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/profile.c	2005-08-30 13:56:40.000000000 +0100
+++ linux-2.6.15-rc5-mutex/kernel/profile.c	2005-12-12 22:12:50.000000000 +0000
@@ -24,7 +24,7 @@
 #include <linux/profile.h>
 #include <linux/highmem.h>
 #include <asm/sections.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct profile_hit {
 	u32 pc, hits;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/kernel/stop_machine.c linux-2.6.15-rc5-mutex/kernel/stop_machine.c
--- /warthog/kernels/linux-2.6.15-rc5/kernel/stop_machine.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/kernel/stop_machine.c	2005-12-12 22:12:50.000000000 +0000
@@ -5,7 +5,7 @@
 #include <linux/err.h>
 #include <linux/syscalls.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 /* Since we effect priority and affinity (both of which are visible
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/lib/reed_solomon/reed_solomon.c linux-2.6.15-rc5-mutex/lib/reed_solomon/reed_solomon.c
--- /warthog/kernels/linux-2.6.15-rc5/lib/reed_solomon/reed_solomon.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/lib/reed_solomon/reed_solomon.c	2005-12-12 22:12:50.000000000 +0000
@@ -44,7 +44,7 @@
 #include <linux/module.h>
 #include <linux/rslib.h>
 #include <linux/slab.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* This list holds all currently allocated rs control structures */
 static LIST_HEAD (rslist);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/mm/slab.c linux-2.6.15-rc5-mutex/mm/slab.c
--- /warthog/kernels/linux-2.6.15-rc5/mm/slab.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/mm/slab.c	2005-12-12 17:25:08.000000000 +0000
@@ -631,7 +631,7 @@ static kmem_cache_t cache_cache = {
 };
 
 /* Guard access to the cache-chain. */
-static struct semaphore	cache_chain_sem;
+static struct mutex	cache_chain_sem;
 static struct list_head cache_chain;
 
 /*

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 4/19] MUTEX: FRV arch mutex
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (5 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 5/19] MUTEX: Core kernel changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 15/19] MUTEX: Second set of include changes David Howells
                   ` (25 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch renames the functions of the FRV traditional semaphore
implementation to include "_sem" in their names and to remove the MUTEX macros
that are now provided by the new mutex facility.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-frv-2615rc5.diff
 arch/frv/kernel/frv_ksyms.c |    2 +-
 arch/frv/kernel/semaphore.c |   24 ++++++++++++------------
 include/asm-frv/semaphore.h |   35 +++++++++++------------------------
 3 files changed, 24 insertions(+), 37 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/asm-frv/semaphore.h linux-2.6.15-rc5-mutex/include/asm-frv/semaphore.h
--- /warthog/kernels/linux-2.6.15-rc5/include/asm-frv/semaphore.h	2005-12-08 16:23:52.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/asm-frv/semaphore.h	2005-12-12 19:26:43.000000000 +0000
@@ -50,29 +50,16 @@ struct semaphore {
 #define __DECLARE_SEMAPHORE_GENERIC(name,count) \
 	struct semaphore name = __SEMAPHORE_INITIALIZER(name,count)
 
-#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name,1)
-#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0)
-
 static inline void sema_init (struct semaphore *sem, int val)
 {
 	*sem = (struct semaphore) __SEMAPHORE_INITIALIZER(*sem, val);
 }
 
-static inline void init_MUTEX (struct semaphore *sem)
-{
-	sema_init(sem, 1);
-}
-
-static inline void init_MUTEX_LOCKED (struct semaphore *sem)
-{
-	sema_init(sem, 0);
-}
-
-extern void __down(struct semaphore *sem, unsigned long flags);
-extern int  __down_interruptible(struct semaphore *sem, unsigned long flags);
-extern void __up(struct semaphore *sem);
+extern void __down_sem(struct semaphore *sem, unsigned long flags);
+extern int  __down_sem_interruptible(struct semaphore *sem, unsigned long flags);
+extern void __up_sem(struct semaphore *sem);
 
-static inline void down(struct semaphore *sem)
+static inline void down_sem(struct semaphore *sem)
 {
 	unsigned long flags;
 
@@ -86,11 +73,11 @@ static inline void down(struct semaphore
 		spin_unlock_irqrestore(&sem->wait_lock, flags);
 	}
 	else {
-		__down(sem, flags);
+		__down_sem(sem, flags);
 	}
 }
 
-static inline int down_interruptible(struct semaphore *sem)
+static inline int down_sem_interruptible(struct semaphore *sem)
 {
 	unsigned long flags;
 	int ret = 0;
@@ -105,16 +92,16 @@ static inline int down_interruptible(str
 		spin_unlock_irqrestore(&sem->wait_lock, flags);
 	}
 	else {
-		ret = __down_interruptible(sem, flags);
+		ret = __down_sem_interruptible(sem, flags);
 	}
 	return ret;
 }
 
 /*
- * non-blockingly attempt to down() a semaphore.
+ * non-blockingly attempt to down_sem() a semaphore.
  * - returns zero if we acquired it
  */
-static inline int down_trylock(struct semaphore *sem)
+static inline int down_sem_trylock(struct semaphore *sem)
 {
 	unsigned long flags;
 	int success = 0;
@@ -132,7 +119,7 @@ static inline int down_trylock(struct se
 	return !success;
 }
 
-static inline void up(struct semaphore *sem)
+static inline void up_sem(struct semaphore *sem)
 {
 	unsigned long flags;
 
@@ -142,7 +129,7 @@ static inline void up(struct semaphore *
 
 	spin_lock_irqsave(&sem->wait_lock, flags);
 	if (!list_empty(&sem->wait_list))
-		__up(sem);
+		__up_sem(sem);
 	else
 		sem->counter++;
 	spin_unlock_irqrestore(&sem->wait_lock, flags);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/frv/kernel/frv_ksyms.c linux-2.6.15-rc5-mutex/arch/frv/kernel/frv_ksyms.c
--- /warthog/kernels/linux-2.6.15-rc5/arch/frv/kernel/frv_ksyms.c	2005-11-01 13:18:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/arch/frv/kernel/frv_ksyms.c	2005-12-12 22:08:19.000000000 +0000
@@ -13,7 +13,7 @@
 #include <asm/pgalloc.h>
 #include <asm/irq.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/checksum.h>
 #include <asm/hardirq.h>
 #include <asm/current.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/arch/frv/kernel/semaphore.c linux-2.6.15-rc5-mutex/arch/frv/kernel/semaphore.c
--- /warthog/kernels/linux-2.6.15-rc5/arch/frv/kernel/semaphore.c	2005-12-08 16:23:32.000000000 +0000
+++ linux-2.6.15-rc5-mutex/arch/frv/kernel/semaphore.c	2005-12-12 19:26:25.000000000 +0000
@@ -38,12 +38,12 @@ void semtrace(struct semaphore *sem, con
  * wait for a token to be granted from a semaphore
  * - entered with lock held and interrupts disabled
  */
-void __down(struct semaphore *sem, unsigned long flags)
+void __down_sem(struct semaphore *sem, unsigned long flags)
 {
 	struct task_struct *tsk = current;
 	struct sem_waiter waiter;
 
-	semtrace(sem, "Entering __down");
+	semtrace(sem, "Entering __down_sem");
 
 	/* set up my own style of waitqueue */
 	waiter.task = tsk;
@@ -65,22 +65,22 @@ void __down(struct semaphore *sem, unsig
 	}
 
 	tsk->state = TASK_RUNNING;
-	semtrace(sem, "Leaving __down");
+	semtrace(sem, "Leaving __down_sem");
 }
 
-EXPORT_SYMBOL(__down);
+EXPORT_SYMBOL(__down_sem);
 
 /*
  * interruptibly wait for a token to be granted from a semaphore
  * - entered with lock held and interrupts disabled
  */
-int __down_interruptible(struct semaphore *sem, unsigned long flags)
+int __down_sem_interruptible(struct semaphore *sem, unsigned long flags)
 {
 	struct task_struct *tsk = current;
 	struct sem_waiter waiter;
 	int ret;
 
-	semtrace(sem,"Entering __down_interruptible");
+	semtrace(sem,"Entering __down_sem_interruptible");
 
 	/* set up my own style of waitqueue */
 	waiter.task = tsk;
@@ -106,7 +106,7 @@ int __down_interruptible(struct semaphor
 
  out:
 	tsk->state = TASK_RUNNING;
-	semtrace(sem, "Leaving __down_interruptible");
+	semtrace(sem, "Leaving __down_sem_interruptible");
 	return ret;
 
  interrupted:
@@ -123,18 +123,18 @@ int __down_interruptible(struct semaphor
 	goto out;
 }
 
-EXPORT_SYMBOL(__down_interruptible);
+EXPORT_SYMBOL(__down_sem_interruptible);
 
 /*
  * release a single token back to a semaphore
  * - entered with lock held and interrupts disabled
  */
-void __up(struct semaphore *sem)
+void __up_sem(struct semaphore *sem)
 {
 	struct task_struct *tsk;
 	struct sem_waiter *waiter;
 
-	semtrace(sem,"Entering __up");
+	semtrace(sem,"Entering __up_sem");
 
 	/* grant the token to the process at the front of the queue */
 	waiter = list_entry(sem->wait_list.next, struct sem_waiter, list);
@@ -150,7 +150,7 @@ void __up(struct semaphore *sem)
 	wake_up_process(tsk);
 	put_task_struct(tsk);
 
-	semtrace(sem,"Leaving __up");
+	semtrace(sem,"Leaving __up_sem");
 }
 
-EXPORT_SYMBOL(__up);
+EXPORT_SYMBOL(__up_sem);

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 6/19] MUTEX: Drivers A-E changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (2 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 7/19] MUTEX: Drivers F-H changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 3/19] MUTEX: x86_64 arch mutex David Howells
                   ` (28 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/a* thru drivers/e* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-AtoE-2615rc5.diff
 drivers/acpi/ec.c                   |    2 +-
 drivers/acpi/osl.c                  |   10 +++++-----
 drivers/acpi/video.c                |    2 +-
 drivers/atm/ambassador.h            |    2 +-
 drivers/atm/fore200e.h              |    2 +-
 drivers/atm/idt77252.c              |    2 +-
 drivers/atm/idt77252.h              |    2 +-
 drivers/base/core.c                 |    2 +-
 drivers/base/firmware_class.c       |    2 +-
 drivers/base/map.c                  |    6 +++---
 drivers/base/power/power.h          |    4 ++--
 drivers/base/power/shutdown.c       |    2 +-
 drivers/base/sys.c                  |    2 +-
 drivers/block/aoe/aoechr.c          |    4 ++--
 drivers/block/cryptoloop.c          |    2 +-
 drivers/block/pktcdvd.c             |    2 +-
 drivers/block/sx8.c                 |    4 ++--
 drivers/char/agp/frontend.c         |    2 +-
 drivers/char/drm/drmP.h             |    4 ++--
 drivers/char/drm/drm_stub.c         |    4 ++--
 drivers/char/generic_serial.c       |    2 +-
 drivers/char/ipmi/ipmi_devintf.c    |    6 +++---
 drivers/char/ipmi/ipmi_msghandler.c |    2 +-
 drivers/char/mbcs.h                 |    6 +++---
 drivers/char/moxa.c                 |    2 +-
 drivers/char/rio/rioboot.c          |    2 +-
 drivers/char/rio/riocmd.c           |    2 +-
 drivers/char/rio/rioctrl.c          |    2 +-
 drivers/char/rio/rioinit.c          |    2 +-
 drivers/char/rio/riointr.c          |    2 +-
 drivers/char/rio/rioparam.c         |    2 +-
 drivers/char/rio/rioroute.c         |    2 +-
 drivers/char/rio/riotable.c         |    2 +-
 drivers/char/rio/riotty.c           |    2 +-
 drivers/char/rocket.c               |    4 ++--
 drivers/char/rocket_int.h           |    2 +-
 drivers/char/ser_a2232.c            |    2 +-
 drivers/char/snsc.c                 |    4 ++--
 drivers/char/snsc.h                 |    6 +++---
 drivers/char/sonypi.c               |    2 +-
 drivers/char/tpm/tpm.h              |    4 ++--
 drivers/char/tty_io.c               |    4 ++--
 drivers/char/viotape.c              |   20 ++++++++++----------
 drivers/char/watchdog/cpu5wdt.c     |    2 +-
 drivers/char/watchdog/pcwd_usb.c    |    2 +-
 drivers/char/watchdog/sc1200wdt.c   |    6 +++---
 drivers/char/watchdog/scx200_wdt.c  |    4 ++--
 drivers/char/watchdog/wdt_pci.c     |    4 ++--
 48 files changed, 82 insertions(+), 82 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/acpi/ec.c linux-2.6.15-rc5-mutex/drivers/acpi/ec.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/acpi/ec.c	2005-11-01 13:19:04.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/acpi/ec.c	2005-12-12 17:40:34.000000000 +0000
@@ -103,7 +103,7 @@ union acpi_ec {
 		unsigned int expect_event;
 		atomic_t leaving_burst;	/* 0 : No, 1 : Yes, 2: abort */
 		atomic_t pending_gpe;
-		struct semaphore sem;
+		struct mutex sem;
 		wait_queue_head_t wait;
 	} burst;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/acpi/osl.c linux-2.6.15-rc5-mutex/drivers/acpi/osl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/acpi/osl.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/acpi/osl.c	2005-12-12 17:49:01.000000000 +0000
@@ -813,7 +813,7 @@ acpi_status acpi_os_wait_semaphore(acpi_
 		 * (a.k.a. 'would block').
 		 */
 	case 0:
-		if (down_trylock(sem))
+		if (down_sem_trylock(sem))
 			status = AE_TIME;
 		break;
 
@@ -822,7 +822,7 @@ acpi_status acpi_os_wait_semaphore(acpi_
 		 * ------------------
 		 */
 	case ACPI_WAIT_FOREVER:
-		down(sem);
+		down_sem(sem);
 		break;
 
 		/*
@@ -835,10 +835,10 @@ acpi_status acpi_os_wait_semaphore(acpi_
 			int i = 0;
 			static const int quantum_ms = 1000 / HZ;
 
-			ret = down_trylock(sem);
+			ret = down_sem_trylock(sem);
 			for (i = timeout; (i > 0 && ret < 0); i -= quantum_ms) {
 				schedule_timeout_interruptible(1);
-				ret = down_trylock(sem);
+				ret = down_sem_trylock(sem);
 			}
 
 			if (ret != 0)
@@ -881,7 +881,7 @@ acpi_status acpi_os_signal_semaphore(acp
 	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "Signaling semaphore[%p|%d]\n", handle,
 			  units));
 
-	up(sem);
+	up_sem(sem);
 
 	return_ACPI_STATUS(AE_OK);
 }
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/acpi/video.c linux-2.6.15-rc5-mutex/drivers/acpi/video.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/acpi/video.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/acpi/video.c	2005-12-12 21:13:16.000000000 +0000
@@ -123,7 +123,7 @@ struct acpi_video_bus {
 	u8 attached_count;
 	struct acpi_video_bus_cap cap;
 	struct acpi_video_bus_flags flags;
-	struct semaphore sem;
+	struct mutex sem;
 	struct list_head video_device_list;
 	struct proc_dir_entry *dir;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/atm/ambassador.h linux-2.6.15-rc5-mutex/drivers/atm/ambassador.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/atm/ambassador.h	2005-06-22 13:51:45.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/atm/ambassador.h	2005-12-12 20:59:29.000000000 +0000
@@ -639,7 +639,7 @@ struct amb_dev {
   amb_txq          txq;
   amb_rxq          rxq[NUM_RX_POOLS];
   
-  struct semaphore vcc_sf;
+  struct mutex     vcc_sf;
   amb_tx_info      txer[NUM_VCS];
   struct atm_vcc * rxer[NUM_VCS];
   unsigned int     tx_avail;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/atm/fore200e.h linux-2.6.15-rc5-mutex/drivers/atm/fore200e.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/atm/fore200e.h	2005-06-22 13:51:45.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/atm/fore200e.h	2005-12-12 20:59:38.000000000 +0000
@@ -870,7 +870,7 @@ typedef struct fore200e {
 
     struct stats*              stats;                  /* last snapshot of the stats         */
     
-    struct semaphore           rate_sf;                /* protects rate reservation ops      */
+    struct mutex               rate_sf;                /* protects rate reservation ops      */
     spinlock_t                 q_lock;                 /* protects queue ops                 */
 #ifdef FORE200E_USE_TASKLET
     struct tasklet_struct      tx_tasklet;             /* performs tx interrupt work         */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/atm/idt77252.c linux-2.6.15-rc5-mutex/drivers/atm/idt77252.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/atm/idt77252.c	2005-11-01 13:19:04.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/atm/idt77252.c	2005-12-12 22:12:50.000000000 +0000
@@ -47,7 +47,7 @@ static char const rcsid[] =
 #include <linux/bitops.h>
 #include <linux/wait.h>
 #include <linux/jiffies.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
 #include <asm/atomic.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/atm/idt77252.h linux-2.6.15-rc5-mutex/drivers/atm/idt77252.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/atm/idt77252.h	2005-03-02 12:08:03.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/atm/idt77252.h	2005-12-12 20:59:11.000000000 +0000
@@ -359,7 +359,7 @@ struct idt77252_dev
 	unsigned long		srambase;	/* SAR's sram  base address */
 	void __iomem		*fbq[4];	/* FBQ fill addresses */
 
-	struct semaphore	mutex;
+	struct mutex		mutex;
 	spinlock_t		cmd_lock;	/* for r/w utility/sram */
 
 	unsigned long		softstat;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/base/core.c linux-2.6.15-rc5-mutex/drivers/base/core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/base/core.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/base/core.c	2005-12-12 22:12:49.000000000 +0000
@@ -16,7 +16,7 @@
 #include <linux/slab.h>
 #include <linux/string.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "base.h"
 #include "power/power.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/base/firmware_class.c linux-2.6.15-rc5-mutex/drivers/base/firmware_class.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/base/firmware_class.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/base/firmware_class.c	2005-12-12 22:12:49.000000000 +0000
@@ -14,7 +14,7 @@
 #include <linux/vmalloc.h>
 #include <linux/interrupt.h>
 #include <linux/bitops.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/firmware.h>
 #include "base.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/base/map.c linux-2.6.15-rc5-mutex/drivers/base/map.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/base/map.c	2005-11-01 13:19:05.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/base/map.c	2005-12-12 17:42:33.000000000 +0000
@@ -25,7 +25,7 @@ struct kobj_map {
 		int (*lock)(dev_t, void *);
 		void *data;
 	} *probes[255];
-	struct semaphore *sem;
+	struct mutex *sem;
 };
 
 int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
@@ -132,7 +132,7 @@ retry:
 	return NULL;
 }
 
-struct kobj_map *kobj_map_init(kobj_probe_t *base_probe, struct semaphore *sem)
+struct kobj_map *kobj_map_init(kobj_probe_t *base_probe, struct mutex *mutex)
 {
 	struct kobj_map *p = kmalloc(sizeof(struct kobj_map), GFP_KERNEL);
 	struct probe *base = kzalloc(sizeof(*base), GFP_KERNEL);
@@ -149,6 +149,6 @@ struct kobj_map *kobj_map_init(kobj_prob
 	base->get = base_probe;
 	for (i = 0; i < 255; i++)
 		p->probes[i] = base;
-	p->sem = sem;
+	p->sem = mutex;
 	return p;
 }
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/base/power/power.h linux-2.6.15-rc5-mutex/drivers/base/power/power.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/base/power/power.h	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/base/power/power.h	2005-12-12 17:44:20.000000000 +0000
@@ -14,12 +14,12 @@ extern void device_shutdown(void);
 /*
  * Used to synchronize global power management operations.
  */
-extern struct semaphore dpm_sem;
+extern struct mutex dpm_sem;
 
 /*
  * Used to serialize changes to the dpm_* lists.
  */
-extern struct semaphore dpm_list_sem;
+extern struct mutex dpm_list_sem;
 
 /*
  * The PM lists.
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/base/power/shutdown.c linux-2.6.15-rc5-mutex/drivers/base/power/shutdown.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/base/power/shutdown.c	2005-06-22 13:51:45.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/base/power/shutdown.c	2005-12-12 22:12:49.000000000 +0000
@@ -10,7 +10,7 @@
 
 #include <linux/config.h>
 #include <linux/device.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "power.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/base/sys.c linux-2.6.15-rc5-mutex/drivers/base/sys.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/base/sys.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/base/sys.c	2005-12-12 22:12:49.000000000 +0000
@@ -21,7 +21,7 @@
 #include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/pm.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 extern struct subsystem devices_subsys;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/block/aoe/aoechr.c linux-2.6.15-rc5-mutex/drivers/block/aoe/aoechr.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/block/aoe/aoechr.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/block/aoe/aoechr.c	2005-12-12 21:28:14.000000000 +0000
@@ -96,7 +96,7 @@ bail:		spin_unlock_irqrestore(&emsgs_loc
 	spin_unlock_irqrestore(&emsgs_lock, flags);
 
 	if (nblocked_emsgs_readers)
-		up(&emsgs_sema);
+		up_sem(&emsgs_sema);
 }
 
 static ssize_t
@@ -164,7 +164,7 @@ loop:
 
 			spin_unlock_irqrestore(&emsgs_lock, flags);
 
-			n = down_interruptible(&emsgs_sema);
+			n = down_sem_interruptible(&emsgs_sema);
 
 			spin_lock_irqsave(&emsgs_lock, flags);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/block/cryptoloop.c linux-2.6.15-rc5-mutex/drivers/block/cryptoloop.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/block/cryptoloop.c	2005-11-01 13:19:05.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/block/cryptoloop.c	2005-12-12 22:08:48.000000000 +0000
@@ -26,7 +26,7 @@
 #include <linux/crypto.h>
 #include <linux/blkdev.h>
 #include <linux/loop.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 MODULE_LICENSE("GPL");
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/block/pktcdvd.c linux-2.6.15-rc5-mutex/drivers/block/pktcdvd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/block/pktcdvd.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/block/pktcdvd.c	2005-12-12 21:28:17.000000000 +0000
@@ -82,7 +82,7 @@
 static struct pktcdvd_device *pkt_devs[MAX_WRITERS];
 static struct proc_dir_entry *pkt_proc;
 static int pkt_major;
-static struct semaphore ctl_mutex;	/* Serialize open/close/setup/teardown */
+static struct mutex ctl_mutex;	/* Serialize open/close/setup/teardown */
 static mempool_t *psd_pool;
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/block/sx8.c linux-2.6.15-rc5-mutex/drivers/block/sx8.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/block/sx8.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/block/sx8.c	2005-12-12 22:08:48.000000000 +0000
@@ -28,7 +28,7 @@
 #include <linux/hdreg.h>
 #include <linux/dma-mapping.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #if 0
@@ -303,7 +303,7 @@ struct carm_host {
 
 	struct work_struct		fsm_task;
 
-	struct semaphore		probe_sem;
+	struct mutex			probe_sem;
 };
 
 struct carm_response {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/agp/frontend.c linux-2.6.15-rc5-mutex/drivers/char/agp/frontend.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/agp/frontend.c	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/agp/frontend.c	2005-12-12 20:15:38.000000000 +0000
@@ -1081,7 +1081,7 @@ static struct miscdevice agp_miscdev =
 int agp_frontend_initialize(void)
 {
 	memset(&agp_fe, 0, sizeof(struct agp_front_data));
-	sema_init(&(agp_fe.agp_mutex), 1);
+	init_MUTEX(&(agp_fe.agp_mutex));
 
 	if (misc_register(&agp_miscdev)) {
 		printk(KERN_ERR PFX "unable to get minor: %d\n", AGPGART_MINOR);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/drm/drmP.h linux-2.6.15-rc5-mutex/drivers/char/drm/drmP.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/drm/drmP.h	2005-12-08 16:23:38.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/drm/drmP.h	2005-12-12 20:17:29.000000000 +0000
@@ -625,7 +625,7 @@ typedef struct drm_device {
 	/** \name Locks */
 	/*@{ */
 	spinlock_t count_lock;		/**< For inuse, drm_device::open_count, drm_device::buf_use */
-	struct semaphore struct_sem;	/**< For others */
+	struct mutex struct_sem;	/**< For others */
 	/*@} */
 
 	/** \name Usage Counters */
@@ -660,7 +660,7 @@ typedef struct drm_device {
 	/*@{ */
 	drm_ctx_list_t *ctxlist;	/**< Linked list of context handles */
 	int ctx_count;			/**< Number of context handles */
-	struct semaphore ctxlist_sem;	/**< For ctxlist */
+	struct mutex ctxlist_sem;	/**< For ctxlist */
 
 	drm_map_t **context_sareas;	    /**< per-context SAREA's */
 	int max_context;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/drm/drm_stub.c linux-2.6.15-rc5-mutex/drivers/char/drm/drm_stub.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/drm/drm_stub.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/drm/drm_stub.c	2005-12-12 20:24:32.000000000 +0000
@@ -61,8 +61,8 @@ static int drm_fill_in_dev(drm_device_t 
 
 	spin_lock_init(&dev->count_lock);
 	init_timer(&dev->timer);
-	sema_init(&dev->struct_sem, 1);
-	sema_init(&dev->ctxlist_sem, 1);
+	init_MUTEX(&dev->struct_sem);
+	init_MUTEX(&dev->ctxlist_sem);
 
 	dev->pdev = pdev;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/generic_serial.c linux-2.6.15-rc5-mutex/drivers/char/generic_serial.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/generic_serial.c	2005-06-22 13:51:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/generic_serial.c	2005-12-12 22:08:48.000000000 +0000
@@ -28,7 +28,7 @@
 #include <linux/interrupt.h>
 #include <linux/tty_flip.h>
 #include <linux/delay.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #define DEBUG 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/ipmi/ipmi_devintf.c linux-2.6.15-rc5-mutex/drivers/char/ipmi/ipmi_devintf.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/ipmi/ipmi_devintf.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/ipmi/ipmi_devintf.c	2005-12-12 22:08:48.000000000 +0000
@@ -42,7 +42,7 @@
 #include <linux/slab.h>
 #include <linux/devfs_fs_kernel.h>
 #include <linux/ipmi.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/compat.h>
@@ -55,7 +55,7 @@ struct ipmi_file_private
 	struct file          *file;
 	struct fasync_struct *fasync_queue;
 	wait_queue_head_t    wait;
-	struct semaphore     recv_sem;
+	struct mutex         recv_sem;
 	int                  default_retries;
 	unsigned int         default_retry_time_ms;
 };
@@ -141,7 +141,7 @@ static int ipmi_open(struct inode *inode
 	INIT_LIST_HEAD(&(priv->recv_msgs));
 	init_waitqueue_head(&priv->wait);
 	priv->fasync_queue = NULL;
-	sema_init(&(priv->recv_sem), 1);
+	init_MUTEX(&(priv->recv_sem));
 
 	/* Use the low-level defaults. */
 	priv->default_retries = -1;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/ipmi/ipmi_msghandler.c linux-2.6.15-rc5-mutex/drivers/char/ipmi/ipmi_msghandler.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/ipmi/ipmi_msghandler.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/ipmi/ipmi_msghandler.c	2005-12-12 21:30:10.000000000 +0000
@@ -209,7 +209,7 @@ struct ipmi_smi
 
 	/* The list of command receivers that are registered for commands
 	   on this interface. */
-	struct semaphore cmd_rcvrs_lock;
+	struct mutex     cmd_rcvrs_lock;
 	struct list_head cmd_rcvrs;
 
 	/* Events that were queues because no one was there to receive
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/mbcs.h linux-2.6.15-rc5-mutex/drivers/char/mbcs.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/mbcs.h	2005-06-22 13:51:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/mbcs.h	2005-12-12 21:29:18.000000000 +0000
@@ -537,9 +537,9 @@ struct mbcs_soft {
 	atomic_t dmawrite_done;
 	atomic_t dmaread_done;
 	atomic_t algo_done;
-	struct semaphore dmawritelock;
-	struct semaphore dmareadlock;
-	struct semaphore algolock;
+	struct mutex dmawritelock;
+	struct mutex dmareadlock;
+	struct mutex algolock;
 };
 
 extern int mbcs_open(struct inode *ip, struct file *fp);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/moxa.c linux-2.6.15-rc5-mutex/drivers/char/moxa.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/moxa.c	2005-11-01 13:19:06.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/moxa.c	2005-12-12 21:29:08.000000000 +0000
@@ -216,7 +216,7 @@ static int moxaTimer_on;
 static struct timer_list moxaTimer;
 static int moxaEmptyTimer_on[MAX_PORTS];
 static struct timer_list moxaEmptyTimer[MAX_PORTS];
-static struct semaphore moxaBuffSem;
+static struct mutex moxaBuffSem;
 
 /*
  * static functions:
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioboot.c linux-2.6.15-rc5-mutex/drivers/char/rio/rioboot.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioboot.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/rioboot.c	2005-12-12 22:08:48.000000000 +0000
@@ -41,7 +41,7 @@ static char *_rioboot_c_sccs_ = "@(#)rio
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riocmd.c linux-2.6.15-rc5-mutex/drivers/char/rio/riocmd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riocmd.c	2005-06-22 13:51:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/riocmd.c	2005-12-12 22:08:48.000000000 +0000
@@ -41,7 +41,7 @@ static char *_riocmd_c_sccs_ = "@(#)rioc
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/termios.h>
 #include <linux/serial.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioctrl.c linux-2.6.15-rc5-mutex/drivers/char/rio/rioctrl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioctrl.c	2005-03-02 12:08:06.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/rioctrl.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@ static char *_rioctrl_c_sccs_ = "@(#)rio
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioinit.c linux-2.6.15-rc5-mutex/drivers/char/rio/rioinit.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioinit.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/rioinit.c	2005-12-12 22:08:48.000000000 +0000
@@ -41,7 +41,7 @@ static char *_rioinit_c_sccs_ = "@(#)rio
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riointr.c linux-2.6.15-rc5-mutex/drivers/char/rio/riointr.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riointr.c	2005-03-02 12:08:06.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/riointr.c	2005-12-12 22:08:48.000000000 +0000
@@ -41,7 +41,7 @@ static char *_riointr_c_sccs_ = "@(#)rio
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioparam.c linux-2.6.15-rc5-mutex/drivers/char/rio/rioparam.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioparam.c	2004-06-18 13:41:42.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/rioparam.c	2005-12-12 22:08:48.000000000 +0000
@@ -41,7 +41,7 @@ static char *_rioparam_c_sccs_ = "@(#)ri
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioroute.c linux-2.6.15-rc5-mutex/drivers/char/rio/rioroute.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/rioroute.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/rioroute.c	2005-12-12 22:08:48.000000000 +0000
@@ -39,7 +39,7 @@ static char *_rioroute_c_sccs_ = "@(#)ri
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riotable.c linux-2.6.15-rc5-mutex/drivers/char/rio/riotable.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riotable.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/riotable.c	2005-12-12 22:08:48.000000000 +0000
@@ -42,7 +42,7 @@ static char *_riotable_c_sccs_ = "@(#)ri
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riotty.c linux-2.6.15-rc5-mutex/drivers/char/rio/riotty.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rio/riotty.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rio/riotty.c	2005-12-12 22:08:48.000000000 +0000
@@ -44,7 +44,7 @@ static char *_riotty_c_sccs_ = "@(#)riot
 #include <asm/io.h>
 #include <asm/system.h>
 #include <asm/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <linux/termios.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rocket.c linux-2.6.15-rc5-mutex/drivers/char/rocket.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rocket.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/rocket.c	2005-12-12 22:08:48.000000000 +0000
@@ -93,7 +93,7 @@
 #include <asm/atomic.h>
 #include <linux/bitops.h>
 #include <linux/spinlock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/init.h>
 
 /****** RocketPort includes ******/
@@ -716,7 +716,7 @@ static void init_r_port(int board, int a
 		}
 	}
 	spin_lock_init(&info->slock);
-	sema_init(&info->write_sem, 1);
+	init_MUTEX(&info->write_sem);
 	rp_table[line] = info;
 	if (pci_dev)
 		tty_register_device(rocket_driver, line, &pci_dev->dev);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/rocket_int.h linux-2.6.15-rc5-mutex/drivers/char/rocket_int.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/rocket_int.h	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/rocket_int.h	2005-12-12 20:15:24.000000000 +0000
@@ -1171,7 +1171,7 @@ struct r_port {
 	struct wait_queue *close_wait;
 #endif
 	spinlock_t slock;
-	struct semaphore write_sem;
+	struct mutex write_sem;
 };
 
 #define RPORT_MAGIC 0x525001
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/ser_a2232.c linux-2.6.15-rc5-mutex/drivers/char/ser_a2232.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/ser_a2232.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/ser_a2232.c	2005-12-12 22:08:48.000000000 +0000
@@ -97,7 +97,7 @@
 #include <asm/amigahw.h>
 #include <linux/zorro.h>
 #include <asm/irq.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/delay.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/snsc.c linux-2.6.15-rc5-mutex/drivers/char/snsc.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/snsc.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/snsc.c	2005-12-12 20:16:07.000000000 +0000
@@ -99,8 +99,8 @@ scdrv_open(struct inode *inode, struct f
 	spin_lock_init(&sd->sd_wlock);
 	init_waitqueue_head(&sd->sd_rq);
 	init_waitqueue_head(&sd->sd_wq);
-	sema_init(&sd->sd_rbs, 1);
-	sema_init(&sd->sd_wbs, 1);
+	init_MUTEX(&sd->sd_rbs);
+	init_MUTEX(&sd->sd_wbs);
 
 	file->private_data = sd;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/snsc.h linux-2.6.15-rc5-mutex/drivers/char/snsc.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/snsc.h	2005-06-22 13:51:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/snsc.h	2005-12-12 22:12:49.000000000 +0000
@@ -22,8 +22,8 @@
 #include <linux/kobject.h>
 #include <linux/fs.h>
 #include <linux/cdev.h>
+#include <linux/semaphore.h>
 #include <asm/sn/types.h>
-#include <asm/semaphore.h>
 
 #define CHUNKSIZE 127
 
@@ -35,8 +35,8 @@ struct subch_data_s {
 	spinlock_t sd_wlock;	/* monitor lock for wsv */
 	wait_queue_head_t sd_rq;	/* wait queue for readers */
 	wait_queue_head_t sd_wq;	/* wait queue for writers */
-	struct semaphore sd_rbs;	/* semaphore for read buffer */
-	struct semaphore sd_wbs;	/* semaphore for write buffer */
+	struct mutex sd_rbs;	/* semaphore for read buffer */
+	struct mutex sd_wbs;	/* semaphore for write buffer */
 
 	char sd_rb[CHUNKSIZE];	/* read buffer */
 	char sd_wb[CHUNKSIZE];	/* write buffer */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/sonypi.c linux-2.6.15-rc5-mutex/drivers/char/sonypi.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/sonypi.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/sonypi.c	2005-12-12 21:28:40.000000000 +0000
@@ -480,7 +480,7 @@ static struct sonypi_device {
 	u16 evtype_offset;
 	int camera_power;
 	int bluetooth_power;
-	struct semaphore lock;
+	struct mutex lock;
 	struct kfifo *fifo;
 	spinlock_t fifo_lock;
 	wait_queue_head_t fifo_proc_list;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/tpm/tpm.h linux-2.6.15-rc5-mutex/drivers/char/tpm/tpm.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/tpm/tpm.h	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/tpm/tpm.h	2005-12-12 21:28:57.000000000 +0000
@@ -74,11 +74,11 @@ struct tpm_chip {
 	/* Data passed to and from the tpm via the read/write calls */
 	u8 *data_buffer;
 	atomic_t data_pending;
-	struct semaphore buffer_mutex;
+	struct mutex buffer_mutex;
 
 	struct timer_list user_read_timer;	/* user needs to claim result */
 	struct work_struct work;
-	struct semaphore tpm_mutex;	/* tpm is processing */
+	struct mutex tpm_mutex;	/* tpm is processing */
 
 	struct tpm_vendor_specific *vendor;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/tty_io.c linux-2.6.15-rc5-mutex/drivers/char/tty_io.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/tty_io.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/tty_io.c	2005-12-12 17:48:17.000000000 +0000
@@ -2677,8 +2677,8 @@ static void initialize_tty_struct(struct
 	init_waitqueue_head(&tty->write_wait);
 	init_waitqueue_head(&tty->read_wait);
 	INIT_WORK(&tty->hangup_work, do_tty_hangup, tty);
-	sema_init(&tty->atomic_read, 1);
-	sema_init(&tty->atomic_write, 1);
+	init_MUTEX(&tty->atomic_read);
+	init_MUTEX(&tty->atomic_write);
 	spin_lock_init(&tty->read_lock);
 	INIT_LIST_HEAD(&tty->tty_files);
 	INIT_WORK(&tty->SAK_work, NULL, NULL);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/viotape.c linux-2.6.15-rc5-mutex/drivers/char/viotape.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/viotape.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/viotape.c	2005-12-12 20:20:37.000000000 +0000
@@ -454,12 +454,12 @@ static ssize_t viotap_write(struct file 
 	 * semaphore
 	 */
 	if (noblock) {
-		if (down_trylock(&reqSem)) {
+		if (down_sem_trylock(&reqSem)) {
 			ret = -EWOULDBLOCK;
 			goto free_op;
 		}
 	} else
-		down(&reqSem);
+		down_sem(&reqSem);
 
 	/* Allocate a DMA buffer */
 	op->dev = tape_device[devi.devno];
@@ -515,7 +515,7 @@ static ssize_t viotap_write(struct file 
 free_dma:
 	dma_free_coherent(op->dev, count, op->buffer, op->dmaaddr);
 up_sem:
-	up(&reqSem);
+	up_sem(&reqSem);
 free_op:
 	free_op_struct(op);
 	return ret;
@@ -544,12 +544,12 @@ static ssize_t viotap_read(struct file *
 	 * semaphore
 	 */
 	if (noblock) {
-		if (down_trylock(&reqSem)) {
+		if (down_sem_trylock(&reqSem)) {
 			ret = -EWOULDBLOCK;
 			goto free_op;
 		}
 	} else
-		down(&reqSem);
+		down_sem(&reqSem);
 
 	chg_state(devi.devno, VIOT_READING, file);
 
@@ -595,7 +595,7 @@ static ssize_t viotap_read(struct file *
 free_dma:
 	dma_free_coherent(op->dev, count, op->buffer, op->dmaaddr);
 up_sem:
-	up(&reqSem);
+	up_sem(&reqSem);
 free_op:
 	free_op_struct(op);
 	return ret;
@@ -617,7 +617,7 @@ static int viotap_ioctl(struct inode *in
 
 	get_dev_info(file->f_dentry->d_inode, &devi);
 
-	down(&reqSem);
+	down_sem(&reqSem);
 
 	ret = -EINVAL;
 
@@ -748,7 +748,7 @@ static int viotap_ioctl(struct inode *in
 		/* Operation is complete - grab the error code */
 		ret = tape_rc_to_errno(op->rc, "get status", devi.devno);
 		free_op_struct(op);
-		up(&reqSem);
+		up_sem(&reqSem);
 
 		if ((ret == 0) && copy_to_user((void *)arg,
 					&viomtget[devi.devno],
@@ -766,7 +766,7 @@ static int viotap_ioctl(struct inode *in
 
 free_op:
 	free_op_struct(op);
-	up(&reqSem);
+	up_sem(&reqSem);
 	return ret;
 }
 
@@ -918,7 +918,7 @@ static void vioHandleTapeEvent(struct Hv
 			dma_free_coherent(op->dev, op->count,
 					op->buffer, op->dmaaddr);
 			free_op_struct(op);
-			up(&reqSem);
+			up_sem(&reqSem);
 		} else {
 			op->rc = tevent->sub_type_result;
 			op->count = tevent->len;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/cpu5wdt.c linux-2.6.15-rc5-mutex/drivers/char/watchdog/cpu5wdt.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/cpu5wdt.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/watchdog/cpu5wdt.c	2005-12-12 21:29:41.000000000 +0000
@@ -57,7 +57,7 @@ static int ticks = 10000;
 /* some device data */
 
 static struct {
-	struct semaphore stop;
+	struct mutex stop;
 	volatile int running;
 	struct timer_list timer;
 	volatile int queue;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/pcwd_usb.c linux-2.6.15-rc5-mutex/drivers/char/watchdog/pcwd_usb.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/pcwd_usb.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/watchdog/pcwd_usb.c	2005-12-12 21:29:35.000000000 +0000
@@ -138,7 +138,7 @@ struct usb_pcwd_private {
 	atomic_t		cmd_received;		/* true if we received a report after a command */
 
 	int			exists;			/* Wether or not the device exists */
-	struct semaphore	sem;			/* locks this structure */
+	struct mutex		sem;			/* locks this structure */
 };
 static struct usb_pcwd_private *usb_pcwd_device;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/sc1200wdt.c linux-2.6.15-rc5-mutex/drivers/char/watchdog/sc1200wdt.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/sc1200wdt.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/watchdog/sc1200wdt.c	2005-12-12 22:08:48.000000000 +0000
@@ -41,7 +41,7 @@
 #include <linux/fs.h>
 #include <linux/pci.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
 
@@ -74,7 +74,7 @@ static char banner[] __initdata = KERN_I
 static int timeout = 1;
 static int io = -1;
 static int io_len = 2;		/* for non plug and play */
-static struct semaphore open_sem;
+static struct mutex open_sem;
 static char expect_close;
 static spinlock_t sc1200wdt_lock;	/* io port access serialisation */
 
@@ -380,7 +380,7 @@ static int __init sc1200wdt_init(void)
 	printk(banner);
 
 	spin_lock_init(&sc1200wdt_lock);
-	sema_init(&open_sem, 1);
+	init_MUTEX(&open_sem);
 
 #if defined CONFIG_PNP
 	if (isapnp) {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/scx200_wdt.c linux-2.6.15-rc5-mutex/drivers/char/watchdog/scx200_wdt.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/scx200_wdt.c	2005-11-01 13:19:06.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/char/watchdog/scx200_wdt.c	2005-12-12 20:18:41.000000000 +0000
@@ -48,7 +48,7 @@ module_param(nowayout, int, 0);
 MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close");
 
 static u16 wdto_restart;
-static struct semaphore open_semaphore;
+static struct mutex open_semaphore;
 static char expect_close;
 
 /* Bits of the WDCNFG register */
@@ -230,7 +230,7 @@ static int __init scx200_wdt_init(void)
 	scx200_wdt_update_margin();
 	scx200_wdt_disable();
 
-	sema_init(&open_semaphore, 1);
+	init_MUTEX(&open_semaphore);
 
 	r = misc_register(&scx200_wdt_miscdev);
 	if (r) {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/wdt_pci.c linux-2.6.15-rc5-mutex/drivers/char/watchdog/wdt_pci.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/char/watchdog/wdt_pci.c	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/char/watchdog/wdt_pci.c	2005-12-12 20:18:17.000000000 +0000
@@ -74,7 +74,7 @@
 /* We can only use 1 card due to the /dev/watchdog restriction */
 static int dev_count;
 
-static struct semaphore open_sem;
+static struct mutex open_sem;
 static spinlock_t wdtpci_lock;
 static char expect_close;
 
@@ -607,7 +607,7 @@ static int __devinit wdtpci_init_one (st
 		goto out_pci;
 	}
 
-	sema_init(&open_sem, 1);
+	init_MUTEX(&open_sem);
 	spin_lock_init(&wdtpci_lock);
 
 	irq = dev->irq;

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 8/19] MUTEX: Drivers I-K changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
  2005-12-12 23:45 ` [PATCH 2/19] MUTEX: i386 arch mutex David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 7/19] MUTEX: Drivers F-H changes David Howells
                   ` (30 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/i* thru drivers/k* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-ItoK-2615rc5.diff
 drivers/i2c/busses/i2c-ali1535.c            |    2 +-
 drivers/i2c/busses/i2c-amd756-s4882.c       |    2 +-
 drivers/i2c/busses/scx200_acb.c             |    2 +-
 drivers/i2c/chips/eeprom.c                  |    2 +-
 drivers/i2c/chips/max6875.c                 |    4 ++--
 drivers/i2c/chips/pcf8591.c                 |    2 +-
 drivers/i2c/chips/tps65010.c                |    2 +-
 drivers/ide/ide.c                           |    4 ++--
 drivers/ieee1394/dv1394-private.h           |    2 +-
 drivers/ieee1394/eth1394.c                  |    2 +-
 drivers/ieee1394/hosts.h                    |    2 +-
 drivers/ieee1394/ieee1394_core.c            |    2 +-
 drivers/ieee1394/ieee1394_core.h            |    2 +-
 drivers/ieee1394/ieee1394_types.h           |    2 +-
 drivers/ieee1394/nodemgr.c                  |   10 +++++-----
 drivers/ieee1394/raw1394.c                  |    8 ++++----
 drivers/infiniband/core/device.c            |    2 +-
 drivers/infiniband/core/ucm.c               |    2 +-
 drivers/infiniband/core/user_mad.c          |    4 ++--
 drivers/infiniband/core/uverbs.h            |    4 ++--
 drivers/infiniband/hw/mthca/mthca_cmd.c     |   10 +++++-----
 drivers/infiniband/hw/mthca/mthca_dev.h     |   10 +++++-----
 drivers/infiniband/hw/mthca/mthca_memfree.c |    2 +-
 drivers/infiniband/hw/mthca/mthca_memfree.h |    6 +++---
 drivers/infiniband/ulp/ipoib/ipoib.h        |    6 +++---
 drivers/infiniband/ulp/srp/ib_srp.h         |    4 ++--
 drivers/input/joystick/db9.c                |    2 +-
 drivers/input/joystick/gamecon.c            |    2 +-
 drivers/input/joystick/iforce/iforce.h      |    4 ++--
 drivers/input/joystick/turbografx.c         |    2 +-
 drivers/input/keyboard/atkbd.c              |    2 +-
 drivers/input/keyboard/hil_kbd.c            |    2 +-
 drivers/input/misc/hp_sdc_rtc.c             |    4 ++--
 drivers/input/mouse/hil_ptr.c               |    2 +-
 drivers/input/serio/hp_sdc.c                |    4 ++--
 drivers/input/serio/hp_sdc_mlc.c            |    2 +-
 drivers/isdn/capi/capi.c                    |    2 +-
 37 files changed, 64 insertions(+), 64 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/busses/i2c-ali1535.c linux-2.6.15-rc5-mutex/drivers/i2c/busses/i2c-ali1535.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/busses/i2c-ali1535.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/busses/i2c-ali1535.c	2005-12-12 22:08:48.000000000 +0000
@@ -63,7 +63,7 @@
 #include <linux/i2c.h>
 #include <linux/init.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 
 /* ALI1535 SMBus address offsets */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/busses/i2c-amd756-s4882.c linux-2.6.15-rc5-mutex/drivers/i2c/busses/i2c-amd756-s4882.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/busses/i2c-amd756-s4882.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/busses/i2c-amd756-s4882.c	2005-12-12 21:31:04.000000000 +0000
@@ -45,7 +45,7 @@ static struct i2c_adapter *s4882_adapter
 static struct i2c_algorithm *s4882_algo;
 
 /* Wrapper access functions for multiplexed SMBus */
-static struct semaphore amd756_lock;
+static struct mutex amd756_lock;
 
 static s32 amd756_access_virt0(struct i2c_adapter * adap, u16 addr,
 			       unsigned short flags, char read_write,
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/busses/scx200_acb.c linux-2.6.15-rc5-mutex/drivers/i2c/busses/scx200_acb.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/busses/scx200_acb.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/busses/scx200_acb.c	2005-12-12 21:31:22.000000000 +0000
@@ -84,7 +84,7 @@ struct scx200_acb_iface
 	struct scx200_acb_iface *next;
 	struct i2c_adapter adapter;
 	unsigned base;
-	struct semaphore sem;
+	struct mutex sem;
 
 	/* State machine data */
 	enum scx200_acb_state state;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/eeprom.c linux-2.6.15-rc5-mutex/drivers/i2c/chips/eeprom.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/eeprom.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/chips/eeprom.c	2005-12-12 21:31:31.000000000 +0000
@@ -54,7 +54,7 @@ enum eeprom_nature {
 /* Each client has this additional data */
 struct eeprom_data {
 	struct i2c_client client;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	u8 valid;			/* bitfield, bit!=0 if slice is valid */
 	unsigned long last_updated[8];	/* In jiffies, 8 slices */
 	u8 data[EEPROM_SIZE];		/* Register values */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/max6875.c linux-2.6.15-rc5-mutex/drivers/i2c/chips/max6875.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/max6875.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/chips/max6875.c	2005-12-12 22:08:48.000000000 +0000
@@ -31,7 +31,7 @@
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/i2c.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* Do not scan - the MAX6875 access method will write to some EEPROM chips */
 static unsigned short normal_i2c[] = {I2C_CLIENT_END};
@@ -54,7 +54,7 @@ I2C_CLIENT_INSMOD_1(max6875);
 /* Each client has this additional data */
 struct max6875_data {
 	struct i2c_client	client;
-	struct semaphore	update_lock;
+	struct mutex		update_lock;
 
 	u32			valid;
 	u8			data[USER_EEPROM_SIZE];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/pcf8591.c linux-2.6.15-rc5-mutex/drivers/i2c/chips/pcf8591.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/pcf8591.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/chips/pcf8591.c	2005-12-12 21:31:48.000000000 +0000
@@ -74,7 +74,7 @@ MODULE_PARM_DESC(input_mode,
 
 struct pcf8591_data {
 	struct i2c_client client;
-	struct semaphore update_lock;
+	struct mutex  update_lock;
 
 	u8 control;
 	u8 aout;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/tps65010.c linux-2.6.15-rc5-mutex/drivers/i2c/chips/tps65010.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/i2c/chips/tps65010.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/i2c/chips/tps65010.c	2005-12-12 21:31:36.000000000 +0000
@@ -81,7 +81,7 @@ enum tps_model {
 
 struct tps65010 {
 	struct i2c_client	client;
-	struct semaphore	lock;
+	struct mutex		lock;
 	int			irq;
 	struct work_struct	work;
 	struct dentry		*file;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ide/ide.c linux-2.6.15-rc5-mutex/drivers/ide/ide.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ide/ide.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/ide/ide.c	2005-12-12 17:55:02.000000000 +0000
@@ -222,7 +222,7 @@ static void init_hwif_data(ide_hwif_t *h
 	hwif->mwdma_mask = 0x80;	/* disable all mwdma */
 	hwif->swdma_mask = 0x80;	/* disable all swdma */
 
-	sema_init(&hwif->gendev_rel_sem, 0);
+	init_MUTEX_LOCKED(&hwif->gendev_rel_sem);
 
 	default_hwif_iops(hwif);
 	default_hwif_transport(hwif);
@@ -245,7 +245,7 @@ static void init_hwif_data(ide_hwif_t *h
 		drive->is_flash			= 0;
 		drive->vdma			= 0;
 		INIT_LIST_HEAD(&drive->list);
-		sema_init(&drive->gendev_rel_sem, 0);
+		init_MUTEX_LOCKED(&drive->gendev_rel_sem);
 	}
 }
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/dv1394-private.h linux-2.6.15-rc5-mutex/drivers/ieee1394/dv1394-private.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/dv1394-private.h	2004-06-18 13:41:59.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/dv1394-private.h	2005-12-12 21:38:13.000000000 +0000
@@ -470,7 +470,7 @@ struct video_card {
 
 	  NOTE: if you need both spinlock and sem, take sem first to avoid deadlock!
 	 */
-	struct semaphore sem;
+	struct mutex sem;
 
 	/* people waiting for buffer space, please form a line here... */
 	wait_queue_head_t waitq;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/eth1394.c linux-2.6.15-rc5-mutex/drivers/ieee1394/eth1394.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/eth1394.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/eth1394.c	2005-12-12 22:08:48.000000000 +0000
@@ -64,7 +64,7 @@
 #include <linux/ethtool.h>
 #include <asm/uaccess.h>
 #include <asm/delay.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <net/arp.h>
 
 #include "csr1212.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/hosts.h linux-2.6.15-rc5-mutex/drivers/ieee1394/hosts.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/hosts.h	2005-11-01 13:19:07.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/hosts.h	2005-12-12 22:08:48.000000000 +0000
@@ -7,7 +7,7 @@
 #include <linux/timer.h>
 #include <linux/skbuff.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "ieee1394_types.h"
 #include "csr.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/ieee1394_core.c linux-2.6.15-rc5-mutex/drivers/ieee1394/ieee1394_core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/ieee1394_core.c	2005-11-01 13:19:07.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/ieee1394_core.c	2005-12-12 22:08:48.000000000 +0000
@@ -35,7 +35,7 @@
 #include <linux/suspend.h>
 
 #include <asm/byteorder.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "ieee1394_types.h"
 #include "ieee1394.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/ieee1394_core.h linux-2.6.15-rc5-mutex/drivers/ieee1394/ieee1394_core.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/ieee1394_core.h	2005-08-30 13:56:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/ieee1394_core.h	2005-12-12 22:08:48.000000000 +0000
@@ -5,7 +5,7 @@
 #include <linux/slab.h>
 #include <linux/devfs_fs_kernel.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include "hosts.h"
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/ieee1394_types.h linux-2.6.15-rc5-mutex/drivers/ieee1394/ieee1394_types.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/ieee1394_types.h	2004-06-18 13:41:59.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/ieee1394_types.h	2005-12-12 22:08:48.000000000 +0000
@@ -9,7 +9,7 @@
 #include <linux/spinlock.h>
 #include <linux/string.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/byteorder.h>
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/nodemgr.c linux-2.6.15-rc5-mutex/drivers/ieee1394/nodemgr.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/nodemgr.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/nodemgr.c	2005-12-12 20:21:37.000000000 +0000
@@ -1520,8 +1520,8 @@ static int nodemgr_host_thread(void *__h
 		unsigned int generation = 0;
 		int i;
 
-		if (down_interruptible(&hi->reset_sem) ||
-		    down_interruptible(&nodemgr_serialize)) {
+		if (down_sem_interruptible(&hi->reset_sem) ||
+		    down_sem_interruptible(&nodemgr_serialize)) {
 			if (try_to_freeze())
 				continue;
 			printk("NodeMgr: received unexpected signal?!\n" );
@@ -1551,7 +1551,7 @@ static int nodemgr_host_thread(void *__h
 
 			/* If we get a reset before we are done waiting, then
 			 * start the the waiting over again */
-			while (!down_trylock(&hi->reset_sem))
+			while (!down_sem_trylock(&hi->reset_sem))
 				i = 0;
 
 			/* Check the kill_me again */
@@ -1678,7 +1678,7 @@ static void nodemgr_host_reset(struct hp
 
 	if (hi != NULL) {
 		HPSB_VERBOSE("NodeMgr: Processing host reset for %s", hi->daemon_name);
-		up(&hi->reset_sem);
+		up_sem(&hi->reset_sem);
 	} else
 		HPSB_ERR ("NodeMgr: could not process reset of unused host");
 
@@ -1693,7 +1693,7 @@ static void nodemgr_remove_host(struct h
 		if (hi->pid >= 0) {
 			hi->kill_me = 1;
 			mb();
-			up(&hi->reset_sem);
+			up_sem(&hi->reset_sem);
 			wait_for_completion(&hi->exited);
 			nodemgr_remove_host_dev(&host->device);
 		}
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/raw1394.c linux-2.6.15-rc5-mutex/drivers/ieee1394/raw1394.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/ieee1394/raw1394.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/ieee1394/raw1394.c	2005-12-12 20:21:05.000000000 +0000
@@ -138,7 +138,7 @@ static void __queue_complete_req(struct 
 	list_del(&req->list);
 	list_add_tail(&req->list, &fi->req_complete);
 
-	up(&fi->complete_sem);
+	up_sem(&fi->complete_sem);
 	wake_up_interruptible(&fi->poll_wait_complete);
 }
 
@@ -427,11 +427,11 @@ static ssize_t raw1394_read(struct file 
 	}
 
 	if (file->f_flags & O_NONBLOCK) {
-		if (down_trylock(&fi->complete_sem)) {
+		if (down_sem_trylock(&fi->complete_sem)) {
 			return -EAGAIN;
 		}
 	} else {
-		if (down_interruptible(&fi->complete_sem)) {
+		if (down_sem_interruptible(&fi->complete_sem)) {
 			return -ERESTARTSYS;
 		}
 	}
@@ -2809,7 +2809,7 @@ static int raw1394_release(struct inode 
 		spin_unlock_irqrestore(&fi->reqlists_lock, flags);
 
 		if (!done)
-			down_interruptible(&fi->complete_sem);
+			down_sem_interruptible(&fi->complete_sem);
 	}
 
 	/* Remove any sub-trees left by user space programs */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/device.c linux-2.6.15-rc5-mutex/drivers/infiniband/core/device.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/device.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/core/device.c	2005-12-12 22:12:49.000000000 +0000
@@ -39,7 +39,7 @@
 #include <linux/slab.h>
 #include <linux/init.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "core_priv.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/ucm.c linux-2.6.15-rc5-mutex/drivers/infiniband/core/ucm.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/ucm.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/core/ucm.c	2005-12-12 21:14:22.000000000 +0000
@@ -60,7 +60,7 @@ struct ib_ucm_device {
 };
 
 struct ib_ucm_file {
-	struct semaphore mutex;
+	struct mutex mutex;
 	struct file *filp;
 	struct ib_ucm_device *device;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/user_mad.c linux-2.6.15-rc5-mutex/drivers/infiniband/core/user_mad.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/user_mad.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/core/user_mad.c	2005-12-12 22:12:49.000000000 +0000
@@ -47,7 +47,7 @@
 #include <linux/kref.h>
 
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <rdma/ib_mad.h>
 #include <rdma/ib_user_mad.h>
@@ -92,7 +92,7 @@ struct ib_umad_port {
 
 	struct cdev           *sm_dev;
 	struct class_device   *sm_class_dev;
-	struct semaphore       sm_sem;
+	struct mutex           sm_sem;
 
 	struct rw_semaphore    mutex;
 	struct list_head       file_list;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/uverbs.h linux-2.6.15-rc5-mutex/drivers/infiniband/core/uverbs.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/core/uverbs.h	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/core/uverbs.h	2005-12-12 21:14:18.000000000 +0000
@@ -88,7 +88,7 @@ struct ib_uverbs_event_file {
 
 struct ib_uverbs_file {
 	struct kref				ref;
-	struct semaphore			mutex;
+	struct mutex				mutex;
 	struct ib_uverbs_device		       *device;
 	struct ib_ucontext		       *ucontext;
 	struct ib_event_handler			event_handler;
@@ -131,7 +131,7 @@ struct ib_ucq_object {
 	u32			async_events_reported;
 };
 
-extern struct semaphore ib_uverbs_idr_mutex;
+extern struct mutex ib_uverbs_idr_mutex;
 extern struct idr ib_uverbs_pd_idr;
 extern struct idr ib_uverbs_mr_idr;
 extern struct idr ib_uverbs_mw_idr;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_cmd.c linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_cmd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_cmd.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_cmd.c	2005-12-12 20:33:35.000000000 +0000
@@ -333,7 +333,7 @@ static int mthca_cmd_wait(struct mthca_d
 	int err = 0;
 	struct mthca_cmd_context *context;
 
-	if (down_interruptible(&dev->cmd.event_sem))
+	if (down_sem_interruptible(&dev->cmd.event_sem))
 		return -EINTR;
 
 	spin_lock(&dev->cmd.context_lock);
@@ -375,7 +375,7 @@ out:
 	dev->cmd.free_head = context - dev->cmd.context;
 	spin_unlock(&dev->cmd.context_lock);
 
-	up(&dev->cmd.event_sem);
+	up_sem(&dev->cmd.event_sem);
 	return err;
 }
 
@@ -438,8 +438,8 @@ static int mthca_cmd_imm(struct mthca_de
 
 int mthca_cmd_init(struct mthca_dev *dev)
 {
-	sema_init(&dev->cmd.hcr_sem, 1);
-	sema_init(&dev->cmd.poll_sem, 1);
+	init_MUTEX(&dev->cmd.hcr_sem);
+	init_MUTEX(&dev->cmd.poll_sem);
 	dev->cmd.use_events = 0;
 
 	dev->hcr = ioremap(pci_resource_start(dev->pdev, 0) + MTHCA_HCR_BASE,
@@ -517,7 +517,7 @@ void mthca_cmd_use_polling(struct mthca_
 	dev->cmd.use_events = 0;
 
 	for (i = 0; i < dev->cmd.max_cmds; ++i)
-		down(&dev->cmd.event_sem);
+		down_sem(&dev->cmd.event_sem);
 
 	kfree(dev->cmd.context);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_dev.h linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_dev.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_dev.h	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_dev.h	2005-12-12 22:06:13.000000000 +0000
@@ -43,7 +43,7 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/dma-mapping.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "mthca_provider.h"
 #include "mthca_doorbell.h"
@@ -110,8 +110,8 @@ enum {
 struct mthca_cmd {
 	struct pci_pool          *pool;
 	int                       use_events;
-	struct semaphore          hcr_sem;
-	struct semaphore 	  poll_sem;
+	struct mutex              hcr_sem;
+	struct mutex              poll_sem;
 	struct semaphore 	  event_sem;
 	int              	  max_cmds;
 	spinlock_t                context_lock;
@@ -255,7 +255,7 @@ struct mthca_av_table {
 };
 
 struct mthca_mcg_table {
-	struct semaphore   	sem;
+	struct mutex		sem;
 	struct mthca_alloc 	alloc;
 	struct mthca_icm_table *table;
 };
@@ -300,7 +300,7 @@ struct mthca_dev {
 	u64              ddr_end;
 
 	MTHCA_DECLARE_DOORBELL_LOCK(doorbell_lock)
-	struct semaphore cap_mask_mutex;
+	struct mutex cap_mask_mutex;
 
 	void __iomem    *hcr;
 	void __iomem    *kar;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_memfree.c linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_memfree.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_memfree.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_memfree.c	2005-12-12 21:14:34.000000000 +0000
@@ -50,7 +50,7 @@ enum {
 };
 
 struct mthca_user_db_table {
-	struct semaphore mutex;
+	struct mutex mutex;
 	struct {
 		u64                uvirt;
 		struct scatterlist mem;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_memfree.h linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_memfree.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/hw/mthca/mthca_memfree.h	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/hw/mthca/mthca_memfree.h	2005-12-12 22:06:17.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/list.h>
 #include <linux/pci.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define MTHCA_ICM_CHUNK_LEN \
 	((256 - sizeof (struct list_head) - 2 * sizeof (int)) /		\
@@ -64,7 +64,7 @@ struct mthca_icm_table {
 	int               num_obj;
 	int               obj_size;
 	int               lowmem;
-	struct semaphore  mutex;
+	struct mutex      mutex;
 	struct mthca_icm *icm[0];
 };
 
@@ -147,7 +147,7 @@ struct mthca_db_table {
 	int 	       	      max_group1;
 	int 	       	      min_group2;
 	struct mthca_db_page *page;
-	struct semaphore      mutex;
+	struct mutex          mutex;
 };
 
 enum mthca_db_type {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/ulp/ipoib/ipoib.h linux-2.6.15-rc5-mutex/drivers/infiniband/ulp/ipoib/ipoib.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/ulp/ipoib/ipoib.h	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/ulp/ipoib/ipoib.h	2005-12-12 22:12:49.000000000 +0000
@@ -49,7 +49,7 @@
 #include <net/neighbour.h>
 
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <rdma/ib_verbs.h>
 #include <rdma/ib_pack.h>
@@ -123,8 +123,8 @@ struct ipoib_dev_priv {
 
 	unsigned long flags;
 
-	struct semaphore mcast_mutex;
-	struct semaphore vlan_mutex;
+	struct mutex mcast_mutex;
+	struct mutex vlan_mutex;
 
 	struct rb_root  path_tree;
 	struct list_head path_list;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/ulp/srp/ib_srp.h linux-2.6.15-rc5-mutex/drivers/infiniband/ulp/srp/ib_srp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/infiniband/ulp/srp/ib_srp.h	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/infiniband/ulp/srp/ib_srp.h	2005-12-12 22:12:49.000000000 +0000
@@ -38,7 +38,7 @@
 #include <linux/types.h>
 #include <linux/list.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi_host.h>
 #include <scsi/scsi_cmnd.h>
@@ -85,7 +85,7 @@ struct srp_host {
 	struct ib_mr	       *mr;
 	struct class_device	class_dev;
 	struct list_head	target_list;
-	struct semaphore        target_mutex;
+	struct mutex            target_mutex;
 	struct completion	released;
 	struct list_head	list;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/db9.c linux-2.6.15-rc5-mutex/drivers/input/joystick/db9.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/db9.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/joystick/db9.c	2005-12-12 20:56:11.000000000 +0000
@@ -111,7 +111,7 @@ struct db9 {
 	struct pardevice *pd;
 	int mode;
 	int used;
-	struct semaphore sem;
+	struct mutex sem;
 	char phys[DB9_MAX_DEVICES][32];
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/gamecon.c linux-2.6.15-rc5-mutex/drivers/input/joystick/gamecon.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/gamecon.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/joystick/gamecon.c	2005-12-12 20:56:07.000000000 +0000
@@ -83,7 +83,7 @@ struct gc {
 	struct timer_list timer;
 	unsigned char pads[GC_MAX + 1];
 	int used;
-	struct semaphore sem;
+	struct mutex sem;
 	char phys[GC_MAX_DEVICES][32];
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/iforce/iforce.h linux-2.6.15-rc5-mutex/drivers/input/joystick/iforce/iforce.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/iforce/iforce.h	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/joystick/iforce/iforce.h	2005-12-12 22:12:50.000000000 +0000
@@ -37,7 +37,7 @@
 #include <linux/serio.h>
 #include <linux/config.h>
 #include <linux/circ_buf.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* This module provides arbitrary resource management routines.
  * I use it to manage the device's memory.
@@ -146,7 +146,7 @@ struct iforce {
 	wait_queue_head_t wait;
 	struct resource device_memory;
 	struct iforce_core_effect core_effects[FF_EFFECTS_MAX];
-	struct semaphore mem_mutex;
+	struct mutex mem_mutex;
 };
 
 /* Get hi and low bytes of a 16-bits int */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/turbografx.c linux-2.6.15-rc5-mutex/drivers/input/joystick/turbografx.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/joystick/turbografx.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/joystick/turbografx.c	2005-12-12 20:56:17.000000000 +0000
@@ -86,7 +86,7 @@ static struct tgfx {
 	char phys[TGFX_MAX_DEVICES][32];
 	int sticks;
 	int used;
-	struct semaphore sem;
+	struct mutex sem;
 } *tgfx_base[TGFX_MAX_PORTS];
 
 /*
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/keyboard/atkbd.c linux-2.6.15-rc5-mutex/drivers/input/keyboard/atkbd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/keyboard/atkbd.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/keyboard/atkbd.c	2005-12-12 17:52:17.000000000 +0000
@@ -216,7 +216,7 @@ struct atkbd {
 	unsigned long time;
 
 	struct work_struct event_work;
-	struct semaphore event_sem;
+	struct mutex event_sem;
 	unsigned long event_mask;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/keyboard/hil_kbd.c linux-2.6.15-rc5-mutex/drivers/input/keyboard/hil_kbd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/keyboard/hil_kbd.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/keyboard/hil_kbd.c	2005-12-12 20:55:05.000000000 +0000
@@ -80,7 +80,7 @@ struct hil_kbd {
 	char	rnm[HIL_KBD_MAX_LENGTH + 1];	/* RNM record + NULL term. */
 
 	/* Something to sleep around with. */
-	struct semaphore sem;
+	struct mutex sem;
 };
 
 /* Process a complete packet after transfer from the HIL */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/misc/hp_sdc_rtc.c linux-2.6.15-rc5-mutex/drivers/input/misc/hp_sdc_rtc.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/misc/hp_sdc_rtc.c	2005-06-22 13:51:49.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/input/misc/hp_sdc_rtc.c	2005-12-12 20:55:41.000000000 +0000
@@ -52,7 +52,7 @@ MODULE_LICENSE("Dual BSD/GPL");
 
 static unsigned long epoch = 2000;
 
-static struct semaphore i8042tregs;
+static struct mutex i8042tregs;
 
 static hp_sdc_irqhook hp_sdc_rtc_isr;
 
@@ -85,7 +85,7 @@ static void hp_sdc_rtc_isr (int irq, voi
 
 static int hp_sdc_rtc_do_read_bbrtc (struct rtc_time *rtctm)
 {
-	struct semaphore tsem;
+	struct mutex tsem;
 	hp_sdc_transaction t;
 	uint8_t tseq[91];
 	int i;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/mouse/hil_ptr.c linux-2.6.15-rc5-mutex/drivers/input/mouse/hil_ptr.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/mouse/hil_ptr.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/mouse/hil_ptr.c	2005-12-12 20:56:27.000000000 +0000
@@ -73,7 +73,7 @@ struct hil_ptr {
 	unsigned int btnmap[7];
 
 	/* Something to sleep around with. */
-	struct semaphore sem;
+	struct mutex sem;
 };
 
 /* Process a complete packet after transfer from the HIL */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/serio/hp_sdc.c linux-2.6.15-rc5-mutex/drivers/input/serio/hp_sdc.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/serio/hp_sdc.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/serio/hp_sdc.c	2005-12-12 20:56:45.000000000 +0000
@@ -777,7 +777,7 @@ static int __init hp_sdc_init(void)
 	char *errstr;
 	hp_sdc_transaction t_sync;
 	uint8_t ts_sync[6];
-	struct semaphore s_sync;
+	struct mutex s_sync;
 
   	rwlock_init(&hp_sdc.lock);
   	rwlock_init(&hp_sdc.ibf_lock);
@@ -919,7 +919,7 @@ static int __init hp_sdc_register(void)
 {
 	hp_sdc_transaction tq_init;
 	uint8_t tq_init_seq[5];
-	struct semaphore tq_init_sem;
+	struct mutex tq_init_sem;
 #if defined(__mc68000__)
 	mm_segment_t fs;
 	unsigned char i;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/input/serio/hp_sdc_mlc.c linux-2.6.15-rc5-mutex/drivers/input/serio/hp_sdc_mlc.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/input/serio/hp_sdc_mlc.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/input/serio/hp_sdc_mlc.c	2005-12-12 22:12:50.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define PREFIX "HP SDC MLC: "
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/isdn/capi/capi.c linux-2.6.15-rc5-mutex/drivers/isdn/capi/capi.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/isdn/capi/capi.c	2005-12-08 16:23:40.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/isdn/capi/capi.c	2005-12-12 21:19:35.000000000 +0000
@@ -138,7 +138,7 @@ struct capidev {
 
 	struct capincci *nccis;
 
-	struct semaphore ncci_list_sem;
+	struct mutex ncci_list_sem;
 };
 
 /* -------- global variables ---------------------------------------- */

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 7/19] MUTEX: Drivers F-H changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
  2005-12-12 23:45 ` [PATCH 2/19] MUTEX: i386 arch mutex David Howells
  2005-12-12 23:45 ` [PATCH 8/19] MUTEX: Drivers I-K changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 6/19] MUTEX: Drivers A-E changes David Howells
                   ` (29 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/f* thru drivers/h* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-FtoH-2615rc5.diff
 drivers/fc4/fc.c           |    8 ++++----
 drivers/firmware/dcdbas.c  |    2 +-
 drivers/hwmon/adm1021.c    |    2 +-
 drivers/hwmon/adm1025.c    |    2 +-
 drivers/hwmon/adm1026.c    |    4 ++--
 drivers/hwmon/adm1031.c    |    2 +-
 drivers/hwmon/adm9240.c    |    2 +-
 drivers/hwmon/asb100.c     |    4 ++--
 drivers/hwmon/atxp1.c      |    2 +-
 drivers/hwmon/ds1621.c     |    2 +-
 drivers/hwmon/fscher.c     |    2 +-
 drivers/hwmon/fscpos.c     |    2 +-
 drivers/hwmon/gl518sm.c    |    2 +-
 drivers/hwmon/gl520sm.c    |    2 +-
 drivers/hwmon/it87.c       |    4 ++--
 drivers/hwmon/lm63.c       |    2 +-
 drivers/hwmon/lm75.c       |    2 +-
 drivers/hwmon/lm77.c       |    2 +-
 drivers/hwmon/lm78.c       |    4 ++--
 drivers/hwmon/lm80.c       |    2 +-
 drivers/hwmon/lm83.c       |    2 +-
 drivers/hwmon/lm85.c       |    4 ++--
 drivers/hwmon/lm87.c       |    2 +-
 drivers/hwmon/lm90.c       |    2 +-
 drivers/hwmon/lm92.c       |    2 +-
 drivers/hwmon/max1619.c    |    2 +-
 drivers/hwmon/pc87360.c    |    4 ++--
 drivers/hwmon/sis5595.c    |    4 ++--
 drivers/hwmon/smsc47b397.c |    4 ++--
 drivers/hwmon/smsc47m1.c   |    4 ++--
 drivers/hwmon/via686a.c    |    2 +-
 drivers/hwmon/w83627ehf.c  |    4 ++--
 drivers/hwmon/w83627hf.c   |    4 ++--
 drivers/hwmon/w83781d.c    |    4 ++--
 drivers/hwmon/w83792d.c    |    4 ++--
 drivers/hwmon/w83l785ts.c  |    2 +-
 36 files changed, 52 insertions(+), 52 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/fc4/fc.c linux-2.6.15-rc5-mutex/drivers/fc4/fc.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/fc4/fc.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/fc4/fc.c	2005-12-12 22:08:48.000000000 +0000
@@ -36,7 +36,7 @@
 
 #include <asm/pgtable.h>
 #include <asm/irq.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include "fcp_impl.h"
 #include <scsi/scsi_host.h>
 
@@ -106,7 +106,7 @@ fc_channel *fc_channels = NULL;
 #define LSMAGIC	620829043
 typedef struct {
 	/* Must be first */
-	struct semaphore sem;
+	struct mutex sem;
 	int magic;
 	int count;
 	logi *logi;
@@ -119,7 +119,7 @@ typedef struct {
 #define LSOMAGIC 654907799
 typedef struct {
 	/* Must be first */
-	struct semaphore sem;
+	struct mutex sem;
 	int magic;
 	int count;
 	fcp_cmnd *fcmds;
@@ -130,7 +130,7 @@ typedef struct {
 #define LSEMAGIC 84482456
 typedef struct {
 	/* Must be first */
-	struct semaphore sem;
+	struct mutex sem;
 	int magic;
 	int status;
 	struct timer_list timer;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/firmware/dcdbas.c linux-2.6.15-rc5-mutex/drivers/firmware/dcdbas.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/firmware/dcdbas.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/firmware/dcdbas.c	2005-12-12 22:08:48.000000000 +0000
@@ -34,7 +34,7 @@
 #include <linux/string.h>
 #include <linux/types.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "dcdbas.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1021.c linux-2.6.15-rc5-mutex/drivers/hwmon/adm1021.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1021.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/adm1021.c	2005-12-12 21:36:44.000000000 +0000
@@ -92,7 +92,7 @@ struct adm1021_data {
 	struct class_device *class_dev;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1025.c linux-2.6.15-rc5-mutex/drivers/hwmon/adm1025.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1025.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/adm1025.c	2005-12-12 21:36:59.000000000 +0000
@@ -133,7 +133,7 @@ static struct i2c_driver adm1025_driver 
 struct adm1025_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1026.c linux-2.6.15-rc5-mutex/drivers/hwmon/adm1026.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1026.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/adm1026.c	2005-12-12 21:46:25.000000000 +0000
@@ -260,10 +260,10 @@ struct pwm_data {
 struct adm1026_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	int valid;		/* !=0 if following fields are valid */
 	unsigned long last_reading;	/* In jiffies */
 	unsigned long last_config;	/* In jiffies */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1031.c linux-2.6.15-rc5-mutex/drivers/hwmon/adm1031.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm1031.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/adm1031.c	2005-12-12 21:35:55.000000000 +0000
@@ -70,7 +70,7 @@ typedef u8 auto_chan_table_t[8][2];
 struct adm1031_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	int chip_type;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm9240.c linux-2.6.15-rc5-mutex/drivers/hwmon/adm9240.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/adm9240.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/adm9240.c	2005-12-12 21:34:47.000000000 +0000
@@ -150,7 +150,7 @@ struct adm9240_data {
 	enum chips type;
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;
 	unsigned long last_updated_measure;
 	unsigned long last_updated_config;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/asb100.c linux-2.6.15-rc5-mutex/drivers/hwmon/asb100.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/asb100.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/asb100.c	2005-12-12 21:36:30.000000000 +0000
@@ -182,10 +182,10 @@ static u8 DIV_TO_REG(long val)
 struct asb100_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	unsigned long last_updated;	/* In jiffies */
 
 	/* array of 2 pointers to subclients */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/atxp1.c linux-2.6.15-rc5-mutex/drivers/hwmon/atxp1.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/atxp1.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/atxp1.c	2005-12-12 21:32:52.000000000 +0000
@@ -60,7 +60,7 @@ static struct i2c_driver atxp1_driver = 
 struct atxp1_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	unsigned long last_updated;
 	u8 valid;
 	struct {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/ds1621.c linux-2.6.15-rc5-mutex/drivers/hwmon/ds1621.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/ds1621.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/ds1621.c	2005-12-12 21:36:07.000000000 +0000
@@ -72,7 +72,7 @@ MODULE_PARM_DESC(polarity, "Output's pol
 struct ds1621_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;			/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/fscher.c linux-2.6.15-rc5-mutex/drivers/hwmon/fscher.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/fscher.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/fscher.c	2005-12-12 21:36:23.000000000 +0000
@@ -133,7 +133,7 @@ static struct i2c_driver fscher_driver =
 struct fscher_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/fscpos.c linux-2.6.15-rc5-mutex/drivers/hwmon/fscpos.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/fscpos.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/fscpos.c	2005-12-12 21:32:08.000000000 +0000
@@ -114,7 +114,7 @@ static struct i2c_driver fscpos_driver =
 struct fscpos_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; 		/* 0 until following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/gl518sm.c linux-2.6.15-rc5-mutex/drivers/hwmon/gl518sm.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/gl518sm.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/gl518sm.c	2005-12-12 21:36:40.000000000 +0000
@@ -120,7 +120,7 @@ struct gl518_data {
 	struct class_device *class_dev;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/gl520sm.c linux-2.6.15-rc5-mutex/drivers/hwmon/gl520sm.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/gl520sm.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/gl520sm.c	2005-12-12 21:34:43.000000000 +0000
@@ -121,7 +121,7 @@ static struct i2c_driver gl520_driver = 
 struct gl520_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* zero until the following fields are valid */
 	unsigned long last_updated;	/* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/it87.c linux-2.6.15-rc5-mutex/drivers/hwmon/it87.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/it87.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/it87.c	2005-12-12 21:36:10.000000000 +0000
@@ -195,10 +195,10 @@ static int DIV_TO_REG(int val)
 struct it87_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm63.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm63.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm63.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm63.c	2005-12-12 21:34:13.000000000 +0000
@@ -153,7 +153,7 @@ static struct i2c_driver lm63_driver = {
 struct lm63_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm75.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm75.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm75.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm75.c	2005-12-12 21:36:04.000000000 +0000
@@ -47,7 +47,7 @@ I2C_CLIENT_INSMOD_1(lm75);
 struct lm75_data {
 	struct i2c_client	client;
 	struct class_device *class_dev;
-	struct semaphore	update_lock;
+	struct mutex		update_lock;
 	char			valid;		/* !=0 if following fields are valid */
 	unsigned long		last_updated;	/* In jiffies */
 	u16			temp_input;	/* Register values */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm77.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm77.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm77.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm77.c	2005-12-12 21:32:04.000000000 +0000
@@ -51,7 +51,7 @@ I2C_CLIENT_INSMOD_1(lm77);
 struct lm77_data {
 	struct i2c_client	client;
 	struct class_device *class_dev;
-	struct semaphore	update_lock;
+	struct mutex		update_lock;
 	char			valid;
 	unsigned long		last_updated;	/* In jiffies */
 	int			temp_input;	/* Temperatures */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm78.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm78.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm78.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm78.c	2005-12-12 21:34:34.000000000 +0000
@@ -131,10 +131,10 @@ static inline int TEMP_FROM_REG(s8 val)
 struct lm78_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm80.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm80.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm80.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm80.c	2005-12-12 21:35:36.000000000 +0000
@@ -108,7 +108,7 @@ static inline long TEMP_FROM_REG(u16 tem
 struct lm80_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm83.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm83.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm83.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm83.c	2005-12-12 21:33:05.000000000 +0000
@@ -139,7 +139,7 @@ static struct i2c_driver lm83_driver = {
 struct lm83_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm85.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm85.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm85.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm85.c	2005-12-12 21:46:29.000000000 +0000
@@ -331,10 +331,10 @@ struct lm85_autofan {
 struct lm85_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	int valid;		/* !=0 if following fields are valid */
 	unsigned long last_reading;	/* In jiffies */
 	unsigned long last_config;	/* In jiffies */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm87.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm87.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm87.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm87.c	2005-12-12 21:35:26.000000000 +0000
@@ -176,7 +176,7 @@ static struct i2c_driver lm87_driver = {
 struct lm87_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm90.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm90.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm90.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm90.c	2005-12-12 21:35:33.000000000 +0000
@@ -201,7 +201,7 @@ static struct i2c_driver lm90_driver = {
 struct lm90_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 	int kind;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm92.c linux-2.6.15-rc5-mutex/drivers/hwmon/lm92.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/lm92.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/lm92.c	2005-12-12 21:32:22.000000000 +0000
@@ -96,7 +96,7 @@ static struct i2c_driver lm92_driver;
 struct lm92_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/max1619.c linux-2.6.15-rc5-mutex/drivers/hwmon/max1619.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/max1619.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/max1619.c	2005-12-12 21:32:26.000000000 +0000
@@ -104,7 +104,7 @@ static struct i2c_driver max1619_driver 
 struct max1619_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/pc87360.c linux-2.6.15-rc5-mutex/drivers/hwmon/pc87360.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/pc87360.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/pc87360.c	2005-12-12 21:35:18.000000000 +0000
@@ -183,8 +183,8 @@ static inline u8 PWM_TO_REG(int val, int
 struct pc87360_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
-	struct semaphore update_lock;
+	struct mutex lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/sis5595.c linux-2.6.15-rc5-mutex/drivers/hwmon/sis5595.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/sis5595.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/sis5595.c	2005-12-12 21:36:53.000000000 +0000
@@ -167,9 +167,9 @@ static inline u8 DIV_TO_REG(int val)
 struct sis5595_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 	char maxins;		/* == 3 if temp enabled, otherwise == 4 */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/smsc47b397.c linux-2.6.15-rc5-mutex/drivers/hwmon/smsc47b397.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/smsc47b397.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/smsc47b397.c	2005-12-12 21:32:47.000000000 +0000
@@ -92,9 +92,9 @@ static u8 smsc47b397_reg_temp[] = {0x25,
 struct smsc47b397_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	unsigned long last_updated; /* in jiffies */
 	int valid;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/smsc47m1.c linux-2.6.15-rc5-mutex/drivers/hwmon/smsc47m1.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/smsc47m1.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/smsc47m1.c	2005-12-12 21:36:47.000000000 +0000
@@ -102,9 +102,9 @@ superio_exit(void)
 struct smsc47m1_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	unsigned long last_updated;	/* In jiffies */
 
 	u8 fan[2];		/* Register value */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/via686a.c linux-2.6.15-rc5-mutex/drivers/hwmon/via686a.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/via686a.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/via686a.c	2005-12-12 21:32:38.000000000 +0000
@@ -296,7 +296,7 @@ static inline long TEMP_FROM_REG10(u16 v
 struct via686a_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83627ehf.c linux-2.6.15-rc5-mutex/drivers/hwmon/w83627ehf.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83627ehf.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/w83627ehf.c	2005-12-12 21:36:26.000000000 +0000
@@ -177,9 +177,9 @@ temp1_to_reg(int temp)
 struct w83627ehf_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83627hf.c linux-2.6.15-rc5-mutex/drivers/hwmon/w83627hf.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83627hf.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/w83627hf.c	2005-12-12 21:35:50.000000000 +0000
@@ -285,10 +285,10 @@ static inline u8 DIV_TO_REG(long val)
 struct w83627hf_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83781d.c linux-2.6.15-rc5-mutex/drivers/hwmon/w83781d.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83781d.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/w83781d.c	2005-12-12 21:34:06.000000000 +0000
@@ -221,10 +221,10 @@ DIV_TO_REG(long val, enum chips type)
 struct w83781d_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83792d.c linux-2.6.15-rc5-mutex/drivers/hwmon/w83792d.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83792d.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/w83792d.c	2005-12-12 21:35:10.000000000 +0000
@@ -269,10 +269,10 @@ DIV_TO_REG(long val)
 struct w83792d_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore lock;
+	struct mutex lock;
 	enum chips type;
 
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid;		/* !=0 if following fields are valid */
 	unsigned long last_updated;	/* In jiffies */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83l785ts.c linux-2.6.15-rc5-mutex/drivers/hwmon/w83l785ts.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/hwmon/w83l785ts.c	2005-12-08 16:23:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/hwmon/w83l785ts.c	2005-12-12 21:35:47.000000000 +0000
@@ -107,7 +107,7 @@ static struct i2c_driver w83l785ts_drive
 struct w83l785ts_data {
 	struct i2c_client client;
 	struct class_device *class_dev;
-	struct semaphore update_lock;
+	struct mutex update_lock;
 	char valid; /* zero until following fields are valid */
 	unsigned long last_updated; /* in jiffies */
 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 11/19] MUTEX: Drivers Q-S changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (12 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 12/19] MUTEX: Drivers T-Z changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 18/19] MUTEX: Security changes David Howells
                   ` (18 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/q* thru drivers/s* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-QtoS-2615rc5.diff
 drivers/s390/char/sclp_cpi.c           |   16 ++++++++--------
 drivers/s390/char/vmcp.h               |    4 ++--
 drivers/s390/cio/ccwgroup.c            |    2 +-
 drivers/s390/cio/qdio.c                |    2 +-
 drivers/s390/cio/qdio.h                |    2 +-
 drivers/s390/net/ctctty.c              |    2 +-
 drivers/s390/net/qeth_main.c           |    2 +-
 drivers/s390/s390mach.c                |    6 +++---
 drivers/s390/scsi/zfcp_aux.c           |    2 +-
 drivers/s390/scsi/zfcp_def.h           |    4 ++--
 drivers/s390/scsi/zfcp_erp.c           |   12 ++++++------
 drivers/sbus/char/vfc.h                |    2 +-
 drivers/scsi/3w-9xxx.h                 |    2 +-
 drivers/scsi/3w-xxxx.h                 |    2 +-
 drivers/scsi/aacraid/aachba.c          |    2 +-
 drivers/scsi/aacraid/aacraid.h         |    4 ++--
 drivers/scsi/aacraid/commctrl.c        |    2 +-
 drivers/scsi/aacraid/comminit.c        |    2 +-
 drivers/scsi/aacraid/commsup.c         |    2 +-
 drivers/scsi/aacraid/dpcsup.c          |    2 +-
 drivers/scsi/aacraid/linit.c           |    2 +-
 drivers/scsi/aacraid/rkt.c             |    2 +-
 drivers/scsi/aacraid/rx.c              |    2 +-
 drivers/scsi/aacraid/sa.c              |    2 +-
 drivers/scsi/aha152x.c                 |    8 ++++----
 drivers/scsi/aic7xxx/aic79xx_osm.h     |    2 +-
 drivers/scsi/aic7xxx/aic7xxx_osm.h     |    2 +-
 drivers/scsi/ch.c                      |    2 +-
 drivers/scsi/dpt/dpti_i2o.h            |    2 +-
 drivers/scsi/iscsi_tcp.h               |    2 +-
 drivers/scsi/libata-core.c             |    2 +-
 drivers/scsi/megaraid.h                |    2 +-
 drivers/scsi/megaraid/mega_common.h    |    2 +-
 drivers/scsi/megaraid/megaraid_ioctl.h |    2 +-
 drivers/scsi/megaraid/megaraid_mbox.c  |    2 +-
 drivers/scsi/megaraid/megaraid_mbox.h  |    2 +-
 drivers/scsi/megaraid/megaraid_mm.c    |    6 +++---
 drivers/scsi/megaraid/megaraid_sas.c   |    6 +++---
 drivers/scsi/megaraid/megaraid_sas.h   |    2 +-
 drivers/scsi/osst.h                    |    2 +-
 drivers/scsi/qla2xxx/qla_def.h         |    8 ++++----
 drivers/scsi/qla2xxx/qla_gbl.h         |    2 +-
 drivers/scsi/qla2xxx/qla_mbx.c         |    2 +-
 drivers/scsi/qla2xxx/qla_os.c          |    2 +-
 drivers/scsi/scsi_scan.c               |    2 +-
 drivers/scsi/scsi_transport_spi.c      |    2 +-
 drivers/scsi/st.h                      |    2 +-
 drivers/serial/crisv10.c               |    2 +-
 drivers/serial/mcfserial.c             |    2 +-
 drivers/serial/pmac_zilog.c            |    2 +-
 50 files changed, 77 insertions(+), 77 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/char/sclp_cpi.c linux-2.6.15-rc5-mutex/drivers/s390/char/sclp_cpi.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/char/sclp_cpi.c	2005-03-02 12:08:23.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/char/sclp_cpi.c	2005-12-12 22:08:48.000000000 +0000
@@ -16,7 +16,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <asm/ebcdic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "sclp.h"
 #include "sclp_rw.h"
@@ -115,10 +115,10 @@ cpi_check_parms(void)
 static void
 cpi_callback(struct sclp_req *req, void *data)
 {
-	struct semaphore *sem;
+	struct completion *cpl;
 
-	sem = (struct semaphore *) data;
-	up(sem);
+	cpl = data;
+	complete(cpl);
 }
 
 static struct sclp_req *
@@ -185,7 +185,7 @@ cpi_free_req(struct sclp_req *req)
 static int __init
 cpi_module_init(void)
 {
-	struct semaphore sem;
+	struct completion cpl;
 	struct sclp_req *req;
 	int rc;
 
@@ -215,8 +215,8 @@ cpi_module_init(void)
 	}
 
 	/* Prepare semaphore */
-	sema_init(&sem, 0);
-	req->callback_data = &sem;
+	init_completion(&cpl);
+	req->callback_data = &cpl;
 	/* Add request to sclp queue */
 	rc = sclp_add_request(req);
 	if (rc) {
@@ -226,7 +226,7 @@ cpi_module_init(void)
 		return rc;
 	}
 	/* make "insmod" sleep until callback arrives */
-	down(&sem);
+	wait_for_completion(&cpl);
 
 	rc = ((struct cpi_sccb *) req->sccb)->header.response_code;
 	if (rc != 0x0020) {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/char/vmcp.h linux-2.6.15-rc5-mutex/drivers/s390/char/vmcp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/char/vmcp.h	2005-08-30 13:56:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/s390/char/vmcp.h	2005-12-12 22:08:48.000000000 +0000
@@ -12,7 +12,7 @@
  * The idea of this driver is based on cpint from Neale Ferguson
  */
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/ioctl.h>
 
 #define VMCP_GETCODE _IOR(0x10, 1, int)
@@ -26,5 +26,5 @@ struct vmcp_session {
 	int resp_code;
 	/* As we use copy_from/to_user, which might     *
 	 * sleep and cannot use a spinlock              */
-	struct semaphore mutex;
+	struct mutex mutex;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/cio/ccwgroup.c linux-2.6.15-rc5-mutex/drivers/s390/cio/ccwgroup.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/cio/ccwgroup.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/cio/ccwgroup.c	2005-12-12 22:08:48.000000000 +0000
@@ -17,7 +17,7 @@
 #include <linux/ctype.h>
 #include <linux/dcache.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/ccwdev.h>
 #include <asm/ccwgroup.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/cio/qdio.c linux-2.6.15-rc5-mutex/drivers/s390/cio/qdio.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/cio/qdio.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/cio/qdio.c	2005-12-12 22:08:48.000000000 +0000
@@ -42,7 +42,7 @@
 #include <asm/ccwdev.h>
 #include <asm/io.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/timex.h>
 
 #include <asm/debug.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/cio/qdio.h linux-2.6.15-rc5-mutex/drivers/s390/cio/qdio.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/cio/qdio.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/cio/qdio.h	2005-12-12 21:40:46.000000000 +0000
@@ -645,6 +645,6 @@ struct qdio_irq {
 	struct qdr *qdr;
 	struct qdio_q *input_qs[QDIO_MAX_QUEUES_PER_IRQ];
 	struct qdio_q *output_qs[QDIO_MAX_QUEUES_PER_IRQ];
-	struct semaphore setting_up_sema;
+	struct mutex setting_up_sema;
 };
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/net/ctctty.c linux-2.6.15-rc5-mutex/drivers/s390/net/ctctty.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/net/ctctty.c	2005-08-30 13:56:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/s390/net/ctctty.c	2005-12-12 21:40:26.000000000 +0000
@@ -65,7 +65,7 @@ typedef struct {
   struct tty_struct 	*tty;            /* Pointer to corresponding tty   */
   wait_queue_head_t	open_wait;
   wait_queue_head_t	close_wait;
-  struct semaphore      write_sem;
+  struct mutex          write_sem;
   struct tasklet_struct tasklet;
   struct timer_list     stoptimer;
 } ctc_tty_info;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/net/qeth_main.c linux-2.6.15-rc5-mutex/drivers/s390/net/qeth_main.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/net/qeth_main.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/net/qeth_main.c	2005-12-12 22:08:48.000000000 +0000
@@ -63,7 +63,7 @@
 #include <asm/io.h>
 #include <asm/qeth.h>
 #include <asm/timex.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include "qeth.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/s390mach.c linux-2.6.15-rc5-mutex/drivers/s390/s390mach.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/s390mach.c	2005-11-01 13:19:12.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/s390mach.c	2005-12-12 21:40:07.000000000 +0000
@@ -21,7 +21,7 @@
 #define DBG printk
 // #define DBG(args,...) do {} while (0);
 
-static struct semaphore m_sem;
+static struct mutex m_sem;
 
 extern int css_process_crw(int);
 extern int chsc_process_crw(void);
@@ -51,9 +51,9 @@ s390_collect_crw_info(void *param)
 {
 	struct crw crw;
 	int ccode, ret, slow;
-	struct semaphore *sem;
+	struct mutex *sem;
 
-	sem = (struct semaphore *)param;
+	sem = param;
 	/* Set a nice name. */
 	daemonize("kmcheck");
 repeat:
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/scsi/zfcp_aux.c linux-2.6.15-rc5-mutex/drivers/s390/scsi/zfcp_aux.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/scsi/zfcp_aux.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/scsi/zfcp_aux.c	2005-12-12 20:22:18.000000000 +0000
@@ -233,7 +233,7 @@ zfcp_module_init(void)
 		       ZFCP_CFDC_DEV_MAJOR, zfcp_cfdc_misc.minor);
 
 	/* Initialise proc semaphores */
-	sema_init(&zfcp_data.config_sema, 1);
+	init_MUTEX(&zfcp_data.config_sema, 1);
 
 	/* initialise configuration rw lock */
 	rwlock_init(&zfcp_data.config_lock);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/scsi/zfcp_def.h linux-2.6.15-rc5-mutex/drivers/s390/scsi/zfcp_def.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/scsi/zfcp_def.h	2005-11-01 13:19:12.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/scsi/zfcp_def.h	2005-12-12 20:22:06.000000000 +0000
@@ -1065,13 +1065,13 @@ struct zfcp_data {
         rwlock_t                status_read_lock;   /* for status read thread */
         struct list_head        status_read_receive_head;
         struct list_head        status_read_send_head;
-        struct semaphore        status_read_sema;
+        struct mutex		status_read_sema;
 	wait_queue_head_t	status_read_thread_wqh;
 	u32			adapters;	    /* # of adapters in list */
 	rwlock_t                config_lock;        /* serialises changes
 						       to adapter/port/unit
 						       lists */
-	struct semaphore        config_sema;        /* serialises configuration
+	struct mutex		config_sema;        /* serialises configuration
 						       changes */
 	atomic_t		loglevel;            /* current loglevel */
 	char                    init_busid[BUS_ID_SIZE];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/s390/scsi/zfcp_erp.c linux-2.6.15-rc5-mutex/drivers/s390/scsi/zfcp_erp.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/s390/scsi/zfcp_erp.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/s390/scsi/zfcp_erp.c	2005-12-12 20:24:22.000000000 +0000
@@ -830,7 +830,7 @@ zfcp_erp_action_ready(struct zfcp_erp_ac
 	debug_event(adapter->erp_dbf, 4, &erp_action->action, sizeof (int));
 
 	zfcp_erp_action_to_ready(erp_action);
-	up(&adapter->erp_ready_sem);
+	up_sem(&adapter->erp_ready_sem);
 }
 
 /*
@@ -1107,7 +1107,7 @@ zfcp_erp_thread_kill(struct zfcp_adapter
 	int retval = 0;
 
 	atomic_set_mask(ZFCP_STATUS_ADAPTER_ERP_THREAD_KILL, &adapter->status);
-	up(&adapter->erp_ready_sem);
+	up_sem(&adapter->erp_ready_sem);
 
 	wait_event(adapter->erp_thread_wqh,
 		   !atomic_test_mask(ZFCP_STATUS_ADAPTER_ERP_THREAD_UP,
@@ -1165,7 +1165,7 @@ zfcp_erp_thread(void *data)
 		 * no action in 'ready' queue to be processed and
 		 * thread is not to be killed
 		 */
-		down_interruptible(&adapter->erp_ready_sem);
+		down_sem_interruptible(&adapter->erp_ready_sem);
 		debug_text_event(adapter->erp_dbf, 5, "a_th_woken");
 	}
 
@@ -2318,7 +2318,7 @@ zfcp_erp_adapter_strategy_open_fsf_xconf
 		 * _must_ be the one belonging to the 'exchange config
 		 * data' request.
 		 */
-		down(&adapter->erp_ready_sem);
+		down_sem(&adapter->erp_ready_sem);
 		if (erp_action->status & ZFCP_STATUS_ERP_TIMEDOUT) {
 			ZFCP_LOG_INFO("error: exchange of configuration data "
 				      "for adapter %s timed out\n",
@@ -2374,7 +2374,7 @@ zfcp_erp_adapter_strategy_open_fsf_xport
 		}
 		debug_text_event(adapter->erp_dbf, 6, "a_xport_ok");
 
-		down(&adapter->erp_ready_sem);
+		down_sem(&adapter->erp_ready_sem);
 		if (erp_action->status & ZFCP_STATUS_ERP_TIMEDOUT) {
 			ZFCP_LOG_INFO("error: exchange of port data "
 				      "for adapter %s timed out\n",
@@ -3351,7 +3351,7 @@ zfcp_erp_action_enqueue(int action,
 
 	/* finally put it into 'ready' queue and kick erp thread */
 	list_add(&erp_action->list, &adapter->erp_ready_head);
-	up(&adapter->erp_ready_sem);
+	up_sem(&adapter->erp_ready_sem);
 	retval = 0;
  out:
 	return retval;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/sbus/char/vfc.h linux-2.6.15-rc5-mutex/drivers/sbus/char/vfc.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/sbus/char/vfc.h	2005-08-30 13:56:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/sbus/char/vfc.h	2005-12-12 21:18:51.000000000 +0000
@@ -128,7 +128,7 @@ struct vfc_dev {
 	volatile struct vfc_regs *regs;
 	struct vfc_regs *phys_regs;
 	unsigned int control_reg;
-	struct semaphore device_lock_sem;
+	struct mutex device_lock_sem;
 	int instance;
 	int busy;
 	unsigned long which_io;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/3w-9xxx.h linux-2.6.15-rc5-mutex/drivers/scsi/3w-9xxx.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/3w-9xxx.h	2005-11-01 13:19:12.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/3w-9xxx.h	2005-12-12 21:23:51.000000000 +0000
@@ -672,7 +672,7 @@ typedef struct TAG_TW_Device_Extension {
 	u32                     ioctl_msec;
 	int			chrdev_request_id;
 	wait_queue_head_t	ioctl_wqueue;
-	struct semaphore	ioctl_sem;
+	struct mutex		ioctl_sem;
 	char			aen_clobber;
 	unsigned short		working_srl;
 	unsigned short		working_branch;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/3w-xxxx.h linux-2.6.15-rc5-mutex/drivers/scsi/3w-xxxx.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/3w-xxxx.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/3w-xxxx.h	2005-12-12 21:24:35.000000000 +0000
@@ -420,7 +420,7 @@ typedef struct TAG_TW_Device_Extension {
 	u32			max_sector_count;
 	u32			aen_count;
 	struct Scsi_Host	*host;
-	struct semaphore	ioctl_sem;
+	struct mutex		ioctl_sem;
 	unsigned short		aen_queue[TW_Q_LENGTH];
 	unsigned char		aen_head;
 	unsigned char		aen_tail;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/aachba.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/aachba.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/aachba.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/aachba.c	2005-12-12 22:08:48.000000000 +0000
@@ -32,7 +32,7 @@
 #include <linux/slab.h>
 #include <linux/completion.h>
 #include <linux/blkdev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include <scsi/scsi.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/aacraid.h linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/aacraid.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/aacraid.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/aacraid.h	2005-12-12 21:25:15.000000000 +0000
@@ -735,7 +735,7 @@ struct aac_fib_context {
 	u32			unique;		// unique value representing this context
 	ulong			jiffies;	// used for cleanup - dmb changed to ulong
 	struct list_head	next;		// used to link context's into a linked list
-	struct semaphore 	wait_sem;	// this is used to wait for the next fib to arrive.
+	struct mutex		wait_sem;	// this is used to wait for the next fib to arrive.
 	int			wait;		// Set to true when thread is in WaitForSingleObject
 	unsigned long		count;		// total number of FIBs on FibList
 	struct list_head	fib_list;	// this holds fibs and their attachd hw_fibs
@@ -804,7 +804,7 @@ struct fib {
 	 *	This is the event the sendfib routine will wait on if the
 	 *	caller did not pass one and this is synch io.
 	 */
-	struct semaphore 	event_wait;
+	struct mutex		event_wait;
 	spinlock_t		event_lock;
 
 	u32			done;	/* gets set to 1 when fib is complete */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/commctrl.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/commctrl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/commctrl.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/commctrl.c	2005-12-12 22:08:48.000000000 +0000
@@ -38,7 +38,7 @@
 #include <linux/completion.h>
 #include <linux/dma-mapping.h>
 #include <linux/blkdev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include "aacraid.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/comminit.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/comminit.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/comminit.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/comminit.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/completion.h>
 #include <linux/mm.h>
 #include <scsi/scsi_host.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "aacraid.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/commsup.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/commsup.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/commsup.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/commsup.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/blkdev.h>
 #include <scsi/scsi_host.h>
 #include <scsi/scsi_device.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/delay.h>
 
 #include "aacraid.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/dpcsup.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/dpcsup.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/dpcsup.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/dpcsup.c	2005-12-12 22:08:48.000000000 +0000
@@ -38,7 +38,7 @@
 #include <linux/slab.h>
 #include <linux/completion.h>
 #include <linux/blkdev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "aacraid.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/linit.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/linit.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/linit.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/linit.c	2005-12-12 22:08:48.000000000 +0000
@@ -49,7 +49,7 @@
 #include <linux/ioctl32.h>
 #include <linux/delay.h>
 #include <linux/smp_lock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi.h>
 #include <scsi/scsi_cmnd.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/rkt.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/rkt.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/rkt.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/rkt.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/completion.h>
 #include <linux/time.h>
 #include <linux/interrupt.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi_host.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/rx.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/rx.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/rx.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/rx.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/completion.h>
 #include <linux/time.h>
 #include <linux/interrupt.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi_host.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/sa.c linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/sa.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aacraid/sa.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aacraid/sa.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@
 #include <linux/completion.h>
 #include <linux/time.h>
 #include <linux/interrupt.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi_host.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aha152x.c linux-2.6.15-rc5-mutex/drivers/scsi/aha152x.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aha152x.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aha152x.c	2005-12-12 22:08:48.000000000 +0000
@@ -253,7 +253,7 @@
 #include <linux/isapnp.h>
 #include <linux/spinlock.h>
 #include <linux/workqueue.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <scsi/scsicam.h>
 
 #include "scsi.h"
@@ -549,7 +549,7 @@ struct aha152x_hostdata {
  */
 struct aha152x_scdata {
 	Scsi_Cmnd *next;	/* next sc in queue */
-	struct semaphore *sem;	/* semaphore to block on */
+	struct mutex *sem;	/* semaphore to block on */
 };
 
 
@@ -978,7 +978,7 @@ static int setup_expected_interrupts(str
 /* 
  *  Queue a command and setup interrupts for a free bus.
  */
-static int aha152x_internal_queue(Scsi_Cmnd *SCpnt, struct semaphore *sem, int phase, void (*done)(Scsi_Cmnd *))
+static int aha152x_internal_queue(Scsi_Cmnd *SCpnt, struct mutex *sem, int phase, void (*done)(Scsi_Cmnd *))
 {
 	struct Scsi_Host *shpnt = SCpnt->device->host;
 	unsigned long flags;
@@ -1142,7 +1142,7 @@ static int aha152x_abort(Scsi_Cmnd *SCpn
 static void timer_expired(unsigned long p)
 {
 	Scsi_Cmnd	 *SCp   = (Scsi_Cmnd *)p;
-	struct semaphore *sem   = SCSEM(SCp);
+	struct mutex     *sem   = SCSEM(SCp);
 	struct Scsi_Host *shpnt = SCp->device->host;
 	unsigned long flags;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aic7xxx/aic79xx_osm.h linux-2.6.15-rc5-mutex/drivers/scsi/aic7xxx/aic79xx_osm.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aic7xxx/aic79xx_osm.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aic7xxx/aic79xx_osm.h	2005-12-12 21:20:02.000000000 +0000
@@ -390,7 +390,7 @@ struct ahd_platform_data {
 	spinlock_t		 spin_lock;
 	u_int			 qfrozen;
 	struct timer_list	 reset_timer;
-	struct semaphore	 eh_sem;
+	struct mutex		 eh_sem;
 	struct Scsi_Host        *host;		/* pointer to scsi host */
 #define AHD_LINUX_NOIRQ	((uint32_t)~0)
 	uint32_t		 irq;		/* IRQ for this adapter */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aic7xxx/aic7xxx_osm.h linux-2.6.15-rc5-mutex/drivers/scsi/aic7xxx/aic7xxx_osm.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/aic7xxx/aic7xxx_osm.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/aic7xxx/aic7xxx_osm.h	2005-12-12 21:45:18.000000000 +0000
@@ -394,7 +394,7 @@ struct ahc_platform_data {
 	spinlock_t		 spin_lock;
 	u_int			 qfrozen;
 	struct timer_list	 reset_timer;
-	struct semaphore	 eh_sem;
+	struct mutex		 eh_sem;
 	struct Scsi_Host        *host;		/* pointer to scsi host */
 #define AHC_LINUX_NOIRQ	((uint32_t)~0)
 	uint32_t		 irq;		/* IRQ for this adapter */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/ch.c linux-2.6.15-rc5-mutex/drivers/scsi/ch.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/ch.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/ch.c	2005-12-12 21:23:01.000000000 +0000
@@ -112,7 +112,7 @@ typedef struct {
 	u_int               counts[CH_TYPES];
 	u_int               unit_attention;
 	u_int		    voltags;
-	struct semaphore    lock;
+	struct mutex        lock;
 } scsi_changer;
 
 static LIST_HEAD(ch_devlist);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/dpt/dpti_i2o.h linux-2.6.15-rc5-mutex/drivers/scsi/dpt/dpti_i2o.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/dpt/dpti_i2o.h	2004-06-18 13:41:50.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/scsi/dpt/dpti_i2o.h	2005-12-12 22:08:48.000000000 +0000
@@ -21,7 +21,7 @@
 
 #include <linux/i2o-dev.h>
 
-#include <asm/semaphore.h> /* Needed for MUTEX init macros */
+#include <linux/semaphore.h> /* Needed for MUTEX init macros */
 #include <linux/version.h>
 #include <linux/config.h>
 #include <linux/notifier.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/iscsi_tcp.h linux-2.6.15-rc5-mutex/drivers/scsi/iscsi_tcp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/iscsi_tcp.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/iscsi_tcp.h	2005-12-12 21:24:13.000000000 +0000
@@ -157,7 +157,7 @@ struct iscsi_conn {
 	struct kfifo		*mgmtqueue;	/* mgmt (control) xmit queue */
 	struct kfifo		*xmitqueue;	/* data-path cmd queue */
 	struct work_struct	xmitwork;	/* per-conn. xmit workqueue */
-	struct semaphore	xmitsema;	/* serializes connection xmit,
+	struct mutex		xmitsema;	/* serializes connection xmit,
 						 * access to kfifos:	  *
 						 * xmitqueue, writequeue, *
 						 * immqueue, mgmtqueue    */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/libata-core.c linux-2.6.15-rc5-mutex/drivers/scsi/libata-core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/libata-core.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/libata-core.c	2005-12-12 22:08:48.000000000 +0000
@@ -56,7 +56,7 @@
 #include <scsi/scsi_host.h>
 #include <linux/libata.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/byteorder.h>
 
 #include "libata.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/mega_common.h linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/mega_common.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/mega_common.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/mega_common.h	2005-12-12 22:08:48.000000000 +0000
@@ -27,7 +27,7 @@
 #include <linux/list.h>
 #include <linux/moduleparam.h>
 #include <linux/dma-mapping.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <scsi/scsi.h>
 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_device.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_ioctl.h linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_ioctl.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_ioctl.h	2005-03-02 12:08:25.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_ioctl.h	2005-12-12 22:08:48.000000000 +0000
@@ -18,7 +18,7 @@
 #define _MEGARAID_IOCTL_H_
 
 #include <linux/types.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "mbox_defs.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_mbox.c linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_mbox.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_mbox.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_mbox.c	2005-12-12 20:14:16.000000000 +0000
@@ -3870,7 +3870,7 @@ megaraid_sysfs_alloc_resources(adapter_t
 		megaraid_sysfs_free_resources(adapter);
 	}
 
-	sema_init(&raid_dev->sysfs_sem, 1);
+	init_MUTEX(&raid_dev->sysfs_sem);
 
 	init_waitqueue_head(&raid_dev->sysfs_wait_q);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_mbox.h linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_mbox.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_mbox.h	2005-08-30 13:56:25.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_mbox.h	2005-12-12 20:14:29.000000000 +0000
@@ -205,7 +205,7 @@ typedef struct {
 	int				hw_error;
 	int				fast_load;
 	uint8_t				channel_class;
-	struct semaphore		sysfs_sem;
+	struct mutex			sysfs_sem;
 	uioc_t				*sysfs_uioc;
 	mbox64_t			*sysfs_mbox64;
 	caddr_t				sysfs_buffer;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_mm.c linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_mm.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_mm.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_mm.c	2005-12-12 20:34:30.000000000 +0000
@@ -571,14 +571,14 @@ mraid_mm_alloc_kioc(mraid_mmadp_t *adp)
 	struct list_head*	head;
 	unsigned long		flags;
 
-	down(&adp->kioc_semaphore);
+	down_sem(&adp->kioc_semaphore);
 
 	spin_lock_irqsave(&adp->kioc_pool_lock, flags);
 
 	head = &adp->kioc_pool;
 
 	if (list_empty(head)) {
-		up(&adp->kioc_semaphore);
+		up_sem(&adp->kioc_semaphore);
 		spin_unlock_irqrestore(&adp->kioc_pool_lock, flags);
 
 		con_log(CL_ANN, ("megaraid cmm: kioc list empty!\n"));
@@ -645,7 +645,7 @@ mraid_mm_dealloc_kioc(mraid_mmadp_t *adp
 	spin_unlock_irqrestore(&adp->kioc_pool_lock, flags);
 
 	/* increment the free kioc count */
-	up(&adp->kioc_semaphore);
+	up_sem(&adp->kioc_semaphore);
 
 	return;
 }
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_sas.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_sas.c	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_sas.c	2005-12-12 20:35:15.000000000 +0000
@@ -2100,7 +2100,7 @@ megasas_probe_one(struct pci_dev *pdev, 
 	spin_lock_init(&instance->cmd_pool_lock);
 	spin_lock_init(&instance->instance_lock);
 
-	sema_init(&instance->aen_mutex, 1);
+	init_MUTEX(&instance->aen_mutex);
 	sema_init(&instance->ioctl_sem, MEGASAS_INT_CMDS);
 
 	/*
@@ -2579,12 +2579,12 @@ static int megasas_mgmt_ioctl_fw(struct 
 	/*
 	 * We will allow only MEGASAS_INT_CMDS number of parallel ioctl cmds
 	 */
-	if (down_interruptible(&instance->ioctl_sem)) {
+	if (down_sem_interruptible(&instance->ioctl_sem)) {
 		error = -ERESTARTSYS;
 		goto out_kfree_ioc;
 	}
 	error = megasas_mgmt_fw_ioctl(instance, user_ioc, ioc);
-	up(&instance->ioctl_sem);
+	up_sem(&instance->ioctl_sem);
 
       out_kfree_ioc:
 	kfree(ioc);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_sas.h linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_sas.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid/megaraid_sas.h	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid/megaraid_sas.h	2005-12-12 20:14:04.000000000 +0000
@@ -1042,7 +1042,7 @@ struct megasas_instance {
 	struct megasas_evt_detail *evt_detail;
 	dma_addr_t evt_detail_h;
 	struct megasas_cmd *aen_cmd;
-	struct semaphore aen_mutex;
+	struct mutex aen_mutex;
 	struct semaphore ioctl_sem;
 
 	struct Scsi_Host *host;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid.h linux-2.6.15-rc5-mutex/drivers/scsi/megaraid.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/megaraid.h	2005-12-08 16:23:45.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/megaraid.h	2005-12-12 21:23:40.000000000 +0000
@@ -889,7 +889,7 @@ typedef struct {
 
 	scb_t			int_scb;
 	Scsi_Cmnd		int_scmd;
-	struct semaphore	int_mtx;	/* To synchronize the internal
+	struct mutex		int_mtx;	/* To synchronize the internal
 						commands */
 	struct completion	int_waitq;	/* wait queue for internal
 						 cmds */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/osst.h linux-2.6.15-rc5-mutex/drivers/scsi/osst.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/osst.h	2005-03-02 12:08:25.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/osst.h	2005-12-12 21:23:13.000000000 +0000
@@ -532,7 +532,7 @@ struct osst_tape {
   struct scsi_driver *driver;
   unsigned capacity;
   struct scsi_device *device;
-  struct semaphore lock;       /* for serialization */
+  struct mutex lock;           /* for serialization */
   struct completion wait;      /* for SCSI commands */
   struct osst_buffer * buffer;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_def.h linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_def.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_def.h	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_def.h	2005-12-12 22:08:48.000000000 +0000
@@ -22,7 +22,7 @@
 #include <linux/completion.h>
 #include <linux/interrupt.h>
 #include <linux/workqueue.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi.h>
 #include <scsi/scsi_host.h>
@@ -2370,7 +2370,7 @@ typedef struct scsi_qla_host {
 	int			dpc_should_die;
 	struct completion	dpc_inited;
 	struct completion	dpc_exited;
-	struct semaphore	*dpc_wait;
+	struct mutex		*dpc_wait;
 	uint8_t dpc_active;                  /* DPC routine is active */
 
 	/* Timeout timers. */
@@ -2410,8 +2410,8 @@ typedef struct scsi_qla_host {
 
 	spinlock_t	mbx_reg_lock;   /* Mbx Cmd Register Lock */
 
-	struct semaphore mbx_cmd_sem;	/* Serialialize mbx access */
-	struct semaphore mbx_intr_sem;  /* Used for completion notification */
+	struct mutex mbx_cmd_sem;	/* Serialialize mbx access */
+	struct mutex mbx_intr_sem;	/* Used for completion notification */
 
 	uint32_t	mbx_flags;
 #define  MBX_IN_PROGRESS	BIT_0
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_gbl.h linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_gbl.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_gbl.h	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_gbl.h	2005-12-12 21:20:49.000000000 +0000
@@ -74,7 +74,7 @@ extern void qla2x00_mark_all_devices_los
 
 extern void qla2x00_blink_led(scsi_qla_host_t *);
 
-extern int qla2x00_down_timeout(struct semaphore *, unsigned long);
+extern int qla2x00_down_timeout(struct mutex *, unsigned long);
 
 /*
  * Global Function Prototypes in qla_iocb.c source file.
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_mbx.c linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_mbx.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_mbx.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_mbx.c	2005-12-12 21:46:06.000000000 +0000
@@ -12,7 +12,7 @@
 static void
 qla2x00_mbx_sem_timeout(unsigned long data)
 {
-	struct semaphore	*sem_ptr = (struct semaphore *)data;
+	struct mutex	*sem_ptr = (struct mutex *)data;
 
 	DEBUG11(printk("qla2x00_sem_timeout: entered.\n");)
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_os.c linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_os.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/qla2xxx/qla_os.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/qla2xxx/qla_os.c	2005-12-12 21:21:00.000000000 +0000
@@ -2468,7 +2468,7 @@ qla2x00_timer(scsi_qla_host_t *ha)
 
 /* XXX(hch): crude hack to emulate a down_timeout() */
 int
-qla2x00_down_timeout(struct semaphore *sema, unsigned long timeout)
+qla2x00_down_timeout(struct mutex *sema, unsigned long timeout)
 {
 	const unsigned int step = 100; /* msecs */
 	unsigned int iterations = jiffies_to_msecs(timeout)/100;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/scsi_scan.c linux-2.6.15-rc5-mutex/drivers/scsi/scsi_scan.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/scsi_scan.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/scsi_scan.c	2005-12-12 22:08:48.000000000 +0000
@@ -30,7 +30,7 @@
 #include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/blkdev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <scsi/scsi.h>
 #include <scsi/scsi_device.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/scsi_transport_spi.c linux-2.6.15-rc5-mutex/drivers/scsi/scsi_transport_spi.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/scsi_transport_spi.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/scsi_transport_spi.c	2005-12-12 22:08:48.000000000 +0000
@@ -23,7 +23,7 @@
 #include <linux/module.h>
 #include <linux/workqueue.h>
 #include <linux/blkdev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <scsi/scsi.h>
 #include "scsi_priv.h"
 #include <scsi/scsi_device.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/st.h linux-2.6.15-rc5-mutex/drivers/scsi/st.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/scsi/st.h	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/scsi/st.h	2005-12-12 21:23:22.000000000 +0000
@@ -87,7 +87,7 @@ struct st_partstat {
 struct scsi_tape {
 	struct scsi_driver *driver;
 	struct scsi_device *device;
-	struct semaphore lock;	/* For serialization */
+	struct mutex lock;	/* For serialization */
 	struct completion wait;	/* For SCSI commands */
 	struct st_buffer *buffer;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/serial/crisv10.c linux-2.6.15-rc5-mutex/drivers/serial/crisv10.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/serial/crisv10.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/serial/crisv10.c	2005-12-12 21:37:16.000000000 +0000
@@ -1318,7 +1318,7 @@ static unsigned char *tmp_buf;
 #ifdef DECLARE_MUTEX
 static DECLARE_MUTEX(tmp_buf_sem);
 #else
-static struct semaphore tmp_buf_sem = MUTEX;
+static struct mutex tmp_buf_sem = MUTEX;
 #endif
 
 /* Calculate the chartime depending on baudrate, numbor of bits etc. */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/serial/mcfserial.c linux-2.6.15-rc5-mutex/drivers/serial/mcfserial.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/serial/mcfserial.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/serial/mcfserial.c	2005-12-12 22:08:48.000000000 +0000
@@ -40,7 +40,7 @@
 #include <asm/io.h>
 #include <asm/irq.h>
 #include <asm/system.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/delay.h>
 #include <asm/coldfire.h>
 #include <asm/mcfsim.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/serial/pmac_zilog.c linux-2.6.15-rc5-mutex/drivers/serial/pmac_zilog.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/serial/pmac_zilog.c	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/serial/pmac_zilog.c	2005-12-12 22:08:48.000000000 +0000
@@ -68,7 +68,7 @@
 #include <asm/pmac_feature.h>
 #include <asm/dbdma.h>
 #include <asm/macio.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #if defined (CONFIG_SERIAL_PMACZILOG_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
 #define SUPPORT_SYSRQ

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 15/19] MUTEX: Second set of include changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (6 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 4/19] MUTEX: FRV arch mutex David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 10/19] MUTEX: Drivers N-P changes David Howells
                   ` (24 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the second half of the include files to use the new
mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-include-2-2615rc5.diff
 include/linux/sched.h             |    2 +-
 include/linux/seq_file.h          |    4 ++--
 include/linux/serial_core.h       |    2 +-
 include/linux/serio.h             |    2 +-
 include/linux/smb_fs_sb.h         |    2 +-
 include/linux/sunrpc/svcsock.h    |    2 +-
 include/linux/syscalls.h          |    2 +-
 include/linux/tty.h               |   12 ++++++------
 include/linux/udf_fs_sb.h         |    4 ++--
 include/linux/uinput.h            |    2 +-
 include/linux/usb.h               |    2 +-
 include/linux/videodev2.h         |    2 +-
 include/linux/vt_kern.h           |    2 +-
 include/media/saa7146.h           |    6 +++---
 include/media/video-buf-dvb.h     |    2 +-
 include/media/video-buf.h         |    2 +-
 include/net/af_unix.h             |    2 +-
 include/net/bluetooth/hci_core.h  |    2 +-
 include/net/xfrm.h                |    2 +-
 include/pcmcia/ss.h               |    2 +-
 include/scsi/scsi_host.h          |    2 +-
 include/scsi/scsi_transport_spi.h |    2 +-
 22 files changed, 31 insertions(+), 31 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/sched.h linux-2.6.15-rc5-mutex/include/linux/sched.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/sched.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/sched.h	2005-12-12 22:08:02.000000000 +0000
@@ -17,7 +17,7 @@
 #include <linux/nodemask.h>
 
 #include <asm/system.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/page.h>
 #include <asm/ptrace.h>
 #include <asm/mmu.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/seq_file.h linux-2.6.15-rc5-mutex/include/linux/seq_file.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/seq_file.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/seq_file.h	2005-12-12 22:12:49.000000000 +0000
@@ -4,7 +4,7 @@
 
 #include <linux/types.h>
 #include <linux/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct seq_operations;
 struct file;
@@ -19,7 +19,7 @@ struct seq_file {
 	size_t count;
 	loff_t index;
 	loff_t version;
-	struct semaphore sem;
+	struct mutex sem;
 	struct seq_operations *op;
 	void *private;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/serial_core.h linux-2.6.15-rc5-mutex/include/linux/serial_core.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/serial_core.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/serial_core.h	2005-12-12 18:04:24.000000000 +0000
@@ -281,7 +281,7 @@ struct uart_state {
 	struct uart_info	*info;
 	struct uart_port	*port;
 
-	struct semaphore	sem;
+	struct mutex		sem;
 };
 
 #define UART_XMIT_SIZE	PAGE_SIZE
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/serio.h linux-2.6.15-rc5-mutex/include/linux/serio.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/serio.h	2005-08-30 13:56:37.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/serio.h	2005-12-12 17:52:34.000000000 +0000
@@ -42,7 +42,7 @@ struct serio {
 	struct serio *parent, *child;
 
 	struct serio_driver *drv;	/* accessed from interrupt, must be protected by serio->lock and serio->sem */
-	struct semaphore drv_sem;	/* protects serio->drv so attributes can pin driver */
+	struct mutex drv_sem;		/* protects serio->drv so attributes can pin driver */
 
 	struct device dev;
 	unsigned int registered;	/* port has been fully registered with driver core */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/smb_fs_sb.h linux-2.6.15-rc5-mutex/include/linux/smb_fs_sb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/smb_fs_sb.h	2004-09-16 12:06:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/smb_fs_sb.h	2005-12-12 19:33:38.000000000 +0000
@@ -59,7 +59,7 @@ struct smb_sb_info {
 	struct smb_conn_opt opt;
 	wait_queue_head_t conn_wq;
 	int conn_complete;
-	struct semaphore sem;
+	struct mutex sem;
 
 	unsigned char      header[SMB_HEADER_LEN + 20*2 + 2];
 	u32                header_len;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/sunrpc/svcsock.h linux-2.6.15-rc5-mutex/include/linux/sunrpc/svcsock.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/sunrpc/svcsock.h	2004-06-18 13:42:15.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/sunrpc/svcsock.h	2005-12-12 17:57:41.000000000 +0000
@@ -36,7 +36,7 @@ struct svc_sock {
 
 	struct list_head	sk_deferred;	/* deferred requests that need to
 						 * be revisted */
-	struct semaphore        sk_sem;		/* to serialize sending data */
+	struct mutex		sk_sem;		/* to serialize sending data */
 
 	int			(*sk_recvfrom)(struct svc_rqst *rqstp);
 	int			(*sk_sendto)(struct svc_rqst *rqstp);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/syscalls.h linux-2.6.15-rc5-mutex/include/linux/syscalls.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/syscalls.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/syscalls.h	2005-12-12 22:12:49.000000000 +0000
@@ -57,7 +57,7 @@ struct mq_attr;
 #include <linux/capability.h>
 #include <linux/list.h>
 #include <linux/sem.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/siginfo.h>
 #include <asm/signal.h>
 #include <linux/quota.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/tty.h linux-2.6.15-rc5-mutex/include/linux/tty.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/tty.h	2005-11-01 13:19:21.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/tty.h	2005-12-12 17:49:23.000000000 +0000
@@ -123,7 +123,7 @@ extern struct screen_info screen_info;
 
 struct tty_flip_buffer {
 	struct work_struct		work;
-	struct semaphore pty_sem;
+	struct mutex	pty_sem;
 	char		*char_buf_ptr;
 	unsigned char	*flag_buf_ptr;
 	int		count;
@@ -245,7 +245,7 @@ struct tty_struct {
 	struct tty_driver *driver;
 	int index;
 	struct tty_ldisc ldisc;
-	struct semaphore termios_sem;
+	struct mutex termios_sem;
 	struct termios *termios, *termios_locked;
 	char name[64];
 	int pgrp;
@@ -290,8 +290,8 @@ struct tty_struct {
 	int canon_data;
 	unsigned long canon_head;
 	unsigned int canon_column;
-	struct semaphore atomic_read;
-	struct semaphore atomic_write;
+	struct mutex atomic_read;
+	struct mutex atomic_write;
 	unsigned char *write_buf;
 	int write_cnt;
 	spinlock_t read_lock;
@@ -378,8 +378,8 @@ extern void tty_ldisc_put(int);
 extern void tty_wakeup(struct tty_struct *tty);
 extern void tty_ldisc_flush(struct tty_struct *tty);
 
-struct semaphore;
-extern struct semaphore tty_sem;
+struct mutex;
+extern struct mutex tty_sem;
 
 /* n_tty.c */
 extern struct tty_ldisc tty_ldisc_N_TTY;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/udf_fs_sb.h linux-2.6.15-rc5-mutex/include/linux/udf_fs_sb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/udf_fs_sb.h	2005-03-02 12:08:59.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/udf_fs_sb.h	2005-12-12 22:12:49.000000000 +0000
@@ -18,7 +18,7 @@
 #ifndef _UDF_FS_SB_H
 #define _UDF_FS_SB_H 1
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #pragma pack(1)
 
@@ -116,7 +116,7 @@ struct udf_sb_info
 	/* VAT inode */
 	struct inode		*s_vat;
 
-	struct semaphore	s_alloc_sem;
+	struct mutex		s_alloc_sem;
 };
 
 #endif /* _UDF_FS_SB_H */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/uinput.h linux-2.6.15-rc5-mutex/include/linux/uinput.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/uinput.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/uinput.h	2005-12-12 19:34:11.000000000 +0000
@@ -51,7 +51,7 @@ struct uinput_request {
 
 struct uinput_device {
 	struct input_dev	*dev;
-	struct semaphore	sem;
+	struct mutex		sem;
 	enum uinput_state	state;
 	wait_queue_head_t	waitq;
 	unsigned char		ready;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/usb.h linux-2.6.15-rc5-mutex/include/linux/usb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/usb.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/usb.h	2005-12-12 19:41:15.000000000 +0000
@@ -329,7 +329,7 @@ struct usb_device {
 	struct usb_tt	*tt; 		/* low/full speed dev, highspeed hub */
 	int		ttport;		/* device port on that tt hub */
 
-	struct semaphore serialize;
+	struct mutex	serialize;
 
 	unsigned int toggle[2];		/* one bit for each endpoint
 					 * ([0] = IN, [1] = OUT) */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/videodev2.h linux-2.6.15-rc5-mutex/include/linux/videodev2.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/videodev2.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/videodev2.h	2005-12-12 19:34:27.000000000 +0000
@@ -80,7 +80,7 @@ struct video_device
 
 	/* for videodev.c intenal usage -- please don't touch */
 	int users;                     /* video_exclusive_{open|close} ... */
-	struct semaphore lock;         /* ... helper function uses these   */
+	struct mutex lock;             /* ... helper function uses these   */
 	char devfs_name[64];           /* devfs */
 	struct class_device class_dev; /* sysfs */
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/vt_kern.h linux-2.6.15-rc5-mutex/include/linux/vt_kern.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/vt_kern.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/vt_kern.h	2005-12-12 17:46:56.000000000 +0000
@@ -81,6 +81,6 @@ void reset_vc(struct vc_data *vc);
 
 #define CON_BUF_SIZE (CONFIG_BASE_SMALL ? 256 : PAGE_SIZE)
 extern char con_buf[CON_BUF_SIZE];
-extern struct semaphore con_buf_sem;
+extern struct mutex con_buf_sem;
 
 #endif /* _VT_KERN_H */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/media/saa7146.h linux-2.6.15-rc5-mutex/include/media/saa7146.h
--- /warthog/kernels/linux-2.6.15-rc5/include/media/saa7146.h	2005-11-01 13:19:21.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/media/saa7146.h	2005-12-12 19:36:26.000000000 +0000
@@ -112,7 +112,7 @@ struct saa7146_dev
 
 	/* different device locks */
 	spinlock_t			slock;
-        struct semaphore		lock;
+        struct mutex			lock;
 
 	unsigned char			__iomem *mem;		/* pointer to mapped IO memory */
 	int				revision;	/* chip revision; needed for bug-workarounds*/
@@ -133,7 +133,7 @@ struct saa7146_dev
 	void (*vv_callback)(struct saa7146_dev *dev, unsigned long status);
 
 	/* i2c-stuff */
-        struct semaphore	i2c_lock;
+        struct mutex		i2c_lock;
 	u32			i2c_bitrate;
 	struct saa7146_dma	d_i2c;	/* pointer to i2c memory */
 	wait_queue_head_t	i2c_wq;
@@ -150,7 +150,7 @@ int saa7146_i2c_transfer(struct saa7146_
 
 /* from saa7146_core.c */
 extern struct list_head saa7146_devices;
-extern struct semaphore saa7146_devices_lock;
+extern struct mutex saa7146_devices_lock;
 int saa7146_register_extension(struct saa7146_extension*);
 int saa7146_unregister_extension(struct saa7146_extension*);
 struct saa7146_format* format_by_fourcc(struct saa7146_dev *dev, int fourcc);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/media/video-buf-dvb.h linux-2.6.15-rc5-mutex/include/media/video-buf-dvb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/media/video-buf-dvb.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/media/video-buf-dvb.h	2005-12-12 19:36:11.000000000 +0000
@@ -11,7 +11,7 @@ struct videobuf_dvb {
 	struct videobuf_queue      dvbq;
 
 	/* video-buf-dvb state info */
-	struct semaphore           lock;
+	struct mutex               lock;
 	struct task_struct         *thread;
 	int                        nfeeds;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/media/video-buf.h linux-2.6.15-rc5-mutex/include/media/video-buf.h
--- /warthog/kernels/linux-2.6.15-rc5/include/media/video-buf.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/media/video-buf.h	2005-12-12 19:36:51.000000000 +0000
@@ -177,7 +177,7 @@ struct videobuf_queue_ops {
 };
 
 struct videobuf_queue {
-	struct semaphore           lock;
+	struct mutex               lock;
 	spinlock_t                 *irqlock;
 	struct pci_dev             *pci;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/net/af_unix.h linux-2.6.15-rc5-mutex/include/net/af_unix.h
--- /warthog/kernels/linux-2.6.15-rc5/include/net/af_unix.h	2005-11-01 13:19:21.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/net/af_unix.h	2005-12-12 17:58:01.000000000 +0000
@@ -71,7 +71,7 @@ struct unix_sock {
         struct unix_address     *addr;
         struct dentry		*dentry;
         struct vfsmount		*mnt;
-        struct semaphore        readsem;
+        struct mutex		readsem;
         struct sock		*peer;
         struct sock		*other;
         struct sock		*gc_tree;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/net/bluetooth/hci_core.h linux-2.6.15-rc5-mutex/include/net/bluetooth/hci_core.h
--- /warthog/kernels/linux-2.6.15-rc5/include/net/bluetooth/hci_core.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/net/bluetooth/hci_core.h	2005-12-12 19:46:23.000000000 +0000
@@ -106,7 +106,7 @@ struct hci_dev {
 
 	struct sk_buff		*sent_cmd;
 
-	struct semaphore	req_lock;
+	struct mutex		req_lock;
 	wait_queue_head_t	req_wait_q;
 	__u32			req_status;
 	__u32			req_result;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/net/xfrm.h linux-2.6.15-rc5-mutex/include/net/xfrm.h
--- /warthog/kernels/linux-2.6.15-rc5/include/net/xfrm.h	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/net/xfrm.h	2005-12-12 19:45:48.000000000 +0000
@@ -19,7 +19,7 @@
 
 #define XFRM_ALIGN8(len)	(((len) + 7) & ~7)
 
-extern struct semaphore xfrm_cfg_sem;
+extern struct mutex xfrm_cfg_sem;
 
 /* Organization of SPD aka "XFRM rules"
    ------------------------------------
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/pcmcia/ss.h linux-2.6.15-rc5-mutex/include/pcmcia/ss.h
--- /warthog/kernels/linux-2.6.15-rc5/include/pcmcia/ss.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/pcmcia/ss.h	2005-12-12 19:47:19.000000000 +0000
@@ -243,7 +243,7 @@ struct pcmcia_socket {
 #endif
 
 	/* state thread */
-	struct semaphore		skt_sem;	/* protects socket h/w state */
+	struct mutex			skt_sem;	/* protects socket h/w state */
 
 	struct task_struct		*thread;
 	struct completion		thread_done;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/scsi/scsi_host.h linux-2.6.15-rc5-mutex/include/scsi/scsi_host.h
--- /warthog/kernels/linux-2.6.15-rc5/include/scsi/scsi_host.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/scsi/scsi_host.h	2005-12-12 19:46:43.000000000 +0000
@@ -464,7 +464,7 @@ struct Scsi_Host {
 	spinlock_t		default_lock;
 	spinlock_t		*host_lock;
 
-	struct semaphore	scan_mutex;/* serialize scanning activity */
+	struct mutex		scan_mutex;/* serialize scanning activity */
 
 	struct list_head	eh_cmd_q;
 	struct task_struct    * ehandler;  /* Error recovery thread. */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/scsi/scsi_transport_spi.h linux-2.6.15-rc5-mutex/include/scsi/scsi_transport_spi.h
--- /warthog/kernels/linux-2.6.15-rc5/include/scsi/scsi_transport_spi.h	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/scsi/scsi_transport_spi.h	2005-12-12 19:46:50.000000000 +0000
@@ -51,7 +51,7 @@ struct spi_transport_attrs {
 	unsigned int support_qas; /* supports quick arbitration and selection */
 	/* Private Fields */
 	unsigned int dv_pending:1; /* Internal flag */
-	struct semaphore dv_sem; /* semaphore to serialise dv */
+	struct mutex dv_sem; /* semaphore to serialise dv */
 };
 
 enum spi_signal_type {

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 14/19] MUTEX: First set of include changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (10 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 13/19] MUTEX: Filesystem changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 12/19] MUTEX: Drivers T-Z changes David Howells
                   ` (20 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the first half of the include files to use the new
mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-include-1-2615rc5.diff
 include/linux/agpgart.h             |    2 +-
 include/linux/audit.h               |    2 +-
 include/linux/backlight.h           |    2 +-
 include/linux/cpu.h                 |    2 +-
 include/linux/cpufreq.h             |    2 +-
 include/linux/devfs_fs_kernel.h     |    2 +-
 include/linux/device.h              |    6 +++---
 include/linux/ext3_fs_i.h           |    2 +-
 include/linux/fs.h                  |   17 +++++++++--------
 include/linux/gameport.h            |    2 +-
 include/linux/generic_serial.h      |    2 +-
 include/linux/hil_mlc.h             |    8 ++++----
 include/linux/hp_sdc.h              |    2 +-
 include/linux/i2c.h                 |    6 +++---
 include/linux/i2o.h                 |    8 ++++----
 include/linux/ide.h                 |   10 +++++-----
 include/linux/if_pppox.h            |    2 +-
 include/linux/input.h               |    2 +-
 include/linux/isdn.h                |    4 ++--
 include/linux/jbd.h                 |    6 +++---
 include/linux/jffs2_fs_i.h          |    4 ++--
 include/linux/jffs2_fs_sb.h         |    6 +++---
 include/linux/kernelcapi.h          |    2 +-
 include/linux/kobj_map.h            |    4 ++--
 include/linux/kthread.h             |    5 +++--
 include/linux/lcd.h                 |    2 +-
 include/linux/libps2.h              |    2 +-
 include/linux/lockd/lockd.h         |    4 ++--
 include/linux/loop.h                |    6 +++---
 include/linux/lp.h                  |    4 ++--
 include/linux/memory.h              |    5 ++---
 include/linux/msdos_fs.h            |    2 +-
 include/linux/mtd/blktrans.h        |    4 ++--
 include/linux/mtd/doc2000.h         |    4 ++--
 include/linux/nbd.h                 |    2 +-
 include/linux/ncp_fs_i.h            |    2 +-
 include/linux/ncp_fs_sb.h           |    4 ++--
 include/linux/netfilter/nfnetlink.h |    2 +-
 include/linux/parport.h             |    4 ++--
 include/linux/quota.h               |    7 ++++---
 include/linux/raid/md.h             |    2 +-
 include/linux/raid/md_k.h           |    2 +-
 include/linux/reiserfs_fs_sb.h      |    6 +++---
 include/linux/rtnetlink.h           |    2 +-
 44 files changed, 89 insertions(+), 87 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/agpgart.h linux-2.6.15-rc5-mutex/include/linux/agpgart.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/agpgart.h	2005-03-02 12:08:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/agpgart.h	2005-12-12 19:30:17.000000000 +0000
@@ -201,7 +201,7 @@ struct agp_file_private {
 };
 
 struct agp_front_data {
-	struct semaphore agp_mutex;
+	struct mutex agp_mutex;
 	struct agp_controller *current_controller;
 	struct agp_controller *controllers;
 	struct agp_file_private *file_priv_list;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/audit.h linux-2.6.15-rc5-mutex/include/linux/audit.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/audit.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/audit.h	2005-12-12 19:39:56.000000000 +0000
@@ -283,7 +283,7 @@ extern void		    audit_send_reply(int pi
 					     int done, int multi,
 					     void *payload, int size);
 extern void		    audit_log_lost(const char *message);
-extern struct semaphore audit_netlink_sem;
+extern struct mutex audit_netlink_sem;
 #else
 #define audit_log(c,g,t,f,...) do { ; } while (0)
 #define audit_log_start(c,g,t) ({ NULL; })
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/backlight.h linux-2.6.15-rc5-mutex/include/linux/backlight.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/backlight.h	2005-03-02 12:08:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/backlight.h	2005-12-12 19:44:11.000000000 +0000
@@ -39,7 +39,7 @@ struct backlight_device {
 	/* This protects the 'props' field. If 'props' is NULL, the driver that
 	   registered this device has been unloaded, and if class_get_devdata()
 	   points to something in the body of that driver, it is also invalid. */
-	struct semaphore sem;
+	struct mutex sem;
 	/* If this is NULL, the backing module is unloaded */
 	struct backlight_properties *props;
 	/* The framebuffer notifier block */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/cpufreq.h linux-2.6.15-rc5-mutex/include/linux/cpufreq.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/cpufreq.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/cpufreq.h	2005-12-12 19:30:49.000000000 +0000
@@ -82,7 +82,7 @@ struct cpufreq_policy {
         unsigned int		policy; /* see above */
 	struct cpufreq_governor	*governor; /* see below */
 
- 	struct semaphore	lock;   /* CPU ->setpolicy or ->target may
+ 	struct mutex		lock;   /* CPU ->setpolicy or ->target may
 					   only be called once a time */
 
 	struct work_struct	update; /* if update_policy() needs to be
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/cpu.h linux-2.6.15-rc5-mutex/include/linux/cpu.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/cpu.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/cpu.h	2005-12-12 22:12:49.000000000 +0000
@@ -23,7 +23,7 @@
 #include <linux/node.h>
 #include <linux/compiler.h>
 #include <linux/cpumask.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct cpu {
 	int node_id;		/* The node which contains the CPU */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/devfs_fs_kernel.h linux-2.6.15-rc5-mutex/include/linux/devfs_fs_kernel.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/devfs_fs_kernel.h	2004-06-18 13:42:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/devfs_fs_kernel.h	2005-12-12 22:12:49.000000000 +0000
@@ -6,7 +6,7 @@
 #include <linux/spinlock.h>
 #include <linux/types.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define DEVFS_SUPER_MAGIC                0x1373
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/device.h linux-2.6.15-rc5-mutex/include/linux/device.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/device.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/device.h	2005-12-12 22:12:49.000000000 +0000
@@ -19,7 +19,7 @@
 #include <linux/types.h>
 #include <linux/module.h>
 #include <linux/pm.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/atomic.h>
 
 #define DEVICE_NAME_SIZE	50
@@ -146,7 +146,7 @@ struct class {
 	struct subsystem	subsys;
 	struct list_head	children;
 	struct list_head	interfaces;
-	struct semaphore	sem;	/* locks both the children and interfaces lists */
+	struct mutex		sem;	/* locks both the children and interfaces lists */
 
 	struct class_attribute		* class_attrs;
 	struct class_device_attribute	* class_dev_attrs;
@@ -310,7 +310,7 @@ struct device {
 	char	bus_id[BUS_ID_SIZE];	/* position on parent bus */
 	struct device_attribute uevent_attr;
 
-	struct semaphore	sem;	/* semaphore to synchronize calls to
+	struct mutex	sem;		/* semaphore to synchronize calls to
 					 * its driver.
 					 */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/ext3_fs_i.h linux-2.6.15-rc5-mutex/include/linux/ext3_fs_i.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/ext3_fs_i.h	2005-06-22 13:52:32.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/ext3_fs_i.h	2005-12-12 17:34:02.000000000 +0000
@@ -131,7 +131,7 @@ struct ext3_inode_info {
 	 * during recovery.  Hence we must fix the get_block-vs-truncate race
 	 * by other means, so we have truncate_sem.
 	 */
-	struct semaphore truncate_sem;
+	struct mutex truncate_sem;
 	struct inode vfs_inode;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/fs.h linux-2.6.15-rc5-mutex/include/linux/fs.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/fs.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/fs.h	2005-12-12 22:12:49.000000000 +0000
@@ -10,6 +10,7 @@
 #include <linux/limits.h>
 #include <linux/ioctl.h>
 #include <linux/rcuref.h>
+#include <linux/semaphore.h>
 
 /*
  * It's silly to have NR_OPEN bigger than NR_FILE, but you can change
@@ -220,9 +221,9 @@ extern int dir_notify_enable;
 #include <linux/prio_tree.h>
 #include <linux/init.h>
 #include <linux/sched.h>
+#include <linux/semaphore.h>
 
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
 #include <asm/byteorder.h>
 
 struct iovec;
@@ -368,8 +369,8 @@ struct block_device {
 	dev_t			bd_dev;  /* not a kdev_t - it's a search key */
 	struct inode *		bd_inode;	/* will die */
 	int			bd_openers;
-	struct semaphore	bd_sem;	/* open/close mutex */
-	struct semaphore	bd_mount_sem;	/* mount mutex */
+	struct mutex		bd_sem;	/* open/close mutex */
+	struct mutex		bd_mount_sem;	/* mount mutex */
 	struct list_head	bd_inodes;
 	void *			bd_holder;
 	int			bd_holders;
@@ -453,7 +454,7 @@ struct inode {
 	unsigned long		i_blocks;
 	unsigned short          i_bytes;
 	spinlock_t		i_lock;	/* i_blocks, i_bytes, maybe i_size */
-	struct semaphore	i_sem;
+	struct mutex		i_sem;
 	struct rw_semaphore	i_alloc_sem;
 	struct inode_operations	*i_op;
 	struct file_operations	*i_fop;	/* former ->i_op->default_file_ops */
@@ -480,7 +481,7 @@ struct inode {
 
 #ifdef CONFIG_INOTIFY
 	struct list_head	inotify_watches; /* watches on this inode */
-	struct semaphore	inotify_sem;	/* protects the watches list */
+	struct mutex		inotify_sem;	/* protects the watches list */
 #endif
 
 	unsigned long		i_state;
@@ -790,7 +791,7 @@ struct super_block {
 	unsigned long		s_magic;
 	struct dentry		*s_root;
 	struct rw_semaphore	s_umount;
-	struct semaphore	s_lock;
+	struct mutex		s_lock;
 	int			s_count;
 	int			s_syncing;
 	int			s_need_sync_fs;
@@ -819,7 +820,7 @@ struct super_block {
 	 * The next field is for VFS *only*. No filesystems have any business
 	 * even looking at it. You had been warned.
 	 */
-	struct semaphore s_vfs_rename_sem;	/* Kludge */
+	struct mutex s_vfs_rename_sem;	/* Kludge */
 
 	/* Granuality of c/m/atime in ns.
 	   Cannot be worse than a second */
@@ -1496,7 +1497,7 @@ extern void destroy_inode(struct inode *
 extern struct inode *new_inode(struct super_block *);
 extern int remove_suid(struct dentry *);
 extern void remove_dquot_ref(struct super_block *, int, struct list_head *);
-extern struct semaphore iprune_sem;
+extern struct mutex iprune_sem;
 
 extern void __insert_inode_hash(struct inode *, unsigned long hashval);
 extern void remove_inode_hash(struct inode *);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/gameport.h linux-2.6.15-rc5-mutex/include/linux/gameport.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/gameport.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/gameport.h	2005-12-12 19:31:08.000000000 +0000
@@ -40,7 +40,7 @@ struct gameport {
 	struct gameport *parent, *child;
 
 	struct gameport_driver *drv;
-	struct semaphore drv_sem;	/* protects serio->drv so attributes can pin driver */
+	struct mutex drv_sem;		/* protects serio->drv so attributes can pin driver */
 
 	struct device dev;
 	unsigned int registered;	/* port has been fully registered with driver core */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/generic_serial.h linux-2.6.15-rc5-mutex/include/linux/generic_serial.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/generic_serial.h	2005-06-22 13:52:32.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/generic_serial.h	2005-12-12 19:31:20.000000000 +0000
@@ -34,7 +34,7 @@ struct gs_port {
   int                     xmit_head;
   int                     xmit_tail;
   int                     xmit_cnt;
-  struct semaphore        port_write_sem;
+  struct mutex            port_write_sem;
   int                     flags;
   wait_queue_head_t       open_wait;
   wait_queue_head_t       close_wait;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/hil_mlc.h linux-2.6.15-rc5-mutex/include/linux/hil_mlc.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/hil_mlc.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/hil_mlc.h	2005-12-12 22:12:49.000000000 +0000
@@ -34,7 +34,7 @@
 #include <linux/hil.h>
 #include <linux/time.h>
 #include <linux/interrupt.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/serio.h>
 #include <linux/list.h>
 
@@ -133,14 +133,14 @@ struct hil_mlc {
 	int			istarted, ostarted;
 
 	hil_mlc_cts		*cts;
-	struct semaphore	csem;   /* Raised when loop idle */
+	struct mutex		csem;   /* Raised when loop idle */
 
 	hil_mlc_out		*out;
-	struct semaphore	osem;   /* Raised when outpacket dispatched */
+	struct mutex		osem;   /* Raised when outpacket dispatched */
 	hil_packet		opacket;
 
 	hil_mlc_in		*in;
-	struct semaphore	isem;   /* Raised when a packet arrives */
+	struct mutex		isem;   /* Raised when a packet arrives */
 	hil_packet		ipacket[16];
 	hil_packet		imatch;
 	int			icount;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/hp_sdc.h linux-2.6.15-rc5-mutex/include/linux/hp_sdc.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/hp_sdc.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/hp_sdc.h	2005-12-12 19:43:52.000000000 +0000
@@ -68,7 +68,7 @@ typedef struct {
 	uint8_t *seq;	/* commands/data for the transaction */
 	union {
 	  hp_sdc_irqhook   *irqhook;	/* Callback, isr or tasklet context */
-	  struct semaphore *semaphore;	/* Semaphore to sleep on. */
+	  struct mutex     *semaphore;	/* Semaphore to sleep on. */
 	} act;
 } hp_sdc_transaction;
 int hp_sdc_enqueue_transaction(hp_sdc_transaction *this);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/i2c.h linux-2.6.15-rc5-mutex/include/linux/i2c.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/i2c.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/i2c.h	2005-12-12 22:12:49.000000000 +0000
@@ -32,7 +32,7 @@
 #include <linux/mod_devicetable.h>
 #include <linux/device.h>	/* for struct device */
 #include <linux/sched.h>	/* for completion */
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* --- For i2c-isa ---------------------------------------------------- */
 
@@ -222,8 +222,8 @@ struct i2c_adapter {
 	int (*client_unregister)(struct i2c_client *);
 
 	/* data fields that are valid for all devices	*/
-	struct semaphore bus_lock;
-	struct semaphore clist_lock;
+	struct mutex bus_lock;
+	struct mutex clist_lock;
 
 	int timeout;
 	int retries;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/i2o.h linux-2.6.15-rc5-mutex/include/linux/i2o.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/i2o.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/i2o.h	2005-12-12 22:12:49.000000000 +0000
@@ -30,9 +30,9 @@
 #include <linux/string.h>
 #include <linux/slab.h>
 #include <linux/workqueue.h>	/* work_struct */
+#include <linux/semaphore.h>
 
 #include <asm/io.h>
-#include <asm/semaphore.h>	/* Needed for MUTEX init macros */
 
 /* message queue empty */
 #define I2O_QUEUE_EMPTY		0xffffffff
@@ -69,7 +69,7 @@ struct i2o_device {
 
 	struct device device;
 
-	struct semaphore lock;	/* device lock */
+	struct mutex lock;	/* device lock */
 };
 
 /*
@@ -117,7 +117,7 @@ struct i2o_driver {
 	void (*notify_device_add) (struct i2o_device *);
 	void (*notify_device_remove) (struct i2o_device *);
 
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 /*
@@ -181,7 +181,7 @@ struct i2o_controller {
 	struct i2o_dma hrt;	/* HW Resource Table */
 	i2o_lct *lct;		/* Logical Config Table */
 	struct i2o_dma dlct;	/* Temp LCT */
-	struct semaphore lct_lock;	/* Lock for LCT updates */
+	struct mutex lct_lock;	/* Lock for LCT updates */
 	struct i2o_dma status_block;	/* IOP status block */
 
 	struct i2o_io base;	/* controller messaging unit */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/ide.h linux-2.6.15-rc5-mutex/include/linux/ide.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/ide.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/ide.h	2005-12-12 22:12:49.000000000 +0000
@@ -18,10 +18,10 @@
 #include <linux/bio.h>
 #include <linux/device.h>
 #include <linux/pci.h>
+#include <linux/semaphore.h>
 #include <asm/byteorder.h>
 #include <asm/system.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
 
 /*
  * This is the multiple IDE interface driver, as evolved from hd.c.
@@ -759,7 +759,7 @@ typedef struct ide_drive_s {
 	int		crc_count;	/* crc counter to reduce drive speed */
 	struct list_head list;
 	struct device	gendev;
-	struct semaphore gendev_rel_sem;	/* to deal with device release() */
+	struct mutex	gendev_rel_sem;	/* to deal with device release() */
 } ide_drive_t;
 
 #define to_ide_device(dev)container_of(dev, ide_drive_t, gendev)
@@ -915,7 +915,7 @@ typedef struct hwif_s {
 	unsigned	sg_mapped  : 1;	/* sg_table and sg_nents are ready */
 
 	struct device	gendev;
-	struct semaphore gendev_rel_sem; /* To deal with device release() */
+	struct mutex	gendev_rel_sem; /* To deal with device release() */
 
 	void		*hwif_data;	/* extra hwif data */
 
@@ -1000,7 +1000,7 @@ typedef struct ide_settings_s {
 	struct ide_settings_s	*next;
 } ide_settings_t;
 
-extern struct semaphore ide_setting_sem;
+extern struct mutex ide_setting_sem;
 extern int ide_add_setting(ide_drive_t *drive, const char *name, int rw, int read_ioctl, int write_ioctl, int data_type, int min, int max, int mul_factor, int div_factor, void *data, ide_procset_t *set);
 extern ide_settings_t *ide_find_setting_by_name(ide_drive_t *drive, char *name);
 extern int ide_read_setting(ide_drive_t *t, ide_settings_t *setting);
@@ -1458,7 +1458,7 @@ extern const ide_pio_timings_t ide_pio_t
 
 
 extern spinlock_t ide_lock;
-extern struct semaphore ide_cfg_sem;
+extern struct mutex ide_cfg_sem;
 /*
  * Structure locking:
  *
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/if_pppox.h linux-2.6.15-rc5-mutex/include/linux/if_pppox.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/if_pppox.h	2005-06-22 13:52:32.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/if_pppox.h	2005-12-12 22:12:49.000000000 +0000
@@ -24,7 +24,7 @@
 #include <linux/if_ether.h>
 #include <linux/if.h>
 #include <linux/netdevice.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/ppp_channel.h>
 #endif /* __KERNEL__ */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/input.h linux-2.6.15-rc5-mutex/include/linux/input.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/input.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/input.h	2005-12-12 17:51:08.000000000 +0000
@@ -888,7 +888,7 @@ struct input_dev {
 
 	struct input_handle *grab;
 
-	struct semaphore sem;	/* serializes open and close operations */
+	struct mutex sem;	/* serializes open and close operations */
 	unsigned int users;
 
 	struct class_device cdev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/isdn.h linux-2.6.15-rc5-mutex/include/linux/isdn.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/isdn.h	2005-11-01 13:19:20.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/isdn.h	2005-12-12 19:32:14.000000000 +0000
@@ -515,7 +515,7 @@ typedef struct modem_info {
   struct termios	normal_termios;  /* For saving termios structs     */
   struct termios	callout_termios;
   wait_queue_head_t	open_wait, close_wait;
-  struct semaphore      write_sem;
+  struct mutex		write_sem;
   spinlock_t	        readlock;
 } modem_info;
 
@@ -625,7 +625,7 @@ typedef struct isdn_devt {
 	int               v110emu[ISDN_MAX_CHANNELS]; /* V.110 emulator-mode 0=none */
 	atomic_t          v110use[ISDN_MAX_CHANNELS]; /* Usage-Semaphore for stream */
 	isdn_v110_stream  *v110[ISDN_MAX_CHANNELS];   /* V.110 private data         */
-	struct semaphore  sem;                        /* serialize list access*/
+	struct mutex      sem;                        /* serialize list access*/
 	unsigned long     global_features;
 } isdn_dev;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/jbd.h linux-2.6.15-rc5-mutex/include/linux/jbd.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/jbd.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/jbd.h	2005-12-12 22:12:49.000000000 +0000
@@ -27,7 +27,7 @@
 #include <linux/journal-head.h>
 #include <linux/stddef.h>
 #include <linux/bit_spinlock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #endif
 
 #define journal_oom_retry 1
@@ -644,7 +644,7 @@ struct journal_s
 	int			j_barrier_count;
 
 	/* The barrier lock itself */
-	struct semaphore	j_barrier;
+	struct mutex		j_barrier;
 
 	/*
 	 * Transactions: The current running transaction...
@@ -686,7 +686,7 @@ struct journal_s
 	wait_queue_head_t	j_wait_updates;
 
 	/* Semaphore for locking against concurrent checkpoints */
-	struct semaphore 	j_checkpoint_sem;
+	struct mutex		j_checkpoint_sem;
 
 	/*
 	 * Journal head: identifies the first unused block in the journal.
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/jffs2_fs_i.h linux-2.6.15-rc5-mutex/include/linux/jffs2_fs_i.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/jffs2_fs_i.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/jffs2_fs_i.h	2005-12-12 22:12:49.000000000 +0000
@@ -5,7 +5,7 @@
 
 #include <linux/version.h>
 #include <linux/rbtree.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct jffs2_inode_info {
 	/* We need an internal semaphore similar to inode->i_sem.
@@ -14,7 +14,7 @@ struct jffs2_inode_info {
 	   before letting GC proceed. Or we'd have to put ugliness
 	   into the GC code so it didn't attempt to obtain the i_sem
 	   for the inode(s) which are already locked */
-	struct semaphore sem;
+	struct mutex sem;
 
 	/* The highest (datanode) version number used for this ino */
 	uint32_t highest_version;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/jffs2_fs_sb.h linux-2.6.15-rc5-mutex/include/linux/jffs2_fs_sb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/jffs2_fs_sb.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/jffs2_fs_sb.h	2005-12-12 22:12:49.000000000 +0000
@@ -7,7 +7,7 @@
 #include <linux/spinlock.h>
 #include <linux/workqueue.h>
 #include <linux/completion.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/timer.h>
 #include <linux/wait.h>
 #include <linux/list.h>
@@ -35,7 +35,7 @@ struct jffs2_sb_info {
 	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
+	struct mutex alloc_sem;	/* Used to protect all the following
 					   fields, and also to protect against
 					   out-of-order writing of nodes. And GC. */
 	uint32_t cleanmarker_size;	/* Size of an _inline_ CLEANMARKER
@@ -93,7 +93,7 @@ struct jffs2_sb_info {
 	/* Sem to allow jffs2_garbage_collect_deletion_dirent to
 	   drop the erase_completion_lock while it's holding a pointer
 	   to an obsoleted node. I don't like this. Alternatives welcomed. */
-	struct semaphore erase_free_sem;
+	struct mutex erase_free_sem;
 
 	uint32_t wbuf_pagesize; /* 0 for NOR and other flashes with no wbuf */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/kernelcapi.h linux-2.6.15-rc5-mutex/include/linux/kernelcapi.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/kernelcapi.h	2004-09-16 12:06:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/kernelcapi.h	2005-12-12 19:32:42.000000000 +0000
@@ -62,7 +62,7 @@ struct capi20_appl {
 	unsigned long nrecvdatapkt;
 	unsigned long nsentctlpkt;
 	unsigned long nsentdatapkt;
-	struct semaphore recv_sem;
+	struct mutex recv_sem;
 	struct sk_buff_head recv_queue;
 	struct work_struct recv_work;
 	int release_in_progress;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/kobj_map.h linux-2.6.15-rc5-mutex/include/linux/kobj_map.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/kobj_map.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/kobj_map.h	2005-12-12 22:12:49.000000000 +0000
@@ -1,6 +1,6 @@
 #ifdef __KERNEL__
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 typedef struct kobject *kobj_probe_t(dev_t, int *, void *);
 struct kobj_map;
@@ -9,6 +9,6 @@ int kobj_map(struct kobj_map *, dev_t, u
 	     kobj_probe_t *, int (*)(dev_t, void *), void *);
 void kobj_unmap(struct kobj_map *, dev_t, unsigned long);
 struct kobject *kobj_lookup(struct kobj_map *, dev_t, int *);
-struct kobj_map *kobj_map_init(kobj_probe_t *, struct semaphore *);
+struct kobj_map *kobj_map_init(kobj_probe_t *, struct mutex *);
 
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/kthread.h linux-2.6.15-rc5-mutex/include/linux/kthread.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/kthread.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/kthread.h	2005-12-12 22:12:49.000000000 +0000
@@ -3,6 +3,7 @@
 /* Simple interface for creating and stopping kernel threads without mess. */
 #include <linux/err.h>
 #include <linux/sched.h>
+#include <linux/semaphore.h>
 
 /**
  * kthread_create: create a kthread.
@@ -72,14 +73,14 @@ int kthread_stop(struct task_struct *k);
 /**
  * kthread_stop_sem: stop a thread created by kthread_create().
  * @k: thread created by kthread_create().
- * @s: semaphore that @k waits on while idle.
+ * @s: mutex that @k waits on while idle.
  *
  * Does essentially the same thing as kthread_stop() above, but wakes
  * @k by calling up(@s).
  *
  * Returns the result of threadfn(), or -EINTR if wake_up_process()
  * was never called. */
-int kthread_stop_sem(struct task_struct *k, struct semaphore *s);
+int kthread_stop_sem(struct task_struct *k, struct mutex *s);
 
 /**
  * kthread_should_stop: should this kthread return now?
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/lcd.h linux-2.6.15-rc5-mutex/include/linux/lcd.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/lcd.h	2005-03-02 12:08:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/lcd.h	2005-12-12 19:32:48.000000000 +0000
@@ -38,7 +38,7 @@ struct lcd_device {
 	/* This protects the 'props' field. If 'props' is NULL, the driver that
 	   registered this device has been unloaded, and if class_get_devdata()
 	   points to something in the body of that driver, it is also invalid. */
-	struct semaphore sem;
+	struct mutex sem;
 	/* If this is NULL, the backing module is unloaded */
 	struct lcd_properties *props;
 	/* The framebuffer notifier block */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/libps2.h linux-2.6.15-rc5-mutex/include/linux/libps2.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/libps2.h	2005-08-30 13:56:36.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/libps2.h	2005-12-12 18:02:54.000000000 +0000
@@ -28,7 +28,7 @@ struct ps2dev {
 	struct serio *serio;
 
 	/* Ensures that only one command is executing at a time */
-	struct semaphore cmd_sem;
+	struct mutex cmd_sem;
 
 	/* Used to signal completion from interrupt handler */
 	wait_queue_head_t wait;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/lockd/lockd.h linux-2.6.15-rc5-mutex/include/linux/lockd/lockd.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/lockd/lockd.h	2005-08-30 13:56:36.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/lockd/lockd.h	2005-12-12 17:38:48.000000000 +0000
@@ -53,7 +53,7 @@ struct nlm_host {
 	u32			h_nsmstate;	/* true remote NSM state */
 	u32			h_pidcount;	/* Pseudopids */
 	atomic_t		h_count;	/* reference count */
-	struct semaphore	h_sema;		/* mutex for pmap binding */
+	struct mutex		h_sema;		/* mutex for pmap binding */
 	unsigned long		h_nextrebind;	/* next portmap call */
 	unsigned long		h_expires;	/* eligible for GC */
 	struct list_head	h_lockowners;	/* Lockowners for the client */
@@ -99,7 +99,7 @@ struct nlm_file {
 	struct nlm_block *	f_blocks;	/* blocked locks */
 	unsigned int		f_locks;	/* guesstimate # of locks */
 	unsigned int		f_count;	/* reference count */
-	struct semaphore	f_sema;		/* avoid concurrent access */
+	struct mutex		f_sema;		/* avoid concurrent access */
 	int		       	f_hash;		/* hash of f_handle */
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/loop.h linux-2.6.15-rc5-mutex/include/linux/loop.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/loop.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/loop.h	2005-12-12 17:45:34.000000000 +0000
@@ -58,9 +58,9 @@ struct loop_device {
 	struct bio 		*lo_bio;
 	struct bio		*lo_biotail;
 	int			lo_state;
-	struct semaphore	lo_sem;
-	struct semaphore	lo_ctl_mutex;
-	struct semaphore	lo_bh_mutex;
+	struct mutex		lo_sem;
+	struct mutex		lo_ctl_mutex;
+	struct mutex		lo_bh_mutex;
 	int			lo_pending;
 
 	request_queue_t		*lo_queue;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/lp.h linux-2.6.15-rc5-mutex/include/linux/lp.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/lp.h	2005-03-02 12:08:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/lp.h	2005-12-12 22:12:49.000000000 +0000
@@ -99,7 +99,7 @@
 #ifdef __KERNEL__
 
 #include <linux/wait.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* Magic numbers for defining port-device mappings */
 #define LP_PARPORT_UNSPEC -4
@@ -145,7 +145,7 @@ struct lp_struct {
 #endif
 	wait_queue_head_t waitq;
 	unsigned int last_error;
-	struct semaphore port_mutex;
+	struct mutex port_mutex;
 	wait_queue_head_t dataq;
 	long timeout;
 	unsigned int best_mode;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/memory.h linux-2.6.15-rc5-mutex/include/linux/memory.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/memory.h	2005-12-08 16:23:54.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/memory.h	2005-12-12 22:12:49.000000000 +0000
@@ -18,8 +18,7 @@
 #include <linux/sysdev.h>
 #include <linux/node.h>
 #include <linux/compiler.h>
-
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct memory_block {
 	unsigned long phys_index;
@@ -30,7 +29,7 @@ struct memory_block {
 	 * created long after the critical areas during
 	 * initialization.
 	 */
-	struct semaphore state_sem;
+	struct mutex state_sem;
 	int phys_device;		/* to which fru does this belong? */
 	void *hw;			/* optional pointer to fw/hw data */
 	int (*phys_callback)(struct memory_block *);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/msdos_fs.h linux-2.6.15-rc5-mutex/include/linux/msdos_fs.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/msdos_fs.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/msdos_fs.h	2005-12-12 17:34:19.000000000 +0000
@@ -226,7 +226,7 @@ struct msdos_sb_info {
 	unsigned long max_cluster;   /* maximum cluster number */
 	unsigned long root_cluster;  /* first cluster of the root directory */
 	unsigned long fsinfo_sector; /* sector number of FAT32 fsinfo */
-	struct semaphore fat_lock;
+	struct mutex fat_lock;
 	unsigned int prev_free;      /* previously allocated cluster number */
 	unsigned int free_clusters;  /* -1 if undefined */
 	struct fat_mount_options options;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/mtd/blktrans.h linux-2.6.15-rc5-mutex/include/linux/mtd/blktrans.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/mtd/blktrans.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/mtd/blktrans.h	2005-12-12 22:12:49.000000000 +0000
@@ -10,7 +10,7 @@
 #ifndef __MTD_TRANS_H__
 #define __MTD_TRANS_H__
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct hd_geometry;
 struct mtd_info;
@@ -22,7 +22,7 @@ struct mtd_blktrans_dev {
 	struct mtd_blktrans_ops *tr;
 	struct list_head list;
 	struct mtd_info *mtd;
-	struct semaphore sem;
+	struct mutex sem;
 	int devnum;
 	int blksize;
 	unsigned long size;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/mtd/doc2000.h linux-2.6.15-rc5-mutex/include/linux/mtd/doc2000.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/mtd/doc2000.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/mtd/doc2000.h	2005-12-12 22:12:49.000000000 +0000
@@ -15,7 +15,7 @@
 #define __MTD_DOC2000_H__
 
 #include <linux/mtd/mtd.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define DoC_Sig1 0
 #define DoC_Sig2 1
@@ -187,7 +187,7 @@ struct DiskOnChip {
 	int numchips;
 	struct Nand *chips;
 	struct mtd_info *nextdoc;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 int doc_decode_ecc(unsigned char sector[512], unsigned char ecc1[6]);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/nbd.h linux-2.6.15-rc5-mutex/include/linux/nbd.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/nbd.h	2004-06-18 13:42:16.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/nbd.h	2005-12-12 19:33:00.000000000 +0000
@@ -49,7 +49,7 @@ struct nbd_device {
 	int magic;
 	spinlock_t queue_lock;
 	struct list_head queue_head;/* Requests are added here...	*/
-	struct semaphore tx_lock;
+	struct mutex tx_lock;
 	struct gendisk *disk;
 	int blksize;
 	u64 bytesize;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/ncp_fs_i.h linux-2.6.15-rc5-mutex/include/linux/ncp_fs_i.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/ncp_fs_i.h	2004-10-19 10:42:17.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/ncp_fs_i.h	2005-12-12 19:33:05.000000000 +0000
@@ -19,7 +19,7 @@ struct ncp_inode_info {
 	__le32	DosDirNum;
 	__u8	volNumber;
 	__le32	nwattr;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	atomic_t	opened;
 	int	access;
 	int	flags;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/ncp_fs_sb.h linux-2.6.15-rc5-mutex/include/linux/ncp_fs_sb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/ncp_fs_sb.h	2004-06-18 13:42:15.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/ncp_fs_sb.h	2005-12-12 19:33:16.000000000 +0000
@@ -51,7 +51,7 @@ struct ncp_server {
 				   receive replies */
 
 	int lock;		/* To prevent mismatch in protocols. */
-	struct semaphore sem;
+	struct mutex sem;
 
 	int current_size;	/* for packet preparation */
 	int has_subfunction;
@@ -96,7 +96,7 @@ struct ncp_server {
 	struct {
 		struct work_struct tq;		/* STREAM/DGRAM: data/error ready */
 		struct ncp_request_reply* creq;	/* STREAM/DGRAM: awaiting reply from this request */
-		struct semaphore creq_sem;	/* DGRAM only: lock accesses to rcv.creq */
+		struct mutex creq_sem;		/* DGRAM only: lock accesses to rcv.creq */
 
 		unsigned int state;		/* STREAM only: receiver state */
 		struct {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/netfilter/nfnetlink.h linux-2.6.15-rc5-mutex/include/linux/netfilter/nfnetlink.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/netfilter/nfnetlink.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/netfilter/nfnetlink.h	2005-12-12 19:41:44.000000000 +0000
@@ -129,7 +129,7 @@ extern void __nfa_fill(struct sk_buff *s
 ({ if (skb_tailroom(skb) < (int)NFA_SPACE(attrlen)) goto nfattr_failure; \
    __nfa_fill(skb, attrtype, attrlen, data); })
 
-extern struct semaphore nfnl_sem;
+extern struct mutex nfnl_sem;
 
 #define nfnl_shlock()		down(&nfnl_sem)
 #define nfnl_shlock_nowait()	down_trylock(&nfnl_sem)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/parport.h linux-2.6.15-rc5-mutex/include/linux/parport.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/parport.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/parport.h	2005-12-12 22:12:49.000000000 +0000
@@ -101,9 +101,9 @@ typedef enum {
 #include <linux/proc_fs.h>
 #include <linux/spinlock.h>
 #include <linux/wait.h>
+#include <linux/semaphore.h>
 #include <asm/system.h>
 #include <asm/ptrace.h>
-#include <asm/semaphore.h>
 
 /* Define this later. */
 struct parport;
@@ -254,7 +254,7 @@ enum ieee1284_phase {
 struct ieee1284_info {
 	int mode;
 	volatile enum ieee1284_phase phase;
-	struct semaphore irq;
+	struct mutex irq;
 };
 
 /* A parallel port */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/quota.h linux-2.6.15-rc5-mutex/include/linux/quota.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/quota.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/quota.h	2005-12-12 22:12:49.000000000 +0000
@@ -38,6 +38,7 @@
 #include <linux/errno.h>
 #include <linux/types.h>
 #include <linux/spinlock.h>
+#include <linux/semaphore.h>
 
 #define __DQUOT_VERSION__	"dquot_6.5.1"
 #define __DQUOT_NUM_VERSION__	6*10000+5*100+1
@@ -215,7 +216,7 @@ struct dquot {
 	struct list_head dq_inuse;	/* List of all quotas */
 	struct list_head dq_free;	/* Free list element */
 	struct list_head dq_dirty;	/* List of dirty dquots */
-	struct semaphore dq_lock;	/* dquot IO lock */
+	struct mutex dq_lock;		/* dquot IO lock */
 	atomic_t dq_count;		/* Use count */
 	wait_queue_head_t dq_wait_unused;	/* Wait queue for dquot to become unused */
 	struct super_block *dq_sb;	/* superblock this applies to */
@@ -285,8 +286,8 @@ struct quota_format_type {
 
 struct quota_info {
 	unsigned int flags;			/* Flags for diskquotas on this device */
-	struct semaphore dqio_sem;		/* lock device while I/O in progress */
-	struct semaphore dqonoff_sem;		/* Serialize quotaon & quotaoff */
+	struct mutex dqio_sem;			/* lock device while I/O in progress */
+	struct mutex dqonoff_sem;		/* Serialize quotaon & quotaoff */
 	struct rw_semaphore dqptr_sem;		/* serialize ops using quota_info struct, pointers from inode to dquots */
 	struct inode *files[MAXQUOTAS];		/* inodes of quotafiles */
 	struct mem_dqinfo info[MAXQUOTAS];	/* Information for each quota type */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/raid/md.h linux-2.6.15-rc5-mutex/include/linux/raid/md.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/raid/md.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/raid/md.h	2005-12-12 22:12:49.000000000 +0000
@@ -19,7 +19,7 @@
 #define _MD_H
 
 #include <linux/blkdev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/major.h>
 #include <linux/ioctl.h>
 #include <linux/types.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/raid/md_k.h linux-2.6.15-rc5-mutex/include/linux/raid/md_k.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/raid/md_k.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/raid/md_k.h	2005-12-12 19:40:30.000000000 +0000
@@ -204,7 +204,7 @@ struct mddev_s
 	unsigned long			recovery;
 
 	int				in_sync;	/* know to not need resync */
-	struct semaphore		reconfig_sem;
+	struct mutex			reconfig_sem;
 	atomic_t			active;
 
 	int				changed;	/* true if we might need to reread partition info */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/reiserfs_fs_sb.h linux-2.6.15-rc5-mutex/include/linux/reiserfs_fs_sb.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/reiserfs_fs_sb.h	2005-08-30 13:56:37.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/linux/reiserfs_fs_sb.h	2005-12-12 19:44:40.000000000 +0000
@@ -152,7 +152,7 @@ struct reiserfs_journal_list {
 	atomic_t j_nonzerolen;
 	atomic_t j_commit_left;
 	atomic_t j_older_commits_done;	/* all commits older than this on disk */
-	struct semaphore j_commit_lock;
+	struct mutex j_commit_lock;
 	unsigned long j_trans_id;
 	time_t j_timestamp;
 	struct reiserfs_list_bitmap *j_list_bitmap;
@@ -194,8 +194,8 @@ struct reiserfs_journal {
 	struct buffer_head *j_header_bh;
 
 	time_t j_trans_start_time;	/* time this transaction started */
-	struct semaphore j_lock;
-	struct semaphore j_flush_sem;
+	struct mutex j_lock;
+	struct mutex j_flush_sem;
 	wait_queue_head_t j_join_wait;	/* wait for current transaction to finish before starting new one */
 	atomic_t j_jlock;	/* lock for j_join_wait */
 	int j_list_bitmap_index;	/* number of next list bitmap to use */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/linux/rtnetlink.h linux-2.6.15-rc5-mutex/include/linux/rtnetlink.h
--- /warthog/kernels/linux-2.6.15-rc5/include/linux/rtnetlink.h	2005-11-01 13:19:21.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/linux/rtnetlink.h	2005-12-12 17:55:26.000000000 +0000
@@ -1032,7 +1032,7 @@ __rta_reserve(struct sk_buff *skb, int a
 
 extern void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change);
 
-extern struct semaphore rtnl_sem;
+extern struct mutex rtnl_sem;
 
 #define rtnl_shlock()		down(&rtnl_sem)
 #define rtnl_shlock_nowait()	down_trylock(&rtnl_sem)

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 10/19] MUTEX: Drivers N-P changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (7 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 15/19] MUTEX: Second set of include changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 9/19] MUTEX: Drivers L-M changes David Howells
                   ` (23 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/n* thru drivers/p* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-NtoP-2615rc5.diff
 drivers/net/3c527.c                       |    4 ++--
 drivers/net/cassini.h                     |    2 +-
 drivers/net/chelsio/common.h              |    2 +-
 drivers/net/hamradio/6pack.c              |    4 ++--
 drivers/net/hamradio/mkiss.c              |    2 +-
 drivers/net/ibmveth.c                     |    2 +-
 drivers/net/irda/sir-dev.h                |    2 +-
 drivers/net/irda/vlsi_ir.h                |    2 +-
 drivers/net/plip.c                        |    4 ++--
 drivers/net/ppp_async.c                   |    2 +-
 drivers/net/ppp_synctty.c                 |    4 ++--
 drivers/net/sungem.h                      |    2 +-
 drivers/net/wan/cosa.c                    |    2 +-
 drivers/net/wireless/airo.c               |    4 ++--
 drivers/net/wireless/hostap/hostap_wlan.h |    2 +-
 drivers/net/wireless/ipw2100.c            |    4 ++--
 drivers/net/wireless/ipw2100.h            |    4 ++--
 drivers/net/wireless/ipw2200.h            |    2 +-
 drivers/net/wireless/prism54/isl_ioctl.c  |    4 ++--
 drivers/net/wireless/prism54/islpci_dev.c |    4 ++--
 drivers/net/wireless/prism54/islpci_dev.h |    8 ++++----
 drivers/oprofile/event_buffer.h           |    4 ++--
 drivers/oprofile/oprof.c                  |    2 +-
 drivers/pci/hotplug/acpiphp.h             |    2 +-
 drivers/pci/hotplug/acpiphp_glue.c        |    2 +-
 drivers/pci/hotplug/cpci_hotplug_core.c   |    4 ++--
 drivers/pci/hotplug/cpqphp.h              |    2 +-
 drivers/pci/hotplug/cpqphp_ctrl.c         |    6 +++---
 drivers/pci/hotplug/ibmphp_hpc.c          |    6 +++---
 drivers/pci/hotplug/pciehp.h              |    2 +-
 drivers/pci/hotplug/pciehp_ctrl.c         |    4 ++--
 drivers/pci/hotplug/rpadlpar_core.c       |    2 +-
 drivers/pci/hotplug/rpaphp_core.c         |    2 +-
 drivers/pci/hotplug/shpchp.h              |    2 +-
 drivers/pci/hotplug/shpchp_ctrl.c         |    4 ++--
 drivers/pcmcia/soc_common.h               |    2 +-
 drivers/pnp/interface.c                   |    2 +-
 37 files changed, 57 insertions(+), 57 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/3c527.c linux-2.6.15-rc5-mutex/drivers/net/3c527.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/3c527.c	2005-06-22 13:51:53.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/net/3c527.c	2005-12-12 22:08:48.000000000 +0000
@@ -104,7 +104,7 @@ DRV_NAME ".c:v" DRV_VERSION " " DRV_RELD
 #include <linux/completion.h>
 #include <linux/bitops.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 #include <asm/system.h>
 #include <asm/io.h>
@@ -182,7 +182,7 @@ struct mc32_local 
 
 	u16 rx_ring_tail;       /* index to rx de-queue end */ 
 
-	struct semaphore cmd_mutex;    /* Serialises issuing of execute commands */
+	struct mutex cmd_mutex; /* Serialises issuing of execute commands */
         struct completion execution_cmd; /* Card has completed an execute command */
 	struct completion xceiver_cmd;   /* Card has completed a tx or rx command */
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/cassini.h linux-2.6.15-rc5-mutex/drivers/net/cassini.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/cassini.h	2005-11-01 13:19:09.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/cassini.h	2005-12-12 21:16:15.000000000 +0000
@@ -4284,7 +4284,7 @@ struct cas {
 	 * (ie. not power managed) */
 	int hw_running;
 	int opened;
-	struct semaphore pm_sem; /* open/close/suspend/resume */
+	struct mutex pm_sem; /* open/close/suspend/resume */
 
 	struct cas_init_block *init_block;
 	struct cas_tx_desc *init_txds[MAX_TX_RINGS];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/chelsio/common.h linux-2.6.15-rc5-mutex/drivers/net/chelsio/common.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/chelsio/common.h	2005-11-01 13:19:09.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/chelsio/common.h	2005-12-12 21:18:32.000000000 +0000
@@ -213,7 +213,7 @@ struct adapter {
 	struct work_struct stats_update_task;
 	struct timer_list stats_update_timer;
 
-	struct semaphore mib_mutex;
+	struct mutex mib_mutex;
 	spinlock_t tpi_lock;
 	spinlock_t work_lock;
 	/* guards async operations */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/hamradio/6pack.c linux-2.6.15-rc5-mutex/drivers/net/hamradio/6pack.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/hamradio/6pack.c	2005-11-01 13:19:10.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/hamradio/6pack.c	2005-12-12 22:08:48.000000000 +0000
@@ -34,7 +34,7 @@
 #include <linux/init.h>
 #include <linux/ip.h>
 #include <linux/tcp.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/atomic.h>
 
 #define SIXPACK_VERSION    "Revision: 0.3.0"
@@ -124,7 +124,7 @@ struct sixpack {
 	struct timer_list	tx_t;
 	struct timer_list	resync_t;
 	atomic_t		refcnt;
-	struct semaphore	dead_sem;
+	struct mutex		dead_sem;
 	spinlock_t		lock;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/hamradio/mkiss.c linux-2.6.15-rc5-mutex/drivers/net/hamradio/mkiss.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/hamradio/mkiss.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/hamradio/mkiss.c	2005-12-12 21:16:51.000000000 +0000
@@ -85,7 +85,7 @@ struct mkiss {
 #define CRC_MODE_SMACK_TEST	4
 
 	atomic_t		refcnt;
-	struct semaphore	dead_sem;
+	struct mutex		dead_sem;
 };
 
 /*---------------------------------------------------------------------------*/
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/ibmveth.c linux-2.6.15-rc5-mutex/drivers/net/ibmveth.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/ibmveth.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/ibmveth.c	2005-12-12 22:08:48.000000000 +0000
@@ -48,7 +48,7 @@
 #include <linux/mm.h>
 #include <linux/ethtool.h>
 #include <linux/proc_fs.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/hvcall.h>
 #include <asm/atomic.h>
 #include <asm/iommu.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/irda/sir-dev.h linux-2.6.15-rc5-mutex/drivers/net/irda/sir-dev.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/irda/sir-dev.h	2004-06-18 13:41:36.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/net/irda/sir-dev.h	2005-12-12 21:15:51.000000000 +0000
@@ -30,7 +30,7 @@ struct irda_request {
 };
 
 struct sir_fsm {
-	struct semaphore	sem;
+	struct mutex		sem;
 	struct irda_request	rq;
 	unsigned		state, substate;
 	int			param;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/irda/vlsi_ir.h linux-2.6.15-rc5-mutex/drivers/net/irda/vlsi_ir.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/irda/vlsi_ir.h	2005-11-01 13:19:10.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/irda/vlsi_ir.h	2005-12-12 21:15:45.000000000 +0000
@@ -761,7 +761,7 @@ typedef struct vlsi_irda_dev {
 	struct timeval		last_rx;
 
 	spinlock_t		lock;
-	struct semaphore	sem;
+	struct mutex		sem;
 
 	u8			resume_ok;	
 	struct proc_dir_entry	*proc_entry;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/plip.c linux-2.6.15-rc5-mutex/drivers/net/plip.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/plip.c	2005-08-30 13:56:19.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/net/plip.c	2005-12-12 22:08:48.000000000 +0000
@@ -116,7 +116,7 @@ static const char version[] = "NET3 PLIP
 #include <asm/system.h>
 #include <asm/irq.h>
 #include <asm/byteorder.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* Maximum number of devices to support. */
 #define PLIP_MAX  8
@@ -229,7 +229,7 @@ struct net_local {
 	                              struct hh_cache *hh);
 	spinlock_t lock;
 	atomic_t kill_timer;
-	struct semaphore killed_timer_sem;
+	struct mutex killed_timer_sem;
 };
 
 static inline void enable_parport_interrupts (struct net_device *dev)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/ppp_async.c linux-2.6.15-rc5-mutex/drivers/net/ppp_async.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/ppp_async.c	2005-12-08 16:23:43.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/ppp_async.c	2005-12-12 21:18:00.000000000 +0000
@@ -66,7 +66,7 @@ struct asyncppp {
 	struct tasklet_struct tsk;
 
 	atomic_t	refcnt;
-	struct semaphore dead_sem;
+	struct mutex	dead_sem;
 	struct ppp_channel chan;	/* interface to generic ppp layer */
 	unsigned char	obuf[OBUFSIZE];
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/ppp_synctty.c linux-2.6.15-rc5-mutex/drivers/net/ppp_synctty.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/ppp_synctty.c	2005-08-30 13:56:19.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/net/ppp_synctty.c	2005-12-12 22:08:48.000000000 +0000
@@ -44,7 +44,7 @@
 #include <linux/spinlock.h>
 #include <linux/init.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define PPP_VERSION	"2.4.2"
 
@@ -70,7 +70,7 @@ struct syncppp {
 	struct tasklet_struct tsk;
 
 	atomic_t	refcnt;
-	struct semaphore dead_sem;
+	struct mutex	dead_sem;
 	struct ppp_channel chan;	/* interface to generic ppp layer */
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/sungem.h linux-2.6.15-rc5-mutex/drivers/net/sungem.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/sungem.h	2005-11-01 13:19:10.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/sungem.h	2005-12-12 21:16:30.000000000 +0000
@@ -988,7 +988,7 @@ struct gem {
 	/* cell enable count, protected by lock */
 	int			cell_enabled;  
 	
-	struct semaphore	pm_sem;
+	struct mutex		pm_sem;
 
 	u32			msg_enable;
 	u32			status;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wan/cosa.c linux-2.6.15-rc5-mutex/drivers/net/wan/cosa.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wan/cosa.c	2005-12-08 16:23:43.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wan/cosa.c	2005-12-12 21:17:43.000000000 +0000
@@ -131,7 +131,7 @@ struct channel_data {
 	int (*tx_done)(struct channel_data *channel, int size);
 
 	/* Character device parts */
-	struct semaphore rsem, wsem;
+	struct mutex rsem, wsem;
 	char *rxdata;
 	int rxsize;
 	wait_queue_head_t txwaitq, rxwaitq;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/airo.c linux-2.6.15-rc5-mutex/drivers/net/wireless/airo.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/airo.c	2005-12-08 16:23:43.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/airo.c	2005-12-12 20:11:38.000000000 +0000
@@ -1176,7 +1176,7 @@ struct airo_info {
 	unsigned short *flash;
 	tdsRssiEntry *rssi;
 	struct task_struct *task;
-	struct semaphore sem;
+	struct mutex sem;
 	pid_t thr_pid;
 	wait_queue_head_t thr_wait;
 	struct completion thr_exited;
@@ -2718,7 +2718,7 @@ static struct net_device *_init_airo_car
 	}
         ai->dev = dev;
 	spin_lock_init(&ai->aux_lock);
-	sema_init(&ai->sem, 1);
+	init_MUTEX(&ai->sem);
 	ai->config.len = 0;
 	ai->pci = pci;
 	init_waitqueue_head (&ai->thr_wait);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/hostap/hostap_wlan.h linux-2.6.15-rc5-mutex/drivers/net/wireless/hostap/hostap_wlan.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/hostap/hostap_wlan.h	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/hostap/hostap_wlan.h	2005-12-12 21:17:35.000000000 +0000
@@ -637,7 +637,7 @@ struct local_info {
 			      * when removing entries from the list.
 			      * TX and RX paths can use read lock. */
 	spinlock_t cmdlock, baplock, lock;
-	struct semaphore rid_bap_sem;
+	struct mutex rid_bap_sem;
 	u16 infofid; /* MAC buffer id for info frame */
 	/* txfid, intransmitfid, next_txtid, and next_alloc are protected by
 	 * txfidlock */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/ipw2100.c linux-2.6.15-rc5-mutex/drivers/net/wireless/ipw2100.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/ipw2100.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/ipw2100.c	2005-12-12 20:12:25.000000000 +0000
@@ -6413,8 +6413,8 @@ static struct net_device *ipw2100_alloc_
 	strcpy(priv->nick, "ipw2100");
 
 	spin_lock_init(&priv->low_lock);
-	sema_init(&priv->action_sem, 1);
-	sema_init(&priv->adapter_sem, 1);
+	init_MUTEX(&priv->action_sem);
+	init_MUTEX(&priv->adapter_sem);
 
 	init_waitqueue_head(&priv->wait_command_queue);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/ipw2100.h linux-2.6.15-rc5-mutex/drivers/net/wireless/ipw2100.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/ipw2100.h	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/ipw2100.h	2005-12-12 20:12:15.000000000 +0000
@@ -588,8 +588,8 @@ struct ipw2100_priv {
 	int inta_other;
 
 	spinlock_t low_lock;
-	struct semaphore action_sem;
-	struct semaphore adapter_sem;
+	struct mutex action_sem;
+	struct mutex adapter_sem;
 
 	wait_queue_head_t wait_command_queue;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/ipw2200.h linux-2.6.15-rc5-mutex/drivers/net/wireless/ipw2200.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/ipw2200.h	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/ipw2200.h	2005-12-12 21:17:20.000000000 +0000
@@ -1120,7 +1120,7 @@ struct ipw_priv {
 	struct ieee80211_device *ieee;
 
 	spinlock_t lock;
-	struct semaphore sem;
+	struct mutex sem;
 
 	/* basic pci-network driver stuff */
 	struct pci_dev *pci_dev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.15-rc5-mutex/drivers/net/wireless/prism54/isl_ioctl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/prism54/isl_ioctl.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/prism54/isl_ioctl.c	2005-12-12 20:24:32.000000000 +0000
@@ -1255,7 +1255,7 @@ prism54_set_raw(struct net_device *ndev,
 void
 prism54_acl_init(struct islpci_acl *acl)
 {
-	sema_init(&acl->sem, 1);
+	init_MUTEX(&acl->sem);
 	INIT_LIST_HEAD(&acl->mac_list);
 	acl->size = 0;
 	acl->policy = MAC_POLICY_OPEN;
@@ -1686,7 +1686,7 @@ void
 prism54_wpa_ie_init(islpci_private *priv)
 {
 	INIT_LIST_HEAD(&priv->bss_wpa_list);
-	sema_init(&priv->wpa_sem, 1);
+	init_MUTEX(&priv->wpa_sem);
 }
 
 void
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.15-rc5-mutex/drivers/net/wireless/prism54/islpci_dev.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/prism54/islpci_dev.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/prism54/islpci_dev.c	2005-12-12 20:13:30.000000000 +0000
@@ -850,10 +850,10 @@ islpci_setup(struct pci_dev *pdev)
 	init_waitqueue_head(&priv->reset_done);
 
 	/* init the queue read locks, process wait counter */
-	sema_init(&priv->mgmt_sem, 1);
+	init_MUTEX(&priv->mgmt_sem);
 	priv->mgmt_received = NULL;
 	init_waitqueue_head(&priv->mgmt_wqueue);
-	sema_init(&priv->stats_sem, 1);
+	init_MUTEX(&priv->stats_sem);
 	spin_lock_init(&priv->slock);
 
 	/* init state machine with off#1 state */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/prism54/islpci_dev.h linux-2.6.15-rc5-mutex/drivers/net/wireless/prism54/islpci_dev.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/net/wireless/prism54/islpci_dev.h	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/net/wireless/prism54/islpci_dev.h	2005-12-12 20:13:24.000000000 +0000
@@ -55,7 +55,7 @@ struct islpci_acl {
    enum { MAC_POLICY_OPEN=0, MAC_POLICY_ACCEPT=1, MAC_POLICY_REJECT=2 } policy;
    struct list_head mac_list;  /* a list of mac_entry */
    int size;   /* size of queue */
-   struct semaphore sem;   /* accessed in ioctls and trap_work */
+   struct mutex sem;   /* accessed in ioctls and trap_work */
 };
 
 struct islpci_membuf {
@@ -88,7 +88,7 @@ typedef struct {
 	
 	/* Take care of the wireless stats */
 	struct work_struct stats_work;
-	struct semaphore stats_sem;
+	struct mutex stats_sem;
 	/* remember when we last updated the stats */
 	unsigned long stats_timestamp;
 	/* The first is accessed under semaphore locking.
@@ -165,7 +165,7 @@ typedef struct {
 	wait_queue_head_t reset_done;
 
 	/* used by islpci_mgt_transaction */
-	struct semaphore mgmt_sem; /* serialize access to mailbox and wqueue */
+	struct mutex mgmt_sem; /* serialize access to mailbox and wqueue */
 	struct islpci_mgmtframe *mgmt_received;	  /* mbox for incoming frame */
 	wait_queue_head_t mgmt_wqueue;            /* waitqueue for mbox */
 
@@ -178,7 +178,7 @@ typedef struct {
 	int wpa; /* WPA mode enabled */
 	struct list_head bss_wpa_list;
 	int num_bss_wpa;
-	struct semaphore wpa_sem;
+	struct mutex wpa_sem;
 
 	struct work_struct reset_task;
 	int reset_task_pending;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/oprofile/event_buffer.h linux-2.6.15-rc5-mutex/drivers/oprofile/event_buffer.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/oprofile/event_buffer.h	2005-08-30 13:56:21.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/oprofile/event_buffer.h	2005-12-12 22:08:48.000000000 +0000
@@ -11,7 +11,7 @@
 #define EVENT_BUFFER_H
 
 #include <linux/types.h> 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
  
 int alloc_event_buffer(void);
 
@@ -46,6 +46,6 @@ extern struct file_operations event_buff
 /* mutex between sync_cpu_buffers() and the
  * file reading code.
  */
-extern struct semaphore buffer_sem;
+extern struct mutex buffer_sem;
  
 #endif /* EVENT_BUFFER_H */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/oprofile/oprof.c linux-2.6.15-rc5-mutex/drivers/oprofile/oprof.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/oprofile/oprof.c	2005-03-02 12:08:20.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/oprofile/oprof.c	2005-12-12 22:08:48.000000000 +0000
@@ -12,7 +12,7 @@
 #include <linux/init.h>
 #include <linux/oprofile.h>
 #include <linux/moduleparam.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "oprof.h"
 #include "event_buffer.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/acpiphp_glue.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/acpiphp_glue.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/acpiphp_glue.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/acpiphp_glue.c	2005-12-12 22:08:48.000000000 +0000
@@ -46,7 +46,7 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/smp_lock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "../pci.h"
 #include "pci_hotplug.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/acpiphp.h linux-2.6.15-rc5-mutex/drivers/pci/hotplug/acpiphp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/acpiphp.h	2005-08-30 13:56:21.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/acpiphp.h	2005-12-12 21:42:44.000000000 +0000
@@ -118,7 +118,7 @@ struct acpiphp_slot {
 	struct acpiphp_bridge *bridge;	/* parent */
 	struct list_head funcs;		/* one slot may have different
 					   objects (i.e. for each function) */
-	struct semaphore crit_sect;
+	struct mutex	crit_sect;
 
 	u32		id;		/* slot id (serial #) for hotplug core */
 	u8		device;		/* pci device# */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/cpci_hotplug_core.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/cpci_hotplug_core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/cpci_hotplug_core.c	2005-06-22 13:51:55.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/cpci_hotplug_core.c	2005-12-12 21:42:53.000000000 +0000
@@ -60,8 +60,8 @@ static int slots;
 static atomic_t extracting;
 int cpci_debug;
 static struct cpci_hp_controller *controller;
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore thread_exit;		/* guard ensure thread has exited before calling it quits */
+static struct mutex event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct mutex thread_exit;	/* guard ensure thread has exited before calling it quits */
 static int thread_finished = 1;
 
 static int enable_slot(struct hotplug_slot *slot);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/cpqphp_ctrl.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/cpqphp_ctrl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/cpqphp_ctrl.c	2005-01-04 11:13:24.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/cpqphp_ctrl.c	2005-12-12 21:43:08.000000000 +0000
@@ -45,13 +45,13 @@ static int configure_new_function(struct
 			u8 behind_bridge, struct resource_lists *resources);
 static void interrupt_event_handler(struct controller *ctrl);
 
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
+static struct mutex event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct mutex event_exit;		/* guard ensure thread has exited before calling it quits */
 static int event_finished;
 static unsigned long pushbutton_pending;	/* = 0 */
 
 /* things needed for the long_delay function */
-static struct semaphore		delay_sem;
+static struct mutex		delay_sem;
 static wait_queue_head_t	delay_wait;
 
 /* delay is in jiffies to wait for */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/cpqphp.h linux-2.6.15-rc5-mutex/drivers/pci/hotplug/cpqphp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/cpqphp.h	2005-01-04 11:13:24.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/cpqphp.h	2005-12-12 21:43:24.000000000 +0000
@@ -286,7 +286,7 @@ struct event_info {
 struct controller {
 	struct controller *next;
 	u32 ctrl_int_comp;
-	struct semaphore crit_sect;	/* critical section semaphore */
+	struct mutex crit_sect;		/* critical section semaphore */
 	void __iomem *hpc_reg;		/* cookie for our pci controller location */
 	struct pci_resource *mem_head;
 	struct pci_resource *p_mem_head;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/ibmphp_hpc.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/ibmphp_hpc.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/ibmphp_hpc.c	2005-06-22 13:51:55.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/ibmphp_hpc.c	2005-12-12 21:41:50.000000000 +0000
@@ -101,10 +101,10 @@ static int to_debug = FALSE;
 //----------------------------------------------------------------------------
 static int ibmphp_shutdown;
 static int tid_poll;
-static struct semaphore sem_hpcaccess;	// lock access to HPC
-static struct semaphore semOperations;	// lock all operations and
+static struct mutex sem_hpcaccess;	// lock access to HPC
+static struct mutex semOperations;	// lock all operations and
 					// access to data structures
-static struct semaphore sem_exit;	// make sure polling thread goes away
+static struct mutex sem_exit;		// make sure polling thread goes away
 //----------------------------------------------------------------------------
 // local function prototypes
 //----------------------------------------------------------------------------
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/pciehp_ctrl.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/pciehp_ctrl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/pciehp_ctrl.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/pciehp_ctrl.c	2005-12-12 21:41:30.000000000 +0000
@@ -37,8 +37,8 @@
 
 static void interrupt_event_handler(struct controller *ctrl);
 
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
+static struct mutex event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct mutex event_exit;		/* guard ensure thread has exited before calling it quits */
 static int event_finished;
 static unsigned long pushbutton_pending;	/* = 0 */
 static unsigned long surprise_rm_pending;	/* = 0 */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/pciehp.h linux-2.6.15-rc5-mutex/drivers/pci/hotplug/pciehp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/pciehp.h	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/pciehp.h	2005-12-12 21:41:59.000000000 +0000
@@ -95,7 +95,7 @@ struct php_ctlr_state_s {
 #define MAX_EVENTS		10
 struct controller {
 	struct controller *next;
-	struct semaphore crit_sect;	/* critical section semaphore */
+	struct mutex crit_sect;	/* critical section semaphore */
 	struct php_ctlr_state_s *hpc_ctlr_handle; /* HPC controller handle */
 	int num_slots;			/* Number of slots on ctlr */
 	int slot_num_inc;		/* 1 or -1 */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/rpadlpar_core.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/rpadlpar_core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/rpadlpar_core.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/rpadlpar_core.c	2005-12-12 22:08:48.000000000 +0000
@@ -19,7 +19,7 @@
 #include <linux/string.h>
 
 #include <asm/pci-bridge.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/rtas.h>
 #include <asm/vio.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/rpaphp_core.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/rpaphp_core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/rpaphp_core.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/rpaphp_core.c	2005-12-12 21:42:32.000000000 +0000
@@ -40,7 +40,7 @@
 #include "pci_hotplug.h"
 
 int debug;
-static struct semaphore rpaphp_sem;
+static struct mutex rpaphp_sem;
 LIST_HEAD(rpaphp_slot_head);
 int num_slots;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/shpchp_ctrl.c linux-2.6.15-rc5-mutex/drivers/pci/hotplug/shpchp_ctrl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/shpchp_ctrl.c	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/shpchp_ctrl.c	2005-12-12 21:42:10.000000000 +0000
@@ -37,8 +37,8 @@
 
 static void interrupt_event_handler(struct controller *ctrl);
 
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
+static struct mutex event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct mutex event_exit;		/* guard ensure thread has exited before calling it quits */
 static int event_finished;
 static unsigned long pushbutton_pending;	/* = 0 */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/shpchp.h linux-2.6.15-rc5-mutex/drivers/pci/hotplug/shpchp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pci/hotplug/shpchp.h	2005-12-08 16:23:44.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/pci/hotplug/shpchp.h	2005-12-12 21:42:20.000000000 +0000
@@ -79,7 +79,7 @@ struct event_info {
 
 struct controller {
 	struct controller *next;
-	struct semaphore crit_sect;	/* critical section semaphore */
+	struct mutex crit_sect;	/* critical section semaphore */
 	struct php_ctlr_state_s *hpc_ctlr_handle; /* HPC controller handle */
 	int num_slots;			/* Number of slots on ctlr */
 	int slot_num_inc;		/* 1 or -1 */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pcmcia/soc_common.h linux-2.6.15-rc5-mutex/drivers/pcmcia/soc_common.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pcmcia/soc_common.h	2005-08-30 13:56:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/pcmcia/soc_common.h	2005-12-12 21:30:49.000000000 +0000
@@ -133,7 +133,7 @@ extern void soc_common_pcmcia_get_timing
 
 
 extern struct list_head soc_pcmcia_sockets;
-extern struct semaphore soc_pcmcia_sockets_lock;
+extern struct mutex soc_pcmcia_sockets_lock;
 
 extern int soc_common_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops, int first, int nr);
 extern int soc_common_drv_pcmcia_remove(struct device *dev);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/pnp/interface.c linux-2.6.15-rc5-mutex/drivers/pnp/interface.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/pnp/interface.c	2005-08-30 13:56:22.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/pnp/interface.c	2005-12-12 21:41:07.000000000 +0000
@@ -305,7 +305,7 @@ static ssize_t pnp_show_current_resource
 	return ret;
 }
 
-extern struct semaphore pnp_res_mutex;
+extern struct mutex pnp_res_mutex;
 
 static ssize_t
 pnp_set_current_resources(struct device * dmdev, struct device_attribute *attr, const char * ubuf, size_t count)

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 13/19] MUTEX: Filesystem changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (9 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 9/19] MUTEX: Drivers L-M changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 14/19] MUTEX: First set of include changes David Howells
                   ` (21 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the filesystem files to use the new mutex
functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-fs-2615rc5.diff
 fs/9p/trans_fd.c           |    4 ++--
 fs/9p/trans_sock.c         |    8 ++++----
 fs/9p/transport.h          |    4 ++--
 fs/9p/v9fs.h               |    2 +-
 fs/affs/affs.h             |    6 +++---
 fs/autofs4/autofs_i.h      |    2 +-
 fs/block_dev.c             |    4 ++--
 fs/cifs/cifsglob.h         |    8 ++++----
 fs/cramfs/inode.c          |    2 +-
 fs/dquot.c                 |    2 +-
 fs/eventpoll.c             |    4 ++--
 fs/fuse/dev.c              |   10 +++++-----
 fs/fuse/fuse_i.h           |    2 +-
 fs/hfs/btree.h             |    2 +-
 fs/hfs/hfs_fs.h            |    4 ++--
 fs/hfsplus/hfsplus_fs.h    |    4 ++--
 fs/hpfs/hpfs_fn.h          |    6 +++---
 fs/inode.c                 |    4 ++--
 fs/inotify.c               |    4 ++--
 fs/isofs/compress.c        |    2 +-
 fs/jffs/inode-v23.c        |    2 +-
 fs/jffs/intrep.c           |    2 +-
 fs/jffs/jffs_fm.h          |    2 +-
 fs/jfs/jfs_dmap.h          |    2 +-
 fs/jfs/jfs_imap.h          |    4 ++--
 fs/jfs/jfs_incore.h        |    2 +-
 fs/jfs/jfs_logmgr.h        |    2 +-
 fs/libfs.c                 |    2 +-
 fs/lockd/svc.c             |    7 ++++---
 fs/locks.c                 |    2 +-
 fs/nfs/idmap.c             |    4 ++--
 fs/ntfs/inode.h            |    6 +++---
 fs/ntfs/ntfs.h             |    2 +-
 fs/partitions/devfs.c      |    4 ++--
 fs/reiserfs/journal.c      |    8 ++++----
 fs/reiserfs/xattr.c        |    2 +-
 fs/seq_file.c              |    2 +-
 fs/super.c                 |    8 ++++----
 fs/sysfs/file.c            |    4 ++--
 fs/xfs/linux-2.6/mutex.h   |    8 ++++----
 fs/xfs/linux-2.6/sema.h    |    2 +-
 fs/xfs/linux-2.6/xfs_buf.h |    4 ++--
 42 files changed, 83 insertions(+), 82 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/9p/trans_fd.c linux-2.6.15-rc5-mutex/fs/9p/trans_fd.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/9p/trans_fd.c	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/9p/trans_fd.c	2005-12-12 19:58:04.000000000 +0000
@@ -106,8 +106,8 @@ v9fs_fd_init(struct v9fs_session_info *v
 		return -ENOPROTOOPT;
 	}
 
-	sema_init(&trans->writelock, 1);
-	sema_init(&trans->readlock, 1);
+	init_MUTEX(&trans->writelock);
+	init_MUTEX(&trans->readlock);
 
 	ts = kmalloc(sizeof(struct v9fs_trans_fd), GFP_KERNEL);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/9p/transport.h linux-2.6.15-rc5-mutex/fs/9p/transport.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/9p/transport.h	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/9p/transport.h	2005-12-12 19:57:43.000000000 +0000
@@ -31,8 +31,8 @@ enum v9fs_transport_status {
 
 struct v9fs_transport {
 	enum v9fs_transport_status status;
-	struct semaphore writelock;
-	struct semaphore readlock;
+	struct mutex writelock;
+	struct mutex readlock;
 	void *priv;
 
 	int (*init) (struct v9fs_session_info *, const char *, char *);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/9p/trans_sock.c linux-2.6.15-rc5-mutex/fs/9p/trans_sock.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/9p/trans_sock.c	2005-12-08 16:23:48.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/9p/trans_sock.c	2005-12-12 19:58:29.000000000 +0000
@@ -154,8 +154,8 @@ v9fs_tcp_init(struct v9fs_session_info *
 	struct v9fs_trans_sock *ts = NULL;
 	struct v9fs_transport *trans = v9ses->transport;
 
-	sema_init(&trans->writelock, 1);
-	sema_init(&trans->readlock, 1);
+	init_MUTEX(&trans->writelock);
+	init_MUTEX(&trans->readlock);
 
 	ts = kmalloc(sizeof(struct v9fs_trans_sock), GFP_KERNEL);
 
@@ -225,8 +225,8 @@ v9fs_unix_init(struct v9fs_session_info 
 	trans->priv = ts;
 	ts->s = NULL;
 
-	sema_init(&trans->writelock, 1);
-	sema_init(&trans->readlock, 1);
+	init_MUTEX(&trans->writelock);
+	init_MUTEX(&trans->readlock);
 
 	sun_server.sun_family = PF_UNIX;
 	strcpy(sun_server.sun_path, dev_name);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/9p/v9fs.h linux-2.6.15-rc5-mutex/fs/9p/v9fs.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/9p/v9fs.h	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/9p/v9fs.h	2005-12-12 20:52:22.000000000 +0000
@@ -28,7 +28,7 @@
   */
 
 struct v9fs_idpool {
-	struct semaphore lock;
+	struct mutex lock;
 	struct idr pool;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/affs/affs.h linux-2.6.15-rc5-mutex/fs/affs/affs.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/affs/affs.h	2005-03-02 12:08:34.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/affs/affs.h	2005-12-12 20:49:44.000000000 +0000
@@ -50,8 +50,8 @@ struct affs_ext_key {
  */
 struct affs_inode_info {
 	u32	 i_opencnt;
-	struct semaphore i_link_lock;		/* Protects internal inode access. */
-	struct semaphore i_ext_lock;		/* Protects internal inode access. */
+	struct mutex i_link_lock;		/* Protects internal inode access. */
+	struct mutex i_ext_lock;		/* Protects internal inode access. */
 #define i_hash_lock i_ext_lock
 	u32	 i_blkcnt;			/* block count */
 	u32	 i_extcnt;			/* extended block count */
@@ -99,7 +99,7 @@ struct affs_sb_info {
 	gid_t s_gid;			/* gid to override */
 	umode_t s_mode;			/* mode to override */
 	struct buffer_head *s_root_bh;	/* Cached root block. */
-	struct semaphore s_bmlock;	/* Protects bitmap access. */
+	struct mutex s_bmlock;		/* Protects bitmap access. */
 	struct affs_bm_info *s_bitmap;	/* Bitmap infos. */
 	u32 s_bmap_count;		/* # of bitmap blocks. */
 	u32 s_bmap_bits;		/* # of bits in one bitmap blocks */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/autofs4/autofs_i.h linux-2.6.15-rc5-mutex/fs/autofs4/autofs_i.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/autofs4/autofs_i.h	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/autofs4/autofs_i.h	2005-12-12 17:33:33.000000000 +0000
@@ -102,7 +102,7 @@ struct autofs_sb_info {
 	int reghost_enabled;
 	int needs_reghost;
 	struct super_block *sb;
-	struct semaphore wq_sem;
+	struct mutex wq_sem;
 	spinlock_t fs_lock;
 	struct autofs_wait_queue *queues; /* Wait queue pointer */
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/block_dev.c linux-2.6.15-rc5-mutex/fs/block_dev.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/block_dev.c	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/block_dev.c	2005-12-12 17:32:31.000000000 +0000
@@ -265,8 +265,8 @@ static void init_once(void * foo, kmem_c
 	    SLAB_CTOR_CONSTRUCTOR)
 	{
 		memset(bdev, 0, sizeof(*bdev));
-		sema_init(&bdev->bd_sem, 1);
-		sema_init(&bdev->bd_mount_sem, 1);
+		init_MUTEX(&bdev->bd_sem);
+		init_MUTEX(&bdev->bd_mount_sem);
 		INIT_LIST_HEAD(&bdev->bd_inodes);
 		INIT_LIST_HEAD(&bdev->bd_list);
 		inode_init_once(&ei->vfs_inode);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/cifs/cifsglob.h linux-2.6.15-rc5-mutex/fs/cifs/cifsglob.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/cifs/cifsglob.h	2005-12-08 16:23:48.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/cifs/cifsglob.h	2005-12-12 20:48:45.000000000 +0000
@@ -135,7 +135,7 @@ struct TCP_Server_Info {
 	atomic_t num_waiters;   /* blocked waiting to get in sendrecv */
 #endif
 	enum statusEnum tcpStatus; /* what we think the status is */
-	struct semaphore tcpSem;
+	struct mutex tcpSem;
 	struct task_struct *tsk;
 	char server_GUID[16];
 	char secMode;
@@ -178,7 +178,7 @@ struct cifsUidInfo {
  */
 struct cifsSesInfo {
 	struct list_head cifsSessionList;
-	struct semaphore sesSem;
+	struct mutex sesSem;
 	struct cifsUidInfo *uidInfo;	/* pointer to user info */
 	struct TCP_Server_Info *server;	/* pointer to server info */
 	atomic_t inUse; /* # of mounts (tree connections) on this ses */
@@ -207,7 +207,7 @@ struct cifsSesInfo {
 struct cifsTconInfo {
 	struct list_head cifsConnectionList;
 	struct list_head openFileList;
-	struct semaphore tconSem;
+	struct mutex tconSem;
 	struct cifsSesInfo *ses;	/* pointer to session associated with */
 	char treeName[MAX_TREE_SIZE + 1]; /* UNC name of resource (in ASCII not UTF) */
 	char *nativeFileSystem;
@@ -300,7 +300,7 @@ struct cifsFileInfo {
 	unsigned closePend:1;	/* file is marked to close */
 	unsigned invalidHandle:1;  /* file closed via session abend */
 	atomic_t wrtPending;   /* handle in use - defer close */
-	struct semaphore fh_sem; /* prevents reopen race after dead ses*/
+	struct mutex fh_sem; /* prevents reopen race after dead ses*/
 	char * search_resume_name; /* BB removeme BB */
 	unsigned int resume_name_length; /* BB removeme - field renamed and moved BB */
 	struct cifs_search_info srch_inf;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/cramfs/inode.c linux-2.6.15-rc5-mutex/fs/cramfs/inode.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/cramfs/inode.c	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/cramfs/inode.c	2005-12-12 22:12:50.000000000 +0000
@@ -22,7 +22,7 @@
 #include <linux/cramfs_fs_sb.h>
 #include <linux/buffer_head.h>
 #include <linux/vfs.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <asm/uaccess.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/dquot.c linux-2.6.15-rc5-mutex/fs/dquot.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/dquot.c	2005-12-08 16:23:48.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/dquot.c	2005-12-12 19:57:04.000000000 +0000
@@ -575,7 +575,7 @@ static struct dquot *get_empty_dquot(str
 		return NODQUOT;
 
 	memset((caddr_t)dquot, 0, sizeof(struct dquot));
-	sema_init(&dquot->dq_lock, 1);
+	init_MUTEX(&dquot->dq_lock);
 	INIT_LIST_HEAD(&dquot->dq_free);
 	INIT_LIST_HEAD(&dquot->dq_inuse);
 	INIT_HLIST_NODE(&dquot->dq_hash);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/eventpoll.c linux-2.6.15-rc5-mutex/fs/eventpoll.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/eventpoll.c	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/eventpoll.c	2005-12-12 22:12:50.000000000 +0000
@@ -39,7 +39,7 @@
 #include <asm/io.h>
 #include <asm/mman.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 
 /*
@@ -274,7 +274,7 @@ static struct super_block *eventpollfs_g
 /*
  * This semaphore is used to serialize ep_free() and eventpoll_release_file().
  */
-static struct semaphore epsem;
+static struct mutex epsem;
 
 /* Safe wake up implementation */
 static struct poll_safewake psw;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/fuse/dev.c linux-2.6.15-rc5-mutex/fs/fuse/dev.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/fuse/dev.c	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/fuse/dev.c	2005-12-12 20:31:16.000000000 +0000
@@ -110,7 +110,7 @@ struct fuse_req *fuse_get_request(struct
 	sigset_t oldset;
 
 	block_sigs(&oldset);
-	intr = down_interruptible(&fc->outstanding_sem);
+	intr = down_sem_interruptible(&fc->outstanding_sem);
 	restore_sigs(&oldset);
 	return intr ? NULL : do_get_request(fc);
 }
@@ -127,7 +127,7 @@ static void fuse_putback_request(struct 
 	if (fc->outstanding_debt)
 		fc->outstanding_debt--;
 	else
-		up(&fc->outstanding_sem);
+		up_sem(&fc->outstanding_sem);
 	spin_unlock(&fuse_lock);
 }
 
@@ -180,10 +180,10 @@ static void request_end(struct fuse_conn
 
 		/* After INIT reply is received other requests can go
 		   out.  So do (FUSE_MAX_OUTSTANDING - 1) number of
-		   up()s on outstanding_sem.  The last up() is done in
+		   up_sem()s on outstanding_sem.  The last up() is done in
 		   fuse_putback_request() */
 		for (i = 1; i < FUSE_MAX_OUTSTANDING; i++)
-			up(&fc->outstanding_sem);
+			up_sem(&fc->outstanding_sem);
 	} else if (req->in.h.opcode == FUSE_RELEASE && req->inode == NULL) {
 		/* Special case for failed iget in CREATE */
 		u64 nodeid = req->in.h.nodeid;
@@ -296,7 +296,7 @@ static void queue_request(struct fuse_co
 		   processing the RELEASE requests.  However for
 		   efficiency do it without blocking, so if down()
 		   would block, just increase the debt instead */
-		if (down_trylock(&fc->outstanding_sem))
+		if (down_sem_trylock(&fc->outstanding_sem))
 			fc->outstanding_debt++;
 	}
 	list_add_tail(&req->list, &fc->pending);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/fuse/fuse_i.h linux-2.6.15-rc5-mutex/fs/fuse/fuse_i.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/fuse/fuse_i.h	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/fuse/fuse_i.h	2005-12-12 22:05:43.000000000 +0000
@@ -13,7 +13,7 @@
 #include <linux/spinlock.h>
 #include <linux/mm.h>
 #include <linux/backing-dev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /** Max number of pages that can be used in a single read request */
 #define FUSE_MAX_PAGES_PER_REQ 32
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/hfs/btree.h linux-2.6.15-rc5-mutex/fs/hfs/btree.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/hfs/btree.h	2005-06-22 13:52:11.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/hfs/btree.h	2005-12-12 20:54:32.000000000 +0000
@@ -33,7 +33,7 @@ struct hfs_btree {
 	unsigned int depth;
 
 	//unsigned int map1_size, map_size;
-	struct semaphore tree_lock;
+	struct mutex tree_lock;
 
 	unsigned int pages_per_bnode;
 	spinlock_t hash_lock;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/hfs/hfs_fs.h linux-2.6.15-rc5-mutex/fs/hfs/hfs_fs.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/hfs/hfs_fs.h	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/hfs/hfs_fs.h	2005-12-12 20:54:29.000000000 +0000
@@ -56,7 +56,7 @@ struct hfs_inode_info {
 	struct list_head open_dir_list;
 	struct inode *rsrc_inode;
 
-	struct semaphore extents_lock;
+	struct mutex extents_lock;
 
 	u16 alloc_blocks, clump_blocks;
 	sector_t fs_blocks;
@@ -142,7 +142,7 @@ struct hfs_sb_info {
 
 	struct nls_table *nls_io, *nls_disk;
 
-	struct semaphore bitmap_lock;
+	struct mutex bitmap_lock;
 
 	unsigned long flags;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/hfsplus/hfsplus_fs.h linux-2.6.15-rc5-mutex/fs/hfsplus/hfsplus_fs.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/hfsplus/hfsplus_fs.h	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/hfsplus/hfsplus_fs.h	2005-12-12 20:51:21.000000000 +0000
@@ -61,7 +61,7 @@ struct hfs_btree {
 	unsigned int depth;
 
 	//unsigned int map1_size, map_size;
-	struct semaphore tree_lock;
+	struct mutex tree_lock;
 
 	unsigned int pages_per_bnode;
 	spinlock_t hash_lock;
@@ -155,7 +155,7 @@ struct hfsplus_sb_info {
 
 
 struct hfsplus_inode_info {
-	struct semaphore extents_lock;
+	struct mutex extents_lock;
 	u32 clump_blocks, alloc_blocks;
 	sector_t fs_blocks;
 	/* Allocation extents from catalog record or volume header */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/hpfs/hpfs_fn.h linux-2.6.15-rc5-mutex/fs/hpfs/hpfs_fn.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/hpfs/hpfs_fn.h	2005-06-22 13:52:12.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/hpfs/hpfs_fn.h	2005-12-12 20:54:14.000000000 +0000
@@ -57,8 +57,8 @@ struct hpfs_inode_info {
 	unsigned i_ea_uid : 1;	/* file's uid is stored in ea */
 	unsigned i_ea_gid : 1;	/* file's gid is stored in ea */
 	unsigned i_dirty : 1;
-	struct semaphore i_sem;
-	struct semaphore i_parent;
+	struct mutex i_sem;
+	struct mutex i_parent;
 	loff_t **i_rddir_off;
 	struct inode vfs_inode;
 };
@@ -88,7 +88,7 @@ struct hpfs_sb_info {
 	unsigned *sb_bmp_dir;		/* main bitmap directory */
 	unsigned sb_c_bitmap;		/* current bitmap */
 	unsigned sb_max_fwd_alloc;	/* max forwad allocation */
-	struct semaphore hpfs_creation_de; /* when creating dirents, nobody else
+	struct mutex hpfs_creation_de;	/* when creating dirents, nobody else
 					   can alloc blocks */
 	/*unsigned sb_mounting : 1;*/
 	int sb_timeshift;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/inode.c linux-2.6.15-rc5-mutex/fs/inode.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/inode.c	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/inode.c	2005-12-12 17:30:32.000000000 +0000
@@ -192,7 +192,7 @@ void inode_init_once(struct inode *inode
 	INIT_HLIST_NODE(&inode->i_hash);
 	INIT_LIST_HEAD(&inode->i_dentry);
 	INIT_LIST_HEAD(&inode->i_devices);
-	sema_init(&inode->i_sem, 1);
+	init_MUTEX(&inode->i_sem);
 	init_rwsem(&inode->i_alloc_sem);
 	INIT_RADIX_TREE(&inode->i_data.page_tree, GFP_ATOMIC);
 	rwlock_init(&inode->i_data.tree_lock);
@@ -205,7 +205,7 @@ void inode_init_once(struct inode *inode
 	i_size_ordered_init(inode);
 #ifdef CONFIG_INOTIFY
 	INIT_LIST_HEAD(&inode->inotify_watches);
-	sema_init(&inode->inotify_sem, 1);
+	init_MUTEX(&inode->inotify_sem);
 #endif
 }
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/inotify.c linux-2.6.15-rc5-mutex/fs/inotify.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/inotify.c	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/inotify.c	2005-12-12 18:07:19.000000000 +0000
@@ -83,7 +83,7 @@ int inotify_max_queued_events;
 struct inotify_device {
 	wait_queue_head_t 	wq;		/* wait queue for i/o */
 	struct idr		idr;		/* idr mapping wd -> watch */
-	struct semaphore	sem;		/* protects this bad boy */
+	struct mutex		sem;		/* protects this bad boy */
 	struct list_head 	events;		/* list of queued events */
 	struct list_head	watches;	/* list of watches */
 	atomic_t		count;		/* reference count */
@@ -903,7 +903,7 @@ asmlinkage long sys_inotify_init(void)
 	INIT_LIST_HEAD(&dev->events);
 	INIT_LIST_HEAD(&dev->watches);
 	init_waitqueue_head(&dev->wq);
-	sema_init(&dev->sem, 1);
+	init_MUTEX(&dev->sem);
 	dev->event_count = 0;
 	dev->queue_size = 0;
 	dev->max_events = inotify_max_queued_events;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/isofs/compress.c linux-2.6.15-rc5-mutex/fs/isofs/compress.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/isofs/compress.c	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/isofs/compress.c	2005-12-12 20:47:06.000000000 +0000
@@ -34,7 +34,7 @@ static char zisofs_sink_page[PAGE_CACHE_
  * allocation; this avoids failures at block-decompression time.
  */
 static void *zisofs_zlib_workspace;
-static struct semaphore zisofs_zlib_semaphore;
+static struct mutex zisofs_zlib_semaphore;
 
 /*
  * When decompressing, we typically obtain more than one page
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jffs/inode-v23.c linux-2.6.15-rc5-mutex/fs/jffs/inode-v23.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/jffs/inode-v23.c	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/jffs/inode-v23.c	2005-12-12 22:12:50.000000000 +0000
@@ -42,7 +42,7 @@
 #include <linux/quotaops.h>
 #include <linux/highmem.h>
 #include <linux/vfs.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/byteorder.h>
 #include <asm/uaccess.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jffs/intrep.c linux-2.6.15-rc5-mutex/fs/jffs/intrep.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/jffs/intrep.c	2005-12-08 16:23:49.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/jffs/intrep.c	2005-12-12 22:12:50.000000000 +0000
@@ -62,7 +62,7 @@
 #include <linux/fs.h>
 #include <linux/stat.h>
 #include <linux/pagemap.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/byteorder.h>
 #include <linux/smp_lock.h>
 #include <linux/time.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jffs/jffs_fm.h linux-2.6.15-rc5-mutex/fs/jffs/jffs_fm.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/jffs/jffs_fm.h	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/jffs/jffs_fm.h	2005-12-12 20:52:06.000000000 +0000
@@ -97,7 +97,7 @@ struct jffs_fmcontrol
 	struct jffs_fm *tail;
 	struct jffs_fm *head_extra;
 	struct jffs_fm *tail_extra;
-	struct semaphore biglock;
+	struct mutex biglock;
 };
 
 /* Notice the two members head_extra and tail_extra in the jffs_control
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_dmap.h linux-2.6.15-rc5-mutex/fs/jfs/jfs_dmap.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_dmap.h	2005-01-04 11:13:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/jfs/jfs_dmap.h	2005-12-12 20:50:42.000000000 +0000
@@ -243,7 +243,7 @@ struct dbmap {
 struct bmap {
 	struct dbmap db_bmap;		/* on-disk aggregate map descriptor */
 	struct inode *db_ipbmap;	/* ptr to aggregate map incore inode */
-	struct semaphore db_bmaplock;	/* aggregate map lock */
+	struct mutex db_bmaplock;	/* aggregate map lock */
 	atomic_t db_active[MAXAG];	/* count of active, open files in AG */
 	u32 *db_DBmap;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_imap.h linux-2.6.15-rc5-mutex/fs/jfs/jfs_imap.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_imap.h	2005-01-04 11:13:39.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/jfs/jfs_imap.h	2005-12-12 20:51:02.000000000 +0000
@@ -140,8 +140,8 @@ struct dinomap {
 struct inomap {
 	struct dinomap im_imap;		/* 4096: inode allocation control */
 	struct inode *im_ipimap;	/* 4: ptr to inode for imap   */
-	struct semaphore im_freelock;	/* 4: iag free list lock      */
-	struct semaphore im_aglock[MAXAG];	/* 512: per AG locks          */
+	struct mutex im_freelock;	/* 4: iag free list lock      */
+	struct mutex im_aglock[MAXAG];	/* 512: per AG locks          */
 	u32 *im_DBGdimap;
 	atomic_t im_numinos;	/* num of backed inodes */
 	atomic_t im_numfree;	/* num of free backed inodes */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_incore.h linux-2.6.15-rc5-mutex/fs/jfs/jfs_incore.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_incore.h	2005-06-22 13:52:14.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/jfs/jfs_incore.h	2005-12-12 20:50:47.000000000 +0000
@@ -67,7 +67,7 @@ struct jfs_inode_info {
 	 * dirty inodes may be committed while a new transaction on the
 	 * inode is blocked in txBegin or TxBeginAnon
 	 */
-	struct semaphore commit_sem;
+	struct mutex commit_sem;
 	/* xattr_sem allows us to access the xattrs without taking i_sem */
 	struct rw_semaphore xattr_sem;
 	lid_t	xtlid;		/* lid of xtree lock on directory */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_logmgr.h linux-2.6.15-rc5-mutex/fs/jfs/jfs_logmgr.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/jfs/jfs_logmgr.h	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/jfs/jfs_logmgr.h	2005-12-12 20:50:52.000000000 +0000
@@ -389,7 +389,7 @@ struct jfs_log {
 	int eor;		/* 4: eor of last record in eol page */
 	struct lbuf *bp;	/* 4: current log page buffer */
 
-	struct semaphore loglock;	/* 4: log write serialization lock */
+	struct mutex loglock;	/* 4: log write serialization lock */
 
 	/* syncpt */
 	int nextsync;		/* 4: bytes to write before next syncpt */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/libfs.c linux-2.6.15-rc5-mutex/fs/libfs.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/libfs.c	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/libfs.c	2005-12-12 18:01:44.000000000 +0000
@@ -529,7 +529,7 @@ struct simple_attr {
 	char set_buf[24];
 	void *data;
 	const char *fmt;	/* format for read operation */
-	struct semaphore sem;	/* protects access to these buffers */
+	struct mutex sem;	/* protects access to these buffers */
 };
 
 /* simple_attr_open is called by an actual attribute open file operation
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/lockd/svc.c linux-2.6.15-rc5-mutex/fs/lockd/svc.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/lockd/svc.c	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/lockd/svc.c	2005-12-12 17:37:21.000000000 +0000
@@ -49,7 +49,7 @@ static pid_t			nlmsvc_pid;
 int				nlmsvc_grace_period;
 unsigned long			nlmsvc_timeout;
 
-static DECLARE_MUTEX_LOCKED(lockd_start);
+static DECLARE_COMPLETION(lockd_start);
 static DECLARE_WAIT_QUEUE_HEAD(lockd_exit);
 
 /*
@@ -112,7 +112,7 @@ lockd(struct svc_rqst *rqstp)
 	 * Let our maker know we're running.
 	 */
 	nlmsvc_pid = current->pid;
-	up(&lockd_start);
+	complete(&lockd_start);
 
 	daemonize("lockd");
 
@@ -257,13 +257,14 @@ lockd_up(void)
 	/*
 	 * Create the kernel thread and wait for it to start.
 	 */
+	init_completion(&lockd_start);
 	error = svc_create_thread(lockd, serv);
 	if (error) {
 		printk(KERN_WARNING
 			"lockd_up: create thread failed, error=%d\n", error);
 		goto destroy_and_out;
 	}
-	down(&lockd_start);
+	wait_for_completion(&lockd_start);
 
 	/*
 	 * Note: svc_serv structures have an initial use count of 1,
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/locks.c linux-2.6.15-rc5-mutex/fs/locks.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/locks.c	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/locks.c	2005-12-12 22:12:50.000000000 +0000
@@ -125,8 +125,8 @@
 #include <linux/syscalls.h>
 #include <linux/time.h>
 #include <linux/rcupdate.h>
+#include <linux/semaphore.h>
 
-#include <asm/semaphore.h>
 #include <asm/uaccess.h>
 
 #define IS_POSIX(fl)	(fl->fl_flags & FL_POSIX)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/nfs/idmap.c linux-2.6.15-rc5-mutex/fs/nfs/idmap.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/nfs/idmap.c	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/nfs/idmap.c	2005-12-12 20:52:50.000000000 +0000
@@ -70,8 +70,8 @@ struct idmap {
 	struct dentry        *idmap_dentry;
 	wait_queue_head_t     idmap_wq;
 	struct idmap_msg      idmap_im;
-	struct semaphore      idmap_lock;    /* Serializes upcalls */
-	struct semaphore      idmap_im_lock; /* Protects the hashtable */
+	struct mutex          idmap_lock;    /* Serializes upcalls */
+	struct mutex          idmap_im_lock; /* Protects the hashtable */
 	struct idmap_hashtable idmap_user_hash;
 	struct idmap_hashtable idmap_group_hash;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/ntfs/inode.h linux-2.6.15-rc5-mutex/fs/ntfs/inode.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/ntfs/inode.h	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/ntfs/inode.h	2005-12-12 22:12:50.000000000 +0000
@@ -28,8 +28,8 @@
 #include <linux/fs.h>
 #include <linux/seq_file.h>
 #include <linux/list.h>
+#include <linux/semaphore.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
 
 #include "layout.h"
 #include "volume.h"
@@ -81,7 +81,7 @@ struct _ntfs_inode {
 	 * The following fields are only valid for real inodes and extent
 	 * inodes.
 	 */
-	struct semaphore mrec_lock; /* Lock for serializing access to the
+	struct mutex mrec_lock; /* Lock for serializing access to the
 				   mft record belonging to this inode. */
 	struct page *page;	/* The page containing the mft record of the
 				   inode. This should only be touched by the
@@ -119,7 +119,7 @@ struct _ntfs_inode {
 			u8 block_clusters;	/* Number of clusters per cb. */
 		} compressed;
 	} itype;
-	struct semaphore extent_lock;	/* Lock for accessing/modifying the
+	struct mutex extent_lock;	/* Lock for accessing/modifying the
 					   below . */
 	s32 nr_extents;	/* For a base mft record, the number of attached extent
 			   inodes (0 if none), for extent records and for fake
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/ntfs/ntfs.h linux-2.6.15-rc5-mutex/fs/ntfs/ntfs.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/ntfs/ntfs.h	2005-08-30 13:56:28.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/ntfs/ntfs.h	2005-12-12 20:50:25.000000000 +0000
@@ -91,7 +91,7 @@ extern void free_compression_buffers(voi
 
 /* From fs/ntfs/super.c */
 #define default_upcase_len 0x10000
-extern struct semaphore ntfs_lock;
+extern struct mutex ntfs_lock;
 
 typedef struct {
 	int val;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/partitions/devfs.c linux-2.6.15-rc5-mutex/fs/partitions/devfs.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/partitions/devfs.c	2005-01-04 11:13:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/partitions/devfs.c	2005-12-12 22:12:50.000000000 +0000
@@ -6,14 +6,14 @@
 #include <linux/vmalloc.h>
 #include <linux/genhd.h>
 #include <linux/bitops.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 
 struct unique_numspace {
 	u32		  num_free;          /*  Num free in bits       */
 	u32		  length;            /*  Array length in bytes  */
 	unsigned long	  *bits;
-	struct semaphore  mutex;
+	struct mutex      mutex;
 };
 
 static DECLARE_MUTEX(numspace_mutex);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/reiserfs/journal.c linux-2.6.15-rc5-mutex/fs/reiserfs/journal.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/reiserfs/journal.c	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/reiserfs/journal.c	2005-12-12 22:12:50.000000000 +0000
@@ -39,7 +39,7 @@
 #include <asm/system.h>
 
 #include <linux/time.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/vmalloc.h>
 #include <linux/reiserfs_fs.h>
@@ -2473,7 +2473,7 @@ static struct reiserfs_journal_list *all
 	INIT_LIST_HEAD(&jl->j_working_list);
 	INIT_LIST_HEAD(&jl->j_tail_bh_list);
 	INIT_LIST_HEAD(&jl->j_bh_list);
-	sema_init(&jl->j_commit_lock, 1);
+	init_MUTEX(&jl->j_commit_lock);
 	SB_JOURNAL(s)->j_num_lists++;
 	get_journal_list(jl);
 	return jl;
@@ -2744,8 +2744,8 @@ int journal_init(struct super_block *p_s
 	journal->j_last = NULL;
 	journal->j_first = NULL;
 	init_waitqueue_head(&(journal->j_join_wait));
-	sema_init(&journal->j_lock, 1);
-	sema_init(&journal->j_flush_sem, 1);
+	init_MUTEX(&journal->j_lock);
+	init_MUTEX(&journal->j_flush_sem);
 
 	journal->j_trans_id = 10;
 	journal->j_mount_id = 10;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/reiserfs/xattr.c linux-2.6.15-rc5-mutex/fs/reiserfs/xattr.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/reiserfs/xattr.c	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/reiserfs/xattr.c	2005-12-12 22:12:50.000000000 +0000
@@ -43,7 +43,7 @@
 #include <asm/checksum.h>
 #include <linux/smp_lock.h>
 #include <linux/stat.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #define FL_READONLY 128
 #define FL_DIR_SEM_HELD 256
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/seq_file.c linux-2.6.15-rc5-mutex/fs/seq_file.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/seq_file.c	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/seq_file.c	2005-12-12 17:32:40.000000000 +0000
@@ -37,7 +37,7 @@ int seq_open(struct file *file, struct s
 		file->private_data = p;
 	}
 	memset(p, 0, sizeof(*p));
-	sema_init(&p->sem, 1);
+	init_MUTEX(&p->sem);
 	p->op = op;
 
 	/*
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/super.c linux-2.6.15-rc5-mutex/fs/super.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/super.c	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/super.c	2005-12-12 17:25:56.000000000 +0000
@@ -72,13 +72,13 @@ static struct super_block *alloc_super(v
 		INIT_HLIST_HEAD(&s->s_anon);
 		INIT_LIST_HEAD(&s->s_inodes);
 		init_rwsem(&s->s_umount);
-		sema_init(&s->s_lock, 1);
+		init_MUTEX(&s->s_lock);
 		down_write(&s->s_umount);
 		s->s_count = S_BIAS;
 		atomic_set(&s->s_active, 1);
-		sema_init(&s->s_vfs_rename_sem,1);
-		sema_init(&s->s_dquot.dqio_sem, 1);
-		sema_init(&s->s_dquot.dqonoff_sem, 1);
+		init_MUTEX(&s->s_vfs_rename_sem);
+		init_MUTEX(&s->s_dquot.dqio_sem);
+		init_MUTEX(&s->s_dquot.dqonoff_sem);
 		init_rwsem(&s->s_dquot.dqptr_sem);
 		init_waitqueue_head(&s->s_wait_unfrozen);
 		s->s_maxbytes = MAX_NON_LFS;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/sysfs/file.c linux-2.6.15-rc5-mutex/fs/sysfs/file.c
--- /warthog/kernels/linux-2.6.15-rc5/fs/sysfs/file.c	2005-08-30 13:56:29.000000000 +0100
+++ linux-2.6.15-rc5-mutex/fs/sysfs/file.c	2005-12-12 22:12:50.000000000 +0000
@@ -7,7 +7,7 @@
 #include <linux/kobject.h>
 #include <linux/namei.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "sysfs.h"
 
@@ -55,7 +55,7 @@ struct sysfs_buffer {
 	loff_t			pos;
 	char			* page;
 	struct sysfs_ops	* ops;
-	struct semaphore	sem;
+	struct mutex		sem;
 	int			needs_read_fill;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/xfs/linux-2.6/mutex.h linux-2.6.15-rc5-mutex/fs/xfs/linux-2.6/mutex.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/xfs/linux-2.6/mutex.h	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/xfs/linux-2.6/mutex.h	2005-12-12 22:12:50.000000000 +0000
@@ -19,7 +19,7 @@
 #define __XFS_SUPPORT_MUTEX_H__
 
 #include <linux/spinlock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /*
  * Map the mutex'es from IRIX to Linux semaphores.
@@ -28,10 +28,10 @@
  * callers.
  */
 #define MUTEX_DEFAULT		0x0
-typedef struct semaphore	mutex_t;
+typedef struct mutex		mutex_t;
 
-#define mutex_init(lock, type, name)		sema_init(lock, 1)
-#define mutex_destroy(lock)			sema_init(lock, -99)
+#define mutex_init(lock, type, name)		init_MUTEX(lock)
+#define mutex_destroy(lock)			do {} while(0)
 #define mutex_lock(lock, num)			down(lock)
 #define mutex_trylock(lock)			(down_trylock(lock) ? 0 : 1)
 #define mutex_unlock(lock)			up(lock)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/xfs/linux-2.6/sema.h linux-2.6.15-rc5-mutex/fs/xfs/linux-2.6/sema.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/xfs/linux-2.6/sema.h	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/xfs/linux-2.6/sema.h	2005-12-12 22:05:13.000000000 +0000
@@ -21,7 +21,7 @@
 #include <linux/time.h>
 #include <linux/wait.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /*
  * sema_t structure just maps to struct semaphore in Linux kernel.
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/fs/xfs/linux-2.6/xfs_buf.h linux-2.6.15-rc5-mutex/fs/xfs/linux-2.6/xfs_buf.h
--- /warthog/kernels/linux-2.6.15-rc5/fs/xfs/linux-2.6/xfs_buf.h	2005-12-08 16:23:50.000000000 +0000
+++ linux-2.6.15-rc5-mutex/fs/xfs/linux-2.6/xfs_buf.h	2005-12-12 20:47:50.000000000 +0000
@@ -114,7 +114,7 @@ typedef int (*page_buf_bdstrat_t)(struct
 #define PB_PAGES	2
 
 typedef struct xfs_buf {
-	struct semaphore	pb_sema;	/* semaphore for lockables  */
+	struct mutex		pb_sema;	/* semaphore for lockables  */
 	unsigned long		pb_queuetime;	/* time buffer was queued   */
 	atomic_t		pb_pin_count;	/* pin count		    */
 	wait_queue_head_t	pb_waiters;	/* unpin waiters	    */
@@ -134,7 +134,7 @@ typedef struct xfs_buf {
 	page_buf_iodone_t	pb_iodone;	/* I/O completion function */
 	page_buf_relse_t	pb_relse;	/* releasing function */
 	page_buf_bdstrat_t	pb_strat;	/* pre-write function */
-	struct semaphore	pb_iodonesema;	/* Semaphore for I/O waiters */
+	struct mutex		pb_iodonesema;	/* Semaphore for I/O waiters */
 	void			*pb_fspriv;
 	void			*pb_fspriv2;
 	void			*pb_fspriv3;

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 12/19] MUTEX: Drivers T-Z changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (11 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 14/19] MUTEX: First set of include changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 11/19] MUTEX: Drivers Q-S changes David Howells
                   ` (19 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/t* thru drivers/z* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-TtoZ-2615rc5.diff
 drivers/usb/atm/cxacru.c                |    2 +-
 drivers/usb/atm/usbatm.h                |    4 ++--
 drivers/usb/class/usb-midi.c            |    2 +-
 drivers/usb/class/usblp.c               |    2 +-
 drivers/usb/core/hcd.h                  |    2 +-
 drivers/usb/core/hub.c                  |    2 +-
 drivers/usb/gadget/inode.c              |    2 +-
 drivers/usb/gadget/serial.c             |    8 ++++----
 drivers/usb/image/mdc800.c              |    2 +-
 drivers/usb/image/microtek.h            |    2 +-
 drivers/usb/media/dabusb.h              |    2 +-
 drivers/usb/media/ov511.c               |    2 +-
 drivers/usb/media/ov511.h               |   10 +++++-----
 drivers/usb/media/pwc/pwc.h             |    4 ++--
 drivers/usb/media/se401.h               |    2 +-
 drivers/usb/media/sn9c102.h             |    4 ++--
 drivers/usb/media/stv680.h              |    2 +-
 drivers/usb/media/usbvideo.h            |    4 ++--
 drivers/usb/media/vicam.c               |    2 +-
 drivers/usb/media/w9968cf.h             |    4 ++--
 drivers/usb/misc/auerswald.c            |    6 +++---
 drivers/usb/misc/idmouse.c              |    2 +-
 drivers/usb/misc/ldusb.c                |    2 +-
 drivers/usb/misc/legousbtower.c         |    2 +-
 drivers/usb/misc/rio500.c               |    2 +-
 drivers/usb/misc/sisusbvga/sisusb.h     |    2 +-
 drivers/usb/misc/sisusbvga/sisusb_con.c |    2 +-
 drivers/usb/misc/usbtest.c              |    2 +-
 drivers/usb/mon/mon_text.c              |    2 +-
 drivers/usb/mon/usb_mon.h               |    2 +-
 drivers/usb/net/kaweth.c                |    2 +-
 drivers/usb/serial/io_ti.c              |    6 +++---
 drivers/usb/serial/ti_usb_3410_5052.c   |    6 +++---
 drivers/usb/storage/usb.h               |    4 ++--
 drivers/video/pxafb.h                   |    2 +-
 drivers/video/sa1100fb.h                |    2 +-
 drivers/w1/w1.h                         |    4 ++--
 37 files changed, 57 insertions(+), 57 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/atm/cxacru.c linux-2.6.15-rc5-mutex/drivers/usb/atm/cxacru.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/atm/cxacru.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/atm/cxacru.c	2005-12-12 21:08:49.000000000 +0000
@@ -160,7 +160,7 @@ struct cxacru_data {
 	struct work_struct poll_work;
 
 	/* contol handles */
-	struct semaphore cm_serialize;
+	struct mutex cm_serialize;
 	u8 *rcv_buf;
 	u8 *snd_buf;
 	struct urb *rcv_urb;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/atm/usbatm.h linux-2.6.15-rc5-mutex/drivers/usb/atm/usbatm.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/atm/usbatm.h	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/atm/usbatm.h	2005-12-12 22:12:49.000000000 +0000
@@ -30,7 +30,7 @@
 #define VERBOSE_DEBUG
 */
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/atm.h>
 #include <linux/atmdev.h>
 #include <linux/completion.h>
@@ -157,7 +157,7 @@ struct usbatm_data {
         ********************************/
 
 	struct kref refcount;
-	struct semaphore serialize;
+	struct mutex serialize;
 
 	/* heavy init */
 	int thread_pid;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/class/usblp.c linux-2.6.15-rc5-mutex/drivers/usb/class/usblp.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/class/usblp.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/class/usblp.c	2005-12-12 21:12:27.000000000 +0000
@@ -128,7 +128,7 @@ MFG:HEWLETT-PACKARD;MDL:DESKJET 970C;CMD
 
 struct usblp {
 	struct usb_device 	*dev;			/* USB device */
-	struct semaphore	sem;			/* locks this struct, especially "dev" */
+	struct mutex		sem;			/* locks this struct, especially "dev" */
 	char			*writebuf;		/* write transfer_buffer */
 	char			*readbuf;		/* read transfer_buffer */
 	char			*statusbuf;		/* status transfer_buffer */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/class/usb-midi.c linux-2.6.15-rc5-mutex/drivers/usb/class/usb-midi.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/class/usb-midi.c	2005-06-22 13:52:04.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/class/usb-midi.c	2005-12-12 22:12:49.000000000 +0000
@@ -37,7 +37,7 @@
 #include <linux/poll.h>
 #include <linux/sound.h>
 #include <linux/init.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "usb-midi.h"
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/core/hcd.h linux-2.6.15-rc5-mutex/drivers/usb/core/hcd.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/core/hcd.h	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/core/hcd.h	2005-12-12 21:12:43.000000000 +0000
@@ -364,7 +364,7 @@ extern void usb_set_device_state(struct 
 /* exported only within usbcore */
 
 extern struct list_head usb_bus_list;
-extern struct semaphore usb_bus_list_lock;
+extern struct mutex usb_bus_list_lock;
 extern wait_queue_head_t usb_kill_urb_queue;
 
 extern struct usb_bus *usb_bus_get (struct usb_bus *bus);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/core/hub.c linux-2.6.15-rc5-mutex/drivers/usb/core/hub.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/core/hub.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/core/hub.c	2005-12-12 22:12:49.000000000 +0000
@@ -23,7 +23,7 @@
 #include <linux/usbdevice_fs.h>
 #include <linux/kthread.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 #include <asm/byteorder.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/gadget/inode.c linux-2.6.15-rc5-mutex/drivers/usb/gadget/inode.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/gadget/inode.c	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/gadget/inode.c	2005-12-12 21:45:18.000000000 +0000
@@ -193,7 +193,7 @@ enum ep_state {
 };
 
 struct ep_data {
-	struct semaphore		lock;
+	struct mutex			lock;
 	enum ep_state			state;
 	atomic_t			count;
 	struct dev_data			*dev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/gadget/serial.c linux-2.6.15-rc5-mutex/drivers/usb/gadget/serial.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/gadget/serial.c	2005-12-08 16:23:46.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/gadget/serial.c	2005-12-12 21:08:36.000000000 +0000
@@ -333,7 +333,7 @@ static const char *EP_IN_NAME;
 static const char *EP_OUT_NAME;
 static const char *EP_NOTIFY_NAME;
 
-static struct semaphore	gs_open_close_sem[GS_NUM_PORTS];
+static struct mutex gs_open_close_sem[GS_NUM_PORTS];
 
 static unsigned int read_q_size = GS_DEFAULT_READ_Q_SIZE;
 static unsigned int write_q_size = GS_DEFAULT_WRITE_Q_SIZE;
@@ -674,7 +674,7 @@ static int __init gs_module_init(void)
 	tty_set_operations(gs_tty_driver, &gs_tty_ops);
 
 	for (i=0; i < GS_NUM_PORTS; i++)
-		sema_init(&gs_open_close_sem[i], 1);
+		init_MUTEX(&gs_open_close_sem[i]);
 
 	retval = tty_register_driver(gs_tty_driver);
 	if (retval) {
@@ -714,7 +714,7 @@ static int gs_open(struct tty_struct *tt
 	struct gs_port *port;
 	struct gs_dev *dev;
 	struct gs_buf *buf;
-	struct semaphore *sem;
+	struct mutex *sem;
 	int ret;
 
 	port_num = tty->index;
@@ -850,7 +850,7 @@ static void gs_close(struct tty_struct *
 {
 	unsigned long flags;
 	struct gs_port *port = tty->driver_data;
-	struct semaphore *sem;
+	struct mutex *sem;
 
 	if (port == NULL) {
 		printk(KERN_ERR "gs_close: NULL port pointer\n");
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/image/mdc800.c linux-2.6.15-rc5-mutex/drivers/usb/image/mdc800.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/image/mdc800.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/image/mdc800.c	2005-12-12 21:12:56.000000000 +0000
@@ -169,7 +169,7 @@ struct mdc800_data
 	int			out_count;	// Bytes in the buffer
 
 	int			open;		// Camera device open ?
-	struct semaphore	io_lock;	// IO -lock
+	struct mutex		io_lock;	// IO -lock
 
 	char 			in [8];		// Command Input Buffer
 	int  			in_count;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/image/microtek.h linux-2.6.15-rc5-mutex/drivers/usb/image/microtek.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/image/microtek.h	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/image/microtek.h	2005-12-12 21:13:03.000000000 +0000
@@ -39,7 +39,7 @@ struct mts_desc {
 	u8 ep_image;
 
 	struct Scsi_Host * host;
-	struct semaphore lock;
+	struct mutex lock;
 
 	struct urb *urb;
 	struct mts_transfer_context context;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/dabusb.h linux-2.6.15-rc5-mutex/drivers/usb/media/dabusb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/dabusb.h	2004-06-18 13:41:51.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/dabusb.h	2005-12-12 21:10:38.000000000 +0000
@@ -18,7 +18,7 @@ typedef enum { _stopped=0, _started } dr
 
 typedef struct
 {
-	struct semaphore mutex;
+	struct mutex mutex;
 	struct usb_device *usbdev;
 	wait_queue_head_t wait;
 	wait_queue_head_t remove_ok;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/ov511.c linux-2.6.15-rc5-mutex/drivers/usb/media/ov511.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/ov511.c	2005-06-22 13:52:05.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/ov511.c	2005-12-12 22:12:49.000000000 +0000
@@ -42,7 +42,7 @@
 #include <linux/slab.h>
 #include <linux/ctype.h>
 #include <linux/pagemap.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/processor.h>
 #include <linux/mm.h>
 #include <linux/device.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/ov511.h linux-2.6.15-rc5-mutex/drivers/usb/media/ov511.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/ov511.h	2004-09-16 12:06:09.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/ov511.h	2005-12-12 21:09:15.000000000 +0000
@@ -435,7 +435,7 @@ struct usb_ov511 {
 
 	int led_policy;		/* LED: off|on|auto; OV511+ only */
 
-	struct semaphore lock;	/* Serializes user-accessible operations */
+	struct mutex lock;	/* Serializes user-accessible operations */
 	int user;		/* user count for exclusive use */
 
 	int streaming;		/* Are we streaming Isochronous? */
@@ -473,11 +473,11 @@ struct usb_ov511 {
 	int packet_size;	/* Frame size per isoc desc */
 	int packet_numbering;	/* Is ISO frame numbering enabled? */
 
-	struct semaphore param_lock;	/* params lock for this camera */
+	struct mutex param_lock;	/* params lock for this camera */
 
 	/* Framebuffer/sbuf management */
 	int buf_state;
-	struct semaphore buf_lock;
+	struct mutex buf_lock;
 
 	struct ov51x_decomp_ops *decomp_ops;
 
@@ -494,12 +494,12 @@ struct usb_ov511 {
 	int pal;		/* Device is designed for PAL resolution */
 
 	/* I2C interface */
-	struct semaphore i2c_lock;	  /* Protect I2C controller regs */
+	struct mutex i2c_lock;	  /* Protect I2C controller regs */
 	unsigned char primary_i2c_slave;  /* I2C write id of sensor */
 
 	/* Control transaction stuff */
 	unsigned char *cbuf;		/* Buffer for payload */
-	struct semaphore cbuf_lock;
+	struct mutex cbuf_lock;
 };
 
 /* Used to represent a list of values and their respective symbolic names */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/pwc/pwc.h linux-2.6.15-rc5-mutex/drivers/usb/media/pwc/pwc.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/pwc/pwc.h	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/pwc/pwc.h	2005-12-12 22:12:49.000000000 +0000
@@ -32,7 +32,7 @@
 #include <linux/videodev.h>
 #include <linux/wait.h>
 #include <linux/smp_lock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/errno.h>
 
 #include "pwc-uncompress.h"
@@ -204,7 +204,7 @@ struct pwc_device
    int image_read_pos;			/* In case we read data in pieces, keep track of were we are in the imagebuffer */
    int image_used[MAX_IMAGES];		/* For MCAPTURE and SYNC */
 
-   struct semaphore modlock;		/* to prevent races in video_open(), etc */
+   struct mutex modlock;		/* to prevent races in video_open(), etc */
    spinlock_t ptrlock;			/* for manipulating the buffer pointers */
 
    /*** motorized pan/tilt feature */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/se401.h linux-2.6.15-rc5-mutex/drivers/usb/media/se401.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/se401.h	2004-06-18 13:41:51.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/se401.h	2005-12-12 21:09:27.000000000 +0000
@@ -189,7 +189,7 @@ struct usb_se401 {
 	int maxframesize;
 	int cframesize;		/* current framesize */
 
-	struct semaphore lock;
+	struct mutex lock;
 	int user;		/* user count for exclusive use */
 	int removed;		/* device disconnected */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/sn9c102.h linux-2.6.15-rc5-mutex/drivers/usb/media/sn9c102.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/sn9c102.h	2005-08-30 13:56:27.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/sn9c102.h	2005-12-12 22:12:49.000000000 +0000
@@ -32,7 +32,7 @@
 #include <linux/types.h>
 #include <linux/param.h>
 #include <linux/rwsem.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "sn9c102_sensor.h"
 
@@ -148,7 +148,7 @@ struct sn9c102_device {
 	enum sn9c102_dev_state state;
 	u8 users;
 
-	struct semaphore dev_sem, fileop_sem;
+	struct mutex dev_sem, fileop_sem;
 	spinlock_t queue_lock;
 	wait_queue_head_t open, wait_frame, wait_stream;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/stv680.h linux-2.6.15-rc5-mutex/drivers/usb/media/stv680.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/stv680.h	2005-08-30 13:56:27.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/stv680.h	2005-12-12 21:10:23.000000000 +0000
@@ -118,7 +118,7 @@ struct usb_stv {
 	int origGain;
 	int origMode;		/* original camera mode */
 
-	struct semaphore lock;	/* to lock the structure */
+	struct mutex lock;	/* to lock the structure */
 	int user;		/* user count for exclusive use */
 	int removed;		/* device disconnected */
 	int streaming;		/* Are we streaming video? */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/usbvideo.h linux-2.6.15-rc5-mutex/drivers/usb/media/usbvideo.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/usbvideo.h	2004-06-18 13:41:51.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/usbvideo.h	2005-12-12 21:10:11.000000000 +0000
@@ -213,7 +213,7 @@ struct uvd {
 	unsigned long flags;		/* FLAGS_USBVIDEO_xxx */
 	unsigned long paletteBits;	/* Which palettes we accept? */
 	unsigned short defaultPalette;	/* What palette to use for read() */
-	struct semaphore lock;
+	struct mutex lock;
 	int user;		/* user count for exclusive use */
 
 	videosize_t videosize;	/* Current setting */
@@ -272,7 +272,7 @@ struct usbvideo {
 	int num_cameras;		/* As allocated */
 	struct usb_driver usbdrv;	/* Interface to the USB stack */
 	char drvName[80];		/* Driver name */
-	struct semaphore lock;		/* Mutex protecting camera structures */
+	struct mutex lock;		/* Mutex protecting camera structures */
 	struct usbvideo_cb cb;		/* Table of callbacks (virtual methods) */
 	struct video_device vdt;	/* Video device template */
 	struct uvd *cam;			/* Array of camera structures */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/vicam.c linux-2.6.15-rc5-mutex/drivers/usb/media/vicam.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/vicam.c	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/vicam.c	2005-12-12 21:10:31.000000000 +0000
@@ -407,7 +407,7 @@ struct vicam_camera {
 	struct usb_device *udev;	// usb device
 
 	/* guard against simultaneous accesses to the camera */
-	struct semaphore cam_lock;
+	struct mutex cam_lock;
 
 	int is_initialized;
 	u8 open_count;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/w9968cf.h linux-2.6.15-rc5-mutex/drivers/usb/media/w9968cf.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/media/w9968cf.h	2005-06-22 13:52:05.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/usb/media/w9968cf.h	2005-12-12 22:12:49.000000000 +0000
@@ -32,7 +32,7 @@
 #include <linux/param.h>
 #include <linux/types.h>
 #include <linux/rwsem.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <media/ovcamchip.h>
 
@@ -278,7 +278,7 @@ struct w9968cf_device {
 	struct i2c_client* sensor_client;
 
 	/* Locks */
-	struct semaphore dev_sem,    /* for probe, disconnect,open and close */
+	struct mutex dev_sem,    /* for probe, disconnect,open and close */
 	                 fileop_sem; /* for read and ioctl */
 	spinlock_t urb_lock,   /* for submit_urb() and unlink_urb() */
 	           flist_lock; /* for requested frame list accesses */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/auerswald.c linux-2.6.15-rc5-mutex/drivers/usb/misc/auerswald.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/auerswald.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/auerswald.c	2005-12-12 21:11:34.000000000 +0000
@@ -232,7 +232,7 @@ typedef struct auerscon
 /* USB device context */
 typedef struct
 {
-	struct semaphore 	mutex;         	    /* protection in user context */
+	struct mutex		mutex;         	    /* protection in user context */
 	char 			name[20];	    /* name of the /dev/usb entry */
 	unsigned int		dtindex;	    /* index in the device table */
 	struct usb_device *	usbdev;      	    /* USB device handle */
@@ -253,12 +253,12 @@ typedef struct
 /* character device context */
 typedef struct
 {
-	struct semaphore mutex;         /* protection in user context */
+	struct mutex mutex;             /* protection in user context */
 	pauerswald_t auerdev;           /* context pointer of assigned device */
         auerbufctl_t bufctl;            /* controls the buffer chain */
         auerscon_t scontext;            /* service context */
 	wait_queue_head_t readwait;     /* for synchronous reading */
-	struct semaphore readmutex;     /* protection against multiple reads */
+	struct mutex readmutex;         /* protection against multiple reads */
 	pauerbuf_t readbuf;		/* buffer held for partial reading */
 	unsigned int readoffset;	/* current offset in readbuf */
 	unsigned int removed;		/* is != 0 if device is removed */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/idmouse.c linux-2.6.15-rc5-mutex/drivers/usb/misc/idmouse.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/idmouse.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/idmouse.c	2005-12-12 21:11:59.000000000 +0000
@@ -81,7 +81,7 @@ struct usb_idmouse {
 
 	int open; /* if the port is open or not */
 	int present; /* if the device is not disconnected */
-	struct semaphore sem; /* locks this structure */
+	struct mutex sem; /* locks this structure */
 
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/ldusb.c linux-2.6.15-rc5-mutex/drivers/usb/misc/ldusb.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/ldusb.c	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/ldusb.c	2005-12-12 21:11:21.000000000 +0000
@@ -136,7 +136,7 @@ MODULE_PARM_DESC(min_interrupt_out_inter
 
 /* Structure to hold all of our device specific stuff */
 struct ld_usb {
-	struct semaphore	sem;		/* locks this structure */
+	struct mutex		sem;		/* locks this structure */
 	struct usb_interface*	intf;		/* save off the usb interface pointer */
 
 	int			open_count;	/* number of times this port has been opened */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/legousbtower.c linux-2.6.15-rc5-mutex/drivers/usb/misc/legousbtower.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/legousbtower.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/legousbtower.c	2005-12-12 21:11:42.000000000 +0000
@@ -205,7 +205,7 @@ MODULE_DEVICE_TABLE (usb, tower_table);
 
 /* Structure to hold all of our device specific stuff */
 struct lego_usb_tower {
-	struct semaphore	sem;		/* locks this structure */
+	struct mutex		sem;		/* locks this structure */
 	struct usb_device*	udev;		/* save off the usb device pointer */
 	unsigned char		minor;		/* the starting minor number for this device */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/rio500.c linux-2.6.15-rc5-mutex/drivers/usb/misc/rio500.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/rio500.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/rio500.c	2005-12-12 21:11:15.000000000 +0000
@@ -69,7 +69,7 @@ struct rio_usb_data {
         char *obuf, *ibuf;              /* transfer buffers */
         char bulk_in_ep, bulk_out_ep;   /* Endpoint assignments */
         wait_queue_head_t wait_q;       /* for timeouts */
-	struct semaphore lock;          /* general race avoidance */
+	struct mutex lock;              /* general race avoidance */
 };
 
 static struct rio_usb_data rio_instance;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/sisusbvga/sisusb_con.c linux-2.6.15-rc5-mutex/drivers/usb/misc/sisusbvga/sisusb_con.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/sisusbvga/sisusb_con.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/sisusbvga/sisusb_con.c	2005-12-12 21:11:53.000000000 +0000
@@ -102,7 +102,7 @@ static struct sisusb_usb_data *mysisusbs
 /* Forward declaration */
 static const struct consw sisusb_con;
 
-extern struct semaphore disconnect_sem;
+extern struct mutex disconnect_sem;
 
 static inline void
 sisusbcon_memsetw(u16 *s, u16 c, unsigned int count)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/sisusbvga/sisusb.h linux-2.6.15-rc5-mutex/drivers/usb/misc/sisusbvga/sisusb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/sisusbvga/sisusb.h	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/sisusbvga/sisusb.h	2005-12-12 21:11:45.000000000 +0000
@@ -124,7 +124,7 @@ struct sisusb_usb_data {
 	struct usb_interface *interface;
 	struct kref kref;
 	wait_queue_head_t wait_q;	/* for syncind and timeouts */
-	struct semaphore lock;		/* general race avoidance */
+	struct mutex lock;		/* general race avoidance */
 	unsigned int ifnum;		/* interface number of the USB device */
 	int minor;			/* minor (for logging clarity) */
 	int isopen;			/* !=0 if open */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/usbtest.c linux-2.6.15-rc5-mutex/drivers/usb/misc/usbtest.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/misc/usbtest.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/misc/usbtest.c	2005-12-12 21:12:07.000000000 +0000
@@ -65,7 +65,7 @@ struct usbtest_dev {
 	int			in_iso_pipe;
 	int			out_iso_pipe;
 	struct usb_endpoint_descriptor	*iso_in, *iso_out;
-	struct semaphore	sem;
+	struct mutex		sem;
 
 #define TBUF_SIZE	256
 	u8			*buf;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/mon/mon_text.c linux-2.6.15-rc5-mutex/drivers/usb/mon/mon_text.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/mon/mon_text.c	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/mon/mon_text.c	2005-12-12 21:10:57.000000000 +0000
@@ -54,7 +54,7 @@ struct mon_reader_text {
 	wait_queue_head_t wait;
 	int printf_size;
 	char *printf_buf;
-	struct semaphore printf_lock;
+	struct mutex printf_lock;
 
 	char slab_name[SLAB_NAME_SZ];
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/mon/usb_mon.h linux-2.6.15-rc5-mutex/drivers/usb/mon/usb_mon.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/mon/usb_mon.h	2005-11-01 13:19:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/mon/usb_mon.h	2005-12-12 21:10:53.000000000 +0000
@@ -49,7 +49,7 @@ void mon_reader_del(struct mon_bus *mbus
  */
 extern char mon_dmapeek(unsigned char *dst, dma_addr_t dma_addr, int len);
 
-extern struct semaphore mon_lock;
+extern struct mutex mon_lock;
 
 extern struct file_operations mon_fops_text;
 extern struct file_operations mon_fops_stat;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/net/kaweth.c linux-2.6.15-rc5-mutex/drivers/usb/net/kaweth.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/net/kaweth.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/net/kaweth.c	2005-12-12 22:12:49.000000000 +0000
@@ -60,7 +60,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/wait.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/byteorder.h>
 
 #undef DEBUG
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/serial/io_ti.c linux-2.6.15-rc5-mutex/drivers/usb/serial/io_ti.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/serial/io_ti.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/serial/io_ti.c	2005-12-12 22:12:49.000000000 +0000
@@ -38,7 +38,7 @@
 #include <linux/serial.h>
 #include <linux/ioctl.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/usb.h>
 
 #include "usb-serial.h"
@@ -134,7 +134,7 @@ struct edgeport_serial {
 	struct product_info product_info;
 	u8 TI_I2C_Type;			// Type of I2C in UMP
 	u8 TiReadI2C;			// Set to TRUE if we have read the I2c in Boot Mode
-	struct semaphore es_sem;
+	struct mutex es_sem;
 	int num_ports_open;
 	struct usb_serial *serial;
 };
@@ -2739,7 +2739,7 @@ static int edge_startup (struct usb_seri
 		return -ENOMEM;
 	}
 	memset (edge_serial, 0, sizeof(struct edgeport_serial));
-	sema_init(&edge_serial->es_sem, 1);
+	init_MUTEX(&edge_serial->es_sem);
 	edge_serial->serial = serial;
 	usb_set_serial_data(serial, edge_serial);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/serial/ti_usb_3410_5052.c linux-2.6.15-rc5-mutex/drivers/usb/serial/ti_usb_3410_5052.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/serial/ti_usb_3410_5052.c	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/serial/ti_usb_3410_5052.c	2005-12-12 22:12:49.000000000 +0000
@@ -82,7 +82,7 @@
 #include <linux/serial.h>
 #include <linux/circ_buf.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/usb.h>
 
 #include "usb-serial.h"
@@ -140,7 +140,7 @@ struct ti_port {
 };
 
 struct ti_device {
-	struct semaphore	td_open_close_sem;
+	struct mutex		td_open_close_sem;
 	int			td_open_port_count;
 	struct usb_serial	*td_serial;
 	int			td_is_3410;
@@ -425,7 +425,7 @@ static int ti_startup(struct usb_serial 
 		return -ENOMEM;
 	}
 	memset(tdev, 0, sizeof(struct ti_device));
-	sema_init(&tdev->td_open_close_sem, 1);
+	init_MUTEX(&tdev->td_open_close_sem);
 	tdev->td_serial = serial;
 	usb_set_serial_data(serial, tdev);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/usb/storage/usb.h linux-2.6.15-rc5-mutex/drivers/usb/storage/usb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/usb/storage/usb.h	2005-12-08 16:23:47.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/usb/storage/usb.h	2005-12-12 21:07:47.000000000 +0000
@@ -130,7 +130,7 @@ struct us_data {
 	 * It's important to note:
 	 *    (o) you must hold dev_semaphore to change pusb_dev
 	 */
-	struct semaphore	dev_semaphore;	 /* protect pusb_dev */
+	struct mutex		dev_semaphore;	 /* protect pusb_dev */
 	struct usb_device	*pusb_dev;	 /* this usb_device */
 	struct usb_interface	*pusb_intf;	 /* this interface */
 	struct us_unusual_dev   *unusual_dev;	 /* device-filter entry     */
@@ -171,7 +171,7 @@ struct us_data {
 	dma_addr_t		iobuf_dma;
 
 	/* mutual exclusion and synchronization structures */
-	struct semaphore	sema;		 /* to sleep thread on	    */
+	struct mutex		sema;		 /* to sleep thread on	    */
 	struct completion	notify;		 /* thread begin/end	    */
 	wait_queue_head_t	delay_wait;	 /* wait during scan, reset */
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/video/pxafb.h linux-2.6.15-rc5-mutex/drivers/video/pxafb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/video/pxafb.h	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/video/pxafb.h	2005-12-12 21:43:47.000000000 +0000
@@ -87,7 +87,7 @@ struct pxafb_info {
 
 	volatile u_char		state;
 	volatile u_char		task_state;
-	struct semaphore	ctrlr_sem;
+	struct mutex		ctrlr_sem;
 	wait_queue_head_t	ctrlr_wait;
 	struct work_struct	task;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/video/sa1100fb.h linux-2.6.15-rc5-mutex/drivers/video/sa1100fb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/video/sa1100fb.h	2004-06-18 13:41:30.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/video/sa1100fb.h	2005-12-12 21:43:53.000000000 +0000
@@ -100,7 +100,7 @@ struct sa1100fb_info {
 
 	volatile u_char		state;
 	volatile u_char		task_state;
-	struct semaphore	ctrlr_sem;
+	struct mutex		ctrlr_sem;
 	wait_queue_head_t	ctrlr_wait;
 	struct work_struct	task;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/w1/w1.h linux-2.6.15-rc5-mutex/drivers/w1/w1.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/w1/w1.h	2005-11-01 13:19:14.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/w1/w1.h	2005-12-12 22:12:50.000000000 +0000
@@ -44,7 +44,7 @@ struct w1_reg_num
 
 #include <net/sock.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "w1_family.h"
 
@@ -173,7 +173,7 @@ struct w1_master
 	long			flags;
 
 	pid_t			kpid;
-	struct semaphore	mutex;
+	struct mutex		mutex;
 
 	struct device_driver	*driver;
 	struct device		dev;

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 9/19] MUTEX: Drivers L-M changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (8 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 10/19] MUTEX: Drivers N-P changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 13/19] MUTEX: Filesystem changes David Howells
                   ` (22 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the files of the drivers/l* thru drivers/m* to use
the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-drivers-LtoM-2615rc5.diff
 drivers/macintosh/adb.c                           |    2 +-
 drivers/macintosh/mediabay.c                      |    2 +-
 drivers/macintosh/therm_windtunnel.c              |    2 +-
 drivers/md/dm-raid1.c                             |   10 +++++-----
 drivers/md/dm.c                                   |    2 +-
 drivers/md/kcopyd.c                               |    2 +-
 drivers/media/dvb/b2c2/flexcop-common.h           |    2 +-
 drivers/media/dvb/b2c2/flexcop-i2c.c              |    2 +-
 drivers/media/dvb/bt8xx/bt878.h                   |    2 +-
 drivers/media/dvb/bt8xx/dst.c                     |    2 +-
 drivers/media/dvb/bt8xx/dst_common.h              |    2 +-
 drivers/media/dvb/bt8xx/dvb-bt8xx.h               |    2 +-
 drivers/media/dvb/cinergyT2/cinergyT2.c           |    2 +-
 drivers/media/dvb/dvb-core/dmxdev.c               |    4 ++--
 drivers/media/dvb/dvb-core/dmxdev.h               |    6 +++---
 drivers/media/dvb/dvb-core/dvb_demux.c            |    2 +-
 drivers/media/dvb/dvb-core/dvb_demux.h            |    4 ++--
 drivers/media/dvb/dvb-core/dvb_frontend.c         |    4 ++--
 drivers/media/dvb/dvb-core/dvb_frontend.h         |    2 +-
 drivers/media/dvb/dvb-core/dvb_net.c              |    2 +-
 drivers/media/dvb/dvb-usb/dvb-usb-init.c          |    4 ++--
 drivers/media/dvb/dvb-usb/dvb-usb.h               |    4 ++--
 drivers/media/dvb/frontends/bcm3510.c             |    4 ++--
 drivers/media/dvb/ttpci/av7110.c                  |    8 ++++----
 drivers/media/dvb/ttpci/av7110.h                  |    6 +++---
 drivers/media/dvb/ttpci/budget.h                  |    2 +-
 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |   10 +++++-----
 drivers/media/dvb/ttusb-dec/ttusb_dec.c           |   10 +++++-----
 drivers/media/radio/miropcm20-rds-core.c          |    4 ++--
 drivers/media/radio/radio-aimslab.c               |    4 ++--
 drivers/media/radio/radio-aztech.c                |    2 +-
 drivers/media/radio/radio-maestro.c               |    4 ++--
 drivers/media/radio/radio-maxiradio.c             |    4 ++--
 drivers/media/radio/radio-sf16fmi.c               |    4 ++--
 drivers/media/radio/radio-sf16fmr2.c              |    4 ++--
 drivers/media/radio/radio-typhoon.c               |    2 +-
 drivers/media/radio/radio-zoltrix.c               |    2 +-
 drivers/media/video/arv.c                         |    4 ++--
 drivers/media/video/bttvp.h                       |    4 ++--
 drivers/media/video/bw-qcam.c                     |    2 +-
 drivers/media/video/bw-qcam.h                     |    2 +-
 drivers/media/video/c-qcam.c                      |    4 ++--
 drivers/media/video/cpia.c                        |    2 +-
 drivers/media/video/cpia.h                        |    4 ++--
 drivers/media/video/cx88/cx88.h                   |    2 +-
 drivers/media/video/em28xx/em28xx.h               |    2 +-
 drivers/media/video/ir-kbd-i2c.c                  |    2 +-
 drivers/media/video/meye.h                        |    2 +-
 drivers/media/video/msp3400.c                     |    2 +-
 drivers/media/video/planb.c                       |    2 +-
 drivers/media/video/planb.h                       |    2 +-
 drivers/media/video/pms.c                         |    2 +-
 drivers/media/video/saa5246a.c                    |    2 +-
 drivers/media/video/saa5249.c                     |    2 +-
 drivers/media/video/saa7134/saa7134.h             |    4 ++--
 drivers/media/video/tvmixer.c                     |    2 +-
 drivers/media/video/videodev.c                    |    2 +-
 drivers/media/video/vino.c                        |    4 ++--
 drivers/media/video/zoran.h                       |    2 +-
 drivers/message/fusion/mptbase.h                  |    4 ++--
 drivers/message/fusion/mptctl.c                   |    2 +-
 drivers/mfd/ucb1x00-core.c                        |    4 ++--
 drivers/mfd/ucb1x00-ts.c                          |    2 +-
 drivers/mmc/mmc_queue.h                           |    2 +-
 drivers/mtd/devices/blkmtd.c                      |    2 +-
 drivers/mtd/devices/block2mtd.c                   |    2 +-
 drivers/mtd/mtd_blkdevs.c                         |    4 ++--
 drivers/mtd/mtdblock.c                            |    2 +-
 68 files changed, 108 insertions(+), 108 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/macintosh/adb.c linux-2.6.15-rc5-mutex/drivers/macintosh/adb.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/macintosh/adb.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/macintosh/adb.c	2005-12-12 22:12:49.000000000 +0000
@@ -39,7 +39,7 @@
 #include <linux/devfs_fs_kernel.h>
 
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #ifdef CONFIG_PPC
 #include <asm/prom.h>
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/macintosh/mediabay.c linux-2.6.15-rc5-mutex/drivers/macintosh/mediabay.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/macintosh/mediabay.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/macintosh/mediabay.c	2005-12-12 21:45:18.000000000 +0000
@@ -78,7 +78,7 @@ struct media_bay_info {
 	int				index;
 	int				cached_gpio;
 	int				sleeping;
-	struct semaphore		lock;
+	struct mutex			lock;
 #ifdef CONFIG_BLK_DEV_IDE
 	void __iomem			*cd_base;
 	int 				cd_index;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/macintosh/therm_windtunnel.c linux-2.6.15-rc5-mutex/drivers/macintosh/therm_windtunnel.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/macintosh/therm_windtunnel.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/macintosh/therm_windtunnel.c	2005-12-12 21:45:18.000000000 +0000
@@ -64,7 +64,7 @@ static struct {
 	struct completion	completion;
 	pid_t			poll_task;
 	
-	struct semaphore 	lock;
+	struct mutex		lock;
 	struct of_device	*of_dev;
 	
 	struct i2c_client	*thermostat;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/md/dm.c linux-2.6.15-rc5-mutex/drivers/md/dm.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/md/dm.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/md/dm.c	2005-12-12 20:57:20.000000000 +0000
@@ -58,7 +58,7 @@ union map_info *dm_get_mapinfo(struct bi
 
 struct mapped_device {
 	struct rw_semaphore io_lock;
-	struct semaphore suspend_lock;
+	struct mutex suspend_lock;
 	rwlock_t map_lock;
 	atomic_t holders;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/md/dm-raid1.c linux-2.6.15-rc5-mutex/drivers/md/dm-raid1.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/md/dm-raid1.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/md/dm-raid1.c	2005-12-12 20:31:51.000000000 +0000
@@ -358,7 +358,7 @@ static void rh_update_states(struct regi
 		rh->log->type->clear_region(rh->log, reg->key);
 		rh->log->type->complete_resync_work(rh->log, reg->key, 1);
 		dispatch_bios(rh->ms, &reg->delayed_bios);
-		up(&rh->recovery_count);
+		up_sem(&rh->recovery_count);
 		mempool_free(reg, rh->region_pool);
 	}
 
@@ -468,9 +468,9 @@ static int __rh_recovery_prepare(struct 
 
 static void rh_recovery_prepare(struct region_hash *rh)
 {
-	while (!down_trylock(&rh->recovery_count))
+	while (!down_sem_trylock(&rh->recovery_count))
 		if (__rh_recovery_prepare(rh) <= 0) {
-			up(&rh->recovery_count);
+			up_sem(&rh->recovery_count);
 			break;
 		}
 }
@@ -526,7 +526,7 @@ static void rh_stop_recovery(struct regi
 
 	/* wait for any recovering regions */
 	for (i = 0; i < MAX_RECOVERY; i++)
-		down(&rh->recovery_count);
+		down_sem(&rh->recovery_count);
 }
 
 static void rh_start_recovery(struct region_hash *rh)
@@ -534,7 +534,7 @@ static void rh_start_recovery(struct reg
 	int i;
 
 	for (i = 0; i < MAX_RECOVERY; i++)
-		up(&rh->recovery_count);
+		up_sem(&rh->recovery_count);
 
 	wake();
 }
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/md/kcopyd.c linux-2.6.15-rc5-mutex/drivers/md/kcopyd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/md/kcopyd.c	2005-03-02 12:08:10.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/md/kcopyd.c	2005-12-12 20:57:05.000000000 +0000
@@ -191,7 +191,7 @@ struct kcopyd_job {
 	 * These fields are only used if the job has been split
 	 * into more manageable parts.
 	 */
-	struct semaphore lock;
+	struct mutex lock;
 	atomic_t sub_jobs;
 	sector_t progress;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/b2c2/flexcop-common.h linux-2.6.15-rc5-mutex/drivers/media/dvb/b2c2/flexcop-common.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/b2c2/flexcop-common.h	2005-08-30 13:56:18.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/b2c2/flexcop-common.h	2005-12-12 20:02:23.000000000 +0000
@@ -73,7 +73,7 @@ struct flexcop_device {
 	int (*fe_sleep) (struct dvb_frontend *);
 
 	struct i2c_adapter i2c_adap;
-	struct semaphore i2c_sem;
+	struct mutex i2c_sem;
 
 	struct module *owner;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/b2c2/flexcop-i2c.c linux-2.6.15-rc5-mutex/drivers/media/dvb/b2c2/flexcop-i2c.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/b2c2/flexcop-i2c.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/b2c2/flexcop-i2c.c	2005-12-12 20:01:59.000000000 +0000
@@ -180,7 +180,7 @@ int flexcop_i2c_init(struct flexcop_devi
 {
 	int ret;
 
-	sema_init(&fc->i2c_sem,1);
+	init_MUTEX(&fc->i2c_sem);
 
 	memset(&fc->i2c_adap, 0, sizeof(struct i2c_adapter));
 	strncpy(fc->i2c_adap.name, "B2C2 FlexCop device",I2C_NAME_SIZE);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/bt878.h linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/bt878.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/bt878.h	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/bt878.h	2005-12-12 21:01:28.000000000 +0000
@@ -91,7 +91,7 @@
 extern int bt878_num;
 
 struct bt878 {
-	struct semaphore  gpio_lock;
+	struct mutex  gpio_lock;
 	unsigned int nr;
 	unsigned int bttv_nr;
 	struct i2c_adapter *adapter;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/dst.c linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/dst.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/dst.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/dst.c	2005-12-12 20:05:44.000000000 +0000
@@ -910,7 +910,7 @@ static int dst_get_device_id(struct dst_
 
 static int dst_probe(struct dst_state *state)
 {
-	sema_init(&state->dst_mutex, 1);
+	init_MUTEX(&state->dst_mutex);
 	if ((rdc_8820_reset(state)) < 0) {
 		dprintk(verbose, DST_ERROR, 1, "RDC 8820 RESET Failed.");
 		return -1;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/dst_common.h linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/dst_common.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/dst_common.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/dst_common.h	2005-12-12 20:05:57.000000000 +0000
@@ -121,7 +121,7 @@ struct dst_state {
 	u8 vendor[8];
 	u8 board_info[8];
 
-	struct semaphore dst_mutex;
+	struct mutex dst_mutex;
 };
 
 struct dst_types {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/dvb-bt8xx.h linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/dvb-bt8xx.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/bt8xx/dvb-bt8xx.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/bt8xx/dvb-bt8xx.h	2005-12-12 21:01:24.000000000 +0000
@@ -38,7 +38,7 @@
 #include "lgdt330x.h"
 
 struct dvb_bt8xx_card {
-	struct semaphore lock;
+	struct mutex lock;
 	int nfeeds;
 	char card_name[32];
 	struct dvb_adapter dvb_adapter;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/cinergyT2/cinergyT2.c linux-2.6.15-rc5-mutex/drivers/media/dvb/cinergyT2/cinergyT2.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/cinergyT2/cinergyT2.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/cinergyT2/cinergyT2.c	2005-12-12 21:01:13.000000000 +0000
@@ -116,7 +116,7 @@ static struct dvb_frontend_info cinergyt
 struct cinergyt2 {
 	struct dvb_demux demux;
 	struct usb_device *udev;
-	struct semaphore sem;
+	struct mutex sem;
 	struct dvb_adapter adapter;
 	struct dvb_device *fedev;
 	struct dmxdev dmxdev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dmxdev.c linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dmxdev.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dmxdev.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dmxdev.c	2005-12-12 20:01:25.000000000 +0000
@@ -701,7 +701,7 @@ static int dvb_demux_open(struct inode *
 	}
 
 	dmxdevfilter=&dmxdev->filter[i];
-	sema_init(&dmxdevfilter->mutex, 1);
+	init_MUTEX(&dmxdevfilter->mutex);
 	dmxdevfilter->dvbdev=dmxdev->dvbdev;
 	file->private_data=dmxdevfilter;
 
@@ -1113,7 +1113,7 @@ dvb_dmxdev_init(struct dmxdev *dmxdev, s
 		return -ENOMEM;
 	}
 
-	sema_init(&dmxdev->mutex, 1);
+	init_MUTEX(&dmxdev->mutex);
 	spin_lock_init(&dmxdev->lock);
 	for (i=0; i<dmxdev->filternum; i++) {
 		dmxdev->filter[i].dev=dmxdev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dmxdev.h linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dmxdev.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dmxdev.h	2005-06-22 13:51:50.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dmxdev.h	2005-12-12 22:12:50.000000000 +0000
@@ -30,7 +30,7 @@
 #include <linux/wait.h>
 #include <linux/fs.h>
 #include <linux/string.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/dvb/dmx.h>
 
@@ -83,7 +83,7 @@ struct dmxdev_filter {
         struct dmxdev *dev;
         struct dmxdev_buffer buffer;
 
-	struct semaphore mutex;
+	struct mutex mutex;
 
         /* only for sections */
         struct timer_list timer;
@@ -117,7 +117,7 @@ struct dmxdev {
         struct dmxdev_buffer dvr_buffer;
 #define DVR_BUFFER_SIZE (10*188*1024)
 
-	struct semaphore mutex;
+	struct mutex mutex;
 	spinlock_t lock;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_demux.c linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_demux.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_demux.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_demux.c	2005-12-12 20:00:22.000000000 +0000
@@ -1215,7 +1215,7 @@ int dvb_dmx_init(struct dvb_demux *dvbde
 	dmx->disconnect_frontend = dvbdmx_disconnect_frontend;
 	dmx->get_pes_pids = dvbdmx_get_pes_pids;
 
-	sema_init(&dvbdemux->mutex, 1);
+	init_MUTEX(&dvbdemux->mutex);
 	spin_lock_init(&dvbdemux->lock);
 
 	return 0;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_demux.h linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_demux.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_demux.h	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_demux.h	2005-12-12 22:12:50.000000000 +0000
@@ -26,7 +26,7 @@
 #include <linux/time.h>
 #include <linux/timer.h>
 #include <linux/spinlock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "demux.h"
 
@@ -125,7 +125,7 @@ struct dvb_demux {
 	u8 tsbuf[204];
 	int tsbufp;
 
-	struct semaphore mutex;
+	struct mutex mutex;
 	spinlock_t lock;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_frontend.c linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_frontend.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_frontend.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_frontend.c	2005-12-12 22:12:50.000000000 +0000
@@ -37,7 +37,7 @@
 #include <linux/suspend.h>
 #include <linux/jiffies.h>
 #include <asm/processor.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "dvb_frontend.h"
 #include "dvbdev.h"
@@ -95,7 +95,7 @@ struct dvb_frontend_private {
 	struct dvb_device *dvbdev;
 	struct dvb_frontend_parameters parameters;
 	struct dvb_fe_events events;
-	struct semaphore sem;
+	struct mutex sem;
 	struct list_head list_head;
 	wait_queue_head_t wait_queue;
 	pid_t thread_pid;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_frontend.h linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_frontend.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_frontend.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_frontend.h	2005-12-12 21:00:24.000000000 +0000
@@ -86,7 +86,7 @@ struct dvb_fe_events {
 	int			  eventr;
 	int			  overflow;
 	wait_queue_head_t	  wait_queue;
-	struct semaphore	  sem;
+	struct mutex		  sem;
 };
 
 struct dvb_frontend {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_net.c linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_net.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-core/dvb_net.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-core/dvb_net.c	2005-12-12 21:00:56.000000000 +0000
@@ -152,7 +152,7 @@ struct dvb_net_priv {
 	int ule_sndu_remain;			/* Nr. of bytes still required for current ULE SNDU. */
 	unsigned long ts_count;			/* Current ts cell counter. */
 
-	struct semaphore mutex;
+	struct mutex mutex;
 };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-usb/dvb-usb.h linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-usb/dvb-usb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-usb/dvb-usb.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-usb/dvb-usb.h	2005-12-12 20:03:48.000000000 +0000
@@ -276,10 +276,10 @@ struct dvb_usb_device {
 	int pid_filtering;
 
 	/* locking */
-	struct semaphore usb_sem;
+	struct mutex usb_sem;
 
 	/* i2c */
-	struct semaphore i2c_sem;
+	struct mutex i2c_sem;
 	struct i2c_adapter i2c_adap;
 
 	/* tuner programming information */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-usb/dvb-usb-init.c linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-usb/dvb-usb-init.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/dvb-usb/dvb-usb-init.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/dvb-usb/dvb-usb-init.c	2005-12-12 20:03:58.000000000 +0000
@@ -42,8 +42,8 @@ static int dvb_usb_init(struct dvb_usb_d
 {
 	int ret = 0;
 
-	sema_init(&d->usb_sem, 1);
-	sema_init(&d->i2c_sem, 1);
+	init_MUTEX(&d->usb_sem);
+	init_MUTEX(&d->i2c_sem);
 
 	d->state = DVB_USB_STATE_INIT;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/frontends/bcm3510.c linux-2.6.15-rc5-mutex/drivers/media/dvb/frontends/bcm3510.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/frontends/bcm3510.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/frontends/bcm3510.c	2005-12-12 20:00:14.000000000 +0000
@@ -52,7 +52,7 @@ struct bcm3510_state {
 	struct dvb_frontend frontend;
 
 	/* demodulator private data */
-	struct semaphore hab_sem;
+	struct mutex hab_sem;
 	u8 firmware_loaded:1;
 
 	unsigned long next_status_check;
@@ -797,7 +797,7 @@ struct dvb_frontend* bcm3510_attach(cons
 	state->frontend.ops = &state->ops;
 	state->frontend.demodulator_priv = state;
 
-	sema_init(&state->hab_sem, 1);
+	init_MUTEX(&state->hab_sem);
 
 	if ((ret = bcm3510_readB(state,0xe0,&v)) < 0)
 		goto error;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttpci/av7110.c linux-2.6.15-rc5-mutex/drivers/media/dvb/ttpci/av7110.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttpci/av7110.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/ttpci/av7110.c	2005-12-12 22:12:50.000000000 +0000
@@ -54,7 +54,7 @@
 #include <linux/i2c.h>
 
 #include <asm/system.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/dvb/frontend.h>
 
@@ -2650,16 +2650,16 @@ static int av7110_attach(struct saa7146_
 	tasklet_init (&av7110->debi_tasklet, debiirq, (unsigned long) av7110);
 	tasklet_init (&av7110->gpio_tasklet, gpioirq, (unsigned long) av7110);
 
-	sema_init(&av7110->pid_mutex, 1);
+	init_SEMA(&av7110->pid_mutex);
 
 	/* locks for data transfers from/to AV7110 */
 	spin_lock_init(&av7110->debilock);
-	sema_init(&av7110->dcomlock, 1);
+	init_MUTEX(&av7110->dcomlock);
 	av7110->debitype = -1;
 
 	/* default OSD window */
 	av7110->osdwin = 1;
-	sema_init(&av7110->osd_sema, 1);
+	init_MUTEX(&av7110->osd_sema);
 
 	/* ARM "watchdog" */
 	init_waitqueue_head(&av7110->arm_wait);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttpci/av7110.h linux-2.6.15-rc5-mutex/drivers/media/dvb/ttpci/av7110.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttpci/av7110.h	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/ttpci/av7110.h	2005-12-12 20:03:15.000000000 +0000
@@ -126,7 +126,7 @@ struct av7110 {
 	/* DEBI and polled command interface */
 
 	spinlock_t		debilock;
-	struct semaphore	dcomlock;
+	struct mutex		dcomlock;
 	volatile int		debitype;
 	volatile int		debilen;
 
@@ -145,7 +145,7 @@ struct av7110 {
 
 	int			osdwin;      /* currently active window */
 	u16			osdbpp[8];
-	struct semaphore	osd_sema;
+	struct mutex		osd_sema;
 
 	/* CA */
 
@@ -171,7 +171,7 @@ struct av7110 {
 	struct tasklet_struct   vpe_tasklet;
 
 	int			fe_synced;
-	struct semaphore	pid_mutex;
+	struct mutex		pid_mutex;
 
 	int			video_blank;
 	struct video_status	videostate;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttpci/budget.h linux-2.6.15-rc5-mutex/drivers/media/dvb/ttpci/budget.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttpci/budget.h	2005-06-22 13:51:52.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/ttpci/budget.h	2005-12-12 21:01:03.000000000 +0000
@@ -51,7 +51,7 @@ struct budget {
 	struct dmx_frontend mem_frontend;
 
 	int fe_synced;
-	struct semaphore pid_mutex;
+	struct mutex pid_mutex;
 
 	int ci_present;
 	int video_port;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c linux-2.6.15-rc5-mutex/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c	2005-12-12 22:12:50.000000000 +0000
@@ -19,7 +19,7 @@
 #include <linux/time.h>
 #include <linux/errno.h>
 #include <linux/jiffies.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "dvb_frontend.h"
 #include "dmxdev.h"
@@ -83,8 +83,8 @@ struct ttusb {
 	struct dvb_net dvbnet;
 
 	/* and one for USB access. */
-	struct semaphore semi2c;
-	struct semaphore semusb;
+	struct mutex semi2c;
+	struct mutex semusb;
 
 	struct dvb_adapter adapter;
 	struct usb_device *dev;
@@ -1497,8 +1497,8 @@ static int ttusb_probe(struct usb_interf
 	ttusb->dev = udev;
 	ttusb->c = 0;
 	ttusb->mux_state = 0;
-	sema_init(&ttusb->semi2c, 0);
-	sema_init(&ttusb->semusb, 1);
+	init_MUTEX_LOCKED(&ttusb->semi2c);
+	init_MUTEX(&ttusb->semusb);
 
 	ttusb_setup_interfaces(ttusb);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttusb-dec/ttusb_dec.c linux-2.6.15-rc5-mutex/drivers/media/dvb/ttusb-dec/ttusb_dec.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/dvb/ttusb-dec/ttusb_dec.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/dvb/ttusb-dec/ttusb_dec.c	2005-12-12 22:12:50.000000000 +0000
@@ -20,7 +20,7 @@
  *
  */
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/list.h>
 #include <linux/module.h>
 #include <linux/moduleparam.h>
@@ -115,7 +115,7 @@ struct ttusb_dec {
 	unsigned int			out_pipe;
 	unsigned int			irq_pipe;
 	enum ttusb_dec_interface	interface;
-	struct semaphore		usb_sem;
+	struct mutex			usb_sem;
 
 	void			*irq_buffer;
 	struct urb		*irq_urb;
@@ -124,7 +124,7 @@ struct ttusb_dec {
 	dma_addr_t		iso_dma_handle;
 	struct urb		*iso_urb[ISO_BUF_COUNT];
 	int			iso_stream_count;
-	struct semaphore	iso_sem;
+	struct mutex		iso_sem;
 
 	u8				packet[MAX_PVA_LENGTH + 4];
 	enum ttusb_dec_packet_type	packet_type;
@@ -1230,8 +1230,8 @@ static int ttusb_dec_init_usb(struct ttu
 {
 	dprintk("%s\n", __FUNCTION__);
 
-	sema_init(&dec->usb_sem, 1);
-	sema_init(&dec->iso_sem, 1);
+	init_MUTEX(&dec->usb_sem);
+	init_MUTEX(&dec->iso_sem);
 
 	dec->command_pipe = usb_sndbulkpipe(dec->udev, COMMAND_PIPE);
 	dec->result_pipe = usb_rcvbulkpipe(dec->udev, RESULT_PIPE);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/miropcm20-rds-core.c linux-2.6.15-rc5-mutex/drivers/media/radio/miropcm20-rds-core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/miropcm20-rds-core.c	2004-06-18 13:41:41.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/miropcm20-rds-core.c	2005-12-12 22:12:50.000000000 +0000
@@ -18,14 +18,14 @@
 #include <linux/string.h>
 #include <linux/init.h>
 #include <linux/slab.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/io.h>
 #include "../../../sound/oss/aci.h"
 #include "miropcm20-rds-core.h"
 
 #define DEBUG 0
 
-static struct semaphore aci_rds_sem;
+static struct mutex aci_rds_sem;
 
 #define RDS_DATASHIFT          2   /* Bit 2 */
 #define RDS_DATAMASK        (1 << RDS_DATASHIFT)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-aimslab.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-aimslab.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-aimslab.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-aimslab.c	2005-12-12 22:12:50.000000000 +0000
@@ -35,7 +35,7 @@
 #include <asm/uaccess.h>	/* copy to/from user		*/
 #include <linux/videodev.h>	/* kernel radio structs		*/
 #include <linux/config.h>	/* CONFIG_RADIO_RTRACK_PORT 	*/
-#include <asm/semaphore.h>	/* Lock for the I/O 		*/
+#include <linux/semaphore.h>	/* Lock for the I/O 		*/
 
 #ifndef CONFIG_RADIO_RTRACK_PORT
 #define CONFIG_RADIO_RTRACK_PORT -1
@@ -43,7 +43,7 @@
 
 static int io = CONFIG_RADIO_RTRACK_PORT; 
 static int radio_nr = -1;
-static struct semaphore lock;
+static struct mutex lock;
 
 struct rt_device
 {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-aztech.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-aztech.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-aztech.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-aztech.c	2005-12-12 21:02:32.000000000 +0000
@@ -42,7 +42,7 @@
 static int io = CONFIG_RADIO_AZTECH_PORT; 
 static int radio_nr = -1;
 static int radio_wait_time = 1000;
-static struct semaphore lock;
+static struct mutex lock;
 
 struct az_device
 {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-maestro.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-maestro.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-maestro.c	2005-08-30 13:56:18.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-maestro.c	2005-12-12 22:12:50.000000000 +0000
@@ -23,7 +23,7 @@
 #include <linux/sched.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/pci.h>
 #include <linux/videodev.h>
 
@@ -90,7 +90,7 @@ static struct radio_device
 		muted,	/* VIDEO_AUDIO_MUTE */
 		stereo,	/* VIDEO_TUNER_STEREO_ON */	
 		tuned;	/* signal strength (0 or 0xffff) */
-	struct  semaphore lock;
+	struct  mutex lock;
 } radio_unit = {0, 0, 0, 0, };
 
 static __u32 radio_bits_get(struct radio_device *dev)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-maxiradio.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-maxiradio.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-maxiradio.c	2005-08-30 13:56:18.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-maxiradio.c	2005-12-12 22:12:50.000000000 +0000
@@ -37,7 +37,7 @@
 #include <linux/sched.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/pci.h>
 #include <linux/videodev.h>
 
@@ -100,7 +100,7 @@ static struct radio_device
 		
 	unsigned long freq;
 	
-	struct  semaphore lock;
+	struct  mutex lock;
 } radio_unit = {0, 0, 0, 0, };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-sf16fmi.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-sf16fmi.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-sf16fmi.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-sf16fmi.c	2005-12-12 22:12:50.000000000 +0000
@@ -24,7 +24,7 @@
 #include <linux/isapnp.h>
 #include <asm/io.h>		/* outb, outb_p			*/
 #include <asm/uaccess.h>	/* copy to/from user		*/
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 struct fmi_device
 {
@@ -37,7 +37,7 @@ struct fmi_device
 static int io = -1; 
 static int radio_nr = -1;
 static struct pnp_dev *dev = NULL;
-static struct semaphore lock;
+static struct mutex lock;
 
 /* freq is in 1/16 kHz to internal number, hw precision is 50 kHz */
 /* It is only useful to give freq in intervall of 800 (=0.05Mhz),
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-sf16fmr2.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-sf16fmr2.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-sf16fmr2.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-sf16fmr2.c	2005-12-12 22:12:50.000000000 +0000
@@ -19,9 +19,9 @@
 #include <asm/io.h>		/* outb, outb_p			*/
 #include <asm/uaccess.h>	/* copy to/from user		*/
 #include <linux/videodev.h>	/* kernel radio structs		*/
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
-static struct semaphore lock;
+static struct mutex lock;
 
 #undef DEBUG
 //#define DEBUG 1
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-typhoon.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-typhoon.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-typhoon.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-typhoon.c	2005-12-12 21:04:13.000000000 +0000
@@ -59,7 +59,7 @@ struct typhoon_device {
 	int muted;
 	unsigned long curfreq;
 	unsigned long mutefreq;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 static void typhoon_setvol_generic(struct typhoon_device *dev, int vol);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-zoltrix.c linux-2.6.15-rc5-mutex/drivers/media/radio/radio-zoltrix.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/radio/radio-zoltrix.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/radio/radio-zoltrix.c	2005-12-12 21:03:32.000000000 +0000
@@ -48,7 +48,7 @@ struct zol_device {
 	unsigned long curfreq;
 	int muted;
 	unsigned int stereo;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 static int zol_setvol(struct zol_device *dev, int vol)
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/arv.c linux-2.6.15-rc5-mutex/drivers/media/video/arv.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/arv.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/arv.c	2005-12-12 22:12:50.000000000 +0000
@@ -32,7 +32,7 @@
 #include <linux/sched.h>
 #include <linux/videodev.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 #include <asm/m32r.h>
 #include <asm/io.h>
@@ -117,7 +117,7 @@ struct ar_device {
 	int width, height;
 	int frame_bytes, line_bytes;
 	wait_queue_head_t wait;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 static int video_nr = -1;	/* video device number (first free) */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/bttvp.h linux-2.6.15-rc5-mutex/drivers/media/video/bttvp.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/bttvp.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/bttvp.h	2005-12-12 21:07:01.000000000 +0000
@@ -303,9 +303,9 @@ struct bttv {
 
 	/* locking */
 	spinlock_t s_lock;
-	struct semaphore lock;
+	struct mutex lock;
 	int resources;
-	struct semaphore reslock;
+	struct mutex reslock;
 #ifdef VIDIOC_G_PRIORITY
 	struct v4l2_prio_state prio;
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/bw-qcam.c linux-2.6.15-rc5-mutex/drivers/media/video/bw-qcam.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/bw-qcam.c	2005-03-02 12:08:11.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/bw-qcam.c	2005-12-12 22:12:50.000000000 +0000
@@ -73,7 +73,7 @@ OTHER DEALINGS IN THE SOFTWARE.
 #include <linux/parport.h>
 #include <linux/sched.h>
 #include <linux/videodev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 #include "bw-qcam.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/bw-qcam.h linux-2.6.15-rc5-mutex/drivers/media/video/bw-qcam.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/bw-qcam.h	2004-06-18 13:41:41.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/bw-qcam.h	2005-12-12 21:05:53.000000000 +0000
@@ -55,7 +55,7 @@ struct qcam_device {
 	struct video_device vdev;
 	struct pardevice *pdev;
 	struct parport *pport;
-	struct semaphore lock;
+	struct mutex lock;
 	int width, height;
 	int bpp;
 	int mode;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/cpia.c linux-2.6.15-rc5-mutex/drivers/media/video/cpia.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/cpia.c	2005-11-01 13:19:08.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/cpia.c	2005-12-12 22:12:50.000000000 +0000
@@ -39,7 +39,7 @@
 #include <linux/pagemap.h>
 #include <linux/delay.h>
 #include <asm/io.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #ifdef CONFIG_KMOD
 #include <linux/kmod.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/cpia.h linux-2.6.15-rc5-mutex/drivers/media/video/cpia.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/cpia.h	2004-06-18 13:41:41.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/cpia.h	2005-12-12 21:06:15.000000000 +0000
@@ -246,7 +246,7 @@ enum v4l_camstates {
 struct cam_data {
 	struct list_head cam_data_list;
 
-        struct semaphore busy_lock;     /* guard against SMP multithreading */
+        struct mutex busy_lock;		/* guard against SMP multithreading */
 	struct cpia_camera_ops *ops;	/* lowlevel driver operations */
 	void *lowlevel_data;		/* private data for lowlevel driver */
 	u8 *raw_image;			/* buffer for raw image data */
@@ -261,7 +261,7 @@ struct cam_data {
 	u8 mainsFreq;			/* for flicker control */
 
 				/* proc interface */
-	struct semaphore param_lock;	/* params lock for this camera */
+	struct mutex param_lock;	/* params lock for this camera */
 	struct cam_params params;	/* camera settings */
 	struct proc_dir_entry *proc_entry;	/* /proc/cpia/videoX */
 	
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/c-qcam.c linux-2.6.15-rc5-mutex/drivers/media/video/c-qcam.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/c-qcam.c	2005-06-22 13:51:52.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/c-qcam.c	2005-12-12 22:12:50.000000000 +0000
@@ -34,7 +34,7 @@
 #include <linux/parport.h>
 #include <linux/sched.h>
 #include <linux/videodev.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 struct qcam_device {
@@ -47,7 +47,7 @@ struct qcam_device {
 	int contrast, brightness, whitebal;
 	int top, left;
 	unsigned int bidirectional;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 /* cameras maximum */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/cx88/cx88.h linux-2.6.15-rc5-mutex/drivers/media/video/cx88/cx88.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/cx88/cx88.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/cx88/cx88.h	2005-12-12 21:05:06.000000000 +0000
@@ -297,7 +297,7 @@ struct cx88_core {
 	/* IR remote control state */
 	struct cx88_IR             *ir;
 
-	struct semaphore           lock;
+	struct mutex               lock;
 
 	/* various v4l controls */
 	u32                        freq;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/em28xx/em28xx.h linux-2.6.15-rc5-mutex/drivers/media/video/em28xx/em28xx.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/em28xx/em28xx.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/em28xx/em28xx.h	2005-12-12 21:45:51.000000000 +0000
@@ -254,7 +254,7 @@ struct em28xx {
 	enum em28xx_stream_state stream;
 	enum em28xx_io_method io;
 	/* locks */
-	struct semaphore lock, fileop_lock;
+	struct mutex mutex, mutex_lock;
 	spinlock_t queue_lock;
 	struct list_head inqueue, outqueue;
 	wait_queue_head_t open, wait_frame, wait_stream;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/ir-kbd-i2c.c linux-2.6.15-rc5-mutex/drivers/media/video/ir-kbd-i2c.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/ir-kbd-i2c.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/ir-kbd-i2c.c	2005-12-12 22:12:50.000000000 +0000
@@ -39,7 +39,7 @@
 #include <linux/slab.h>
 #include <linux/i2c.h>
 #include <linux/workqueue.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <media/ir-common.h>
 #include <media/ir-kbd-i2c.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/meye.h linux-2.6.15-rc5-mutex/drivers/media/video/meye.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/meye.h	2005-01-04 11:13:16.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/meye.h	2005-12-12 21:05:41.000000000 +0000
@@ -301,7 +301,7 @@ struct meye {
 					/* list of buffers */
 	struct meye_grab_buffer grab_buffer[MEYE_MAX_BUFNBRS];
 	int vma_use_count[MEYE_MAX_BUFNBRS]; /* mmap count */
-	struct semaphore lock;		/* semaphore for open/mmap... */
+	struct mutex lock;		/* semaphore for open/mmap... */
 	struct kfifo *grabq;		/* queue for buffers to be grabbed */
 	spinlock_t grabq_lock;		/* lock protecting the queue */
 	struct kfifo *doneq;		/* queue for grabbed buffers */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/msp3400.c linux-2.6.15-rc5-mutex/drivers/media/video/msp3400.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/msp3400.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/msp3400.c	2005-12-12 22:12:50.000000000 +0000
@@ -50,7 +50,7 @@
 #include <linux/smp_lock.h>
 #include <linux/kthread.h>
 #include <linux/suspend.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/pgtable.h>
 
 #include <media/audiochip.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/planb.c linux-2.6.15-rc5-mutex/drivers/media/video/planb.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/planb.c	2005-06-22 13:51:52.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/planb.c	2005-12-12 22:12:50.000000000 +0000
@@ -48,7 +48,7 @@
 #include <asm/pgtable.h>
 #include <asm/page.h>
 #include <asm/irq.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include "planb.h"
 #include "saa7196.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/planb.h linux-2.6.15-rc5-mutex/drivers/media/video/planb.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/planb.h	2004-06-18 13:41:41.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/planb.h	2005-12-12 21:05:11.000000000 +0000
@@ -174,7 +174,7 @@ struct planb {
 	int	user;
 	unsigned int tab_size;
 	int     maxlines;
-	struct semaphore lock;
+	struct mutex lock;
 	unsigned int	irq;			/* interrupt number */
 	volatile unsigned int intr_mask;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/pms.c linux-2.6.15-rc5-mutex/drivers/media/video/pms.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/pms.c	2005-03-02 12:08:12.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/pms.c	2005-12-12 21:05:35.000000000 +0000
@@ -44,7 +44,7 @@ struct pms_device
 	struct video_picture picture;
 	int height;
 	int width;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 struct i2c_info
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/saa5246a.c linux-2.6.15-rc5-mutex/drivers/media/video/saa5246a.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/saa5246a.c	2005-08-30 13:56:18.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/saa5246a.c	2005-12-12 21:07:15.000000000 +0000
@@ -57,7 +57,7 @@ struct saa5246a_device
 	u8     pgbuf[NUM_DAUS][VTX_VIRTUALSIZE];
 	int    is_searching[NUM_DAUS];
 	struct i2c_client *client;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 static struct video_device saa_template;	/* Declared near bottom */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/saa5249.c linux-2.6.15-rc5-mutex/drivers/media/video/saa5249.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/saa5249.c	2005-08-30 13:56:18.000000000 +0100
+++ linux-2.6.15-rc5-mutex/drivers/media/video/saa5249.c	2005-12-12 21:07:26.000000000 +0000
@@ -105,7 +105,7 @@ struct saa5249_device
 	int disp_mode;
 	int virtual_mode;
 	struct i2c_client *client;
-	struct semaphore lock;
+	struct mutex lock;
 };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/saa7134/saa7134.h linux-2.6.15-rc5-mutex/drivers/media/video/saa7134/saa7134.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/saa7134/saa7134.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/saa7134/saa7134.h	2005-12-12 21:06:33.000000000 +0000
@@ -358,7 +358,7 @@ struct saa7134_fh {
 
 /* dmasound dsp status */
 struct saa7134_dmasound {
-	struct semaphore           lock;
+	struct mutex               lock;
 	int                        minor_mixer;
 	int                        minor_dsp;
 	unsigned int               users_dsp;
@@ -422,7 +422,7 @@ struct saa7134_mpeg_ops {
 /* global device status */
 struct saa7134_dev {
 	struct list_head           devlist;
-	struct semaphore           lock;
+	struct mutex               lock;
 	spinlock_t                 slock;
 #ifdef VIDIOC_G_PRIORITY
 	struct v4l2_prio_state     prio;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/tvmixer.c linux-2.6.15-rc5-mutex/drivers/media/video/tvmixer.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/tvmixer.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/tvmixer.c	2005-12-12 22:12:50.000000000 +0000
@@ -16,8 +16,8 @@
 #include <linux/kdev_t.h>
 #include <linux/sound.h>
 #include <linux/soundcard.h>
+#include <linux/semaphore.h>
 
-#include <asm/semaphore.h>
 #include <asm/uaccess.h>
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/videodev.c linux-2.6.15-rc5-mutex/drivers/media/video/videodev.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/videodev.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/videodev.c	2005-12-12 22:12:50.000000000 +0000
@@ -29,7 +29,7 @@
 #include <linux/devfs_fs_kernel.h>
 #include <asm/uaccess.h>
 #include <asm/system.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #include <linux/videodev.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/vino.c linux-2.6.15-rc5-mutex/drivers/media/video/vino.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/vino.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/vino.c	2005-12-12 21:06:48.000000000 +0000
@@ -245,7 +245,7 @@ struct vino_framebuffer_queue {
 	struct vino_framebuffer *buffer[VINO_FRAMEBUFFER_COUNT_MAX];
 
 	spinlock_t queue_lock;
-	struct semaphore queue_sem;
+	struct mutex queue_sem;
 	wait_queue_head_t frame_wait_queue;
 };
 
@@ -283,7 +283,7 @@ struct vino_channel_settings {
 	/* the driver is currently processing the queue */
 	int capturing;
 
-	struct semaphore sem;
+	struct mutex sem;
 	spinlock_t capture_lock;
 
 	unsigned int users;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/zoran.h linux-2.6.15-rc5-mutex/drivers/media/video/zoran.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/media/video/zoran.h	2005-01-04 11:13:17.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/media/video/zoran.h	2005-12-12 21:07:22.000000000 +0000
@@ -395,7 +395,7 @@ struct zoran {
 	struct videocodec *codec;	/* video codec */
 	struct videocodec *vfe;	/* video front end */
 
-	struct semaphore resource_lock;	/* prevent evil stuff */
+	struct mutex resource_lock;	/* prevent evil stuff */
 
 	u8 initialized;		/* flag if zoran has been correctly initalized */
 	int user;		/* number of current users */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/message/fusion/mptbase.h linux-2.6.15-rc5-mutex/drivers/message/fusion/mptbase.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/message/fusion/mptbase.h	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/message/fusion/mptbase.h	2005-12-12 20:08:51.000000000 +0000
@@ -417,7 +417,7 @@ typedef struct _MPT_IOCTL {
 	u8			 status;	/* current command status */
 	u8			 reset;		/* 1 if bus reset allowed */
 	u8			 target;	/* target for reset */
-	struct semaphore	 sem_ioc;
+	struct mutex		sem_ioc;
 } MPT_IOCTL;
 
 #define MPT_SAS_MGMT_STATUS_RF_VALID	0x02	/* The Reply Frame is VALID */
@@ -425,7 +425,7 @@ typedef struct _MPT_IOCTL {
 #define MPT_SAS_MGMT_STATUS_TM_FAILED	0x40	/* User TM request failed */
 
 typedef struct _MPT_SAS_MGMT {
-	struct semaphore	 mutex;
+	struct mutex		 mutex;
 	struct completion	 done;
 	u8			 reply[MPT_DEFAULT_FRAME_SIZE]; /* reply frame data */
 	u8			 status;	/* current command status */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/message/fusion/mptctl.c linux-2.6.15-rc5-mutex/drivers/message/fusion/mptctl.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/message/fusion/mptctl.c	2005-12-08 16:23:41.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/message/fusion/mptctl.c	2005-12-12 20:24:32.000000000 +0000
@@ -2745,7 +2745,7 @@ mptctl_probe(struct pci_dev *pdev, const
 	memset(mem, 0, sz);
 	ioc->ioctl = (MPT_IOCTL *) mem;
 	ioc->ioctl->ioc = ioc;
-	sema_init(&ioc->ioctl->sem_ioc, 1);
+	init_MUTEX(&ioc->ioctl->sem_ioc);
 	return 0;
 
 out_fail:
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mfd/ucb1x00-core.c linux-2.6.15-rc5-mutex/drivers/mfd/ucb1x00-core.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mfd/ucb1x00-core.c	2005-11-01 13:19:09.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mfd/ucb1x00-core.c	2005-12-12 20:32:38.000000000 +0000
@@ -135,7 +135,7 @@ unsigned int ucb1x00_io_read(struct ucb1
  */
 void ucb1x00_adc_enable(struct ucb1x00 *ucb)
 {
-	down(&ucb->adc_sem);
+	down_sem(&ucb->adc_sem);
 
 	ucb->adc_cr |= UCB_ADC_ENA;
 
@@ -193,7 +193,7 @@ void ucb1x00_adc_disable(struct ucb1x00 
 	ucb1x00_reg_write(ucb, UCB_ADC_CR, ucb->adc_cr);
 	ucb1x00_disable(ucb);
 
-	up(&ucb->adc_sem);
+	up_sem(&ucb->adc_sem);
 }
 
 /*
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mfd/ucb1x00-ts.c linux-2.6.15-rc5-mutex/drivers/mfd/ucb1x00-ts.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mfd/ucb1x00-ts.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mfd/ucb1x00-ts.c	2005-12-12 22:12:50.000000000 +0000
@@ -35,7 +35,7 @@
 #include <linux/delay.h>
 
 #include <asm/dma.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/arch/collie.h>
 #include <asm/mach-types.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mmc/mmc_queue.h linux-2.6.15-rc5-mutex/drivers/mmc/mmc_queue.h
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mmc/mmc_queue.h	2005-01-04 11:13:17.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mmc/mmc_queue.h	2005-12-12 20:58:14.000000000 +0000
@@ -8,7 +8,7 @@ struct mmc_queue {
 	struct mmc_card		*card;
 	struct completion	thread_complete;
 	wait_queue_head_t	thread_wq;
-	struct semaphore	thread_sem;
+	struct mutex		thread_sem;
 	unsigned int		flags;
 	struct request		*req;
 	int			(*prep_fn)(struct mmc_queue *, struct request *);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/devices/blkmtd.c linux-2.6.15-rc5-mutex/drivers/mtd/devices/blkmtd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/devices/blkmtd.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mtd/devices/blkmtd.c	2005-12-12 21:19:07.000000000 +0000
@@ -46,7 +46,7 @@ struct blkmtd_dev {
 	struct list_head list;
 	struct block_device *blkdev;
 	struct mtd_info mtd_info;
-	struct semaphore wrbuf_mutex;
+	struct mutex wrbuf_mutex;
 };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/devices/block2mtd.c linux-2.6.15-rc5-mutex/drivers/mtd/devices/block2mtd.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/devices/block2mtd.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mtd/devices/block2mtd.c	2005-12-12 21:19:09.000000000 +0000
@@ -31,7 +31,7 @@ struct block2mtd_dev {
 	struct list_head list;
 	struct block_device *blkdev;
 	struct mtd_info mtd;
-	struct semaphore write_mutex;
+	struct mutex write_mutex;
 };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/mtd_blkdevs.c linux-2.6.15-rc5-mutex/drivers/mtd/mtd_blkdevs.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/mtd_blkdevs.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mtd/mtd_blkdevs.c	2005-12-12 22:08:48.000000000 +0000
@@ -19,12 +19,12 @@
 #include <linux/spinlock.h>
 #include <linux/hdreg.h>
 #include <linux/init.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 
 static LIST_HEAD(blktrans_majors);
 
-extern struct semaphore mtd_table_mutex;
+extern struct mutex mtd_table_mutex;
 extern struct mtd_info *mtd_table[];
 
 struct mtd_blkcore_priv {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/mtdblock.c linux-2.6.15-rc5-mutex/drivers/mtd/mtdblock.c
--- /warthog/kernels/linux-2.6.15-rc5/drivers/mtd/mtdblock.c	2005-12-08 16:23:42.000000000 +0000
+++ linux-2.6.15-rc5-mutex/drivers/mtd/mtdblock.c	2005-12-12 21:19:16.000000000 +0000
@@ -23,7 +23,7 @@
 static struct mtdblk_dev {
 	struct mtd_info *mtd;
 	int count;
-	struct semaphore cache_sem;
+	struct mutex cache_sem;
 	unsigned char *cache_data;
 	unsigned long cache_offset;
 	unsigned int cache_size;

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 18/19] MUTEX: Security changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (13 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 11/19] MUTEX: Drivers Q-S changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 17/19] MUTEX: Networking changes David Howells
                   ` (17 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the security files to use the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-security-2615rc5.diff
 security/selinux/hooks.c          |    2 +-
 security/selinux/selinuxfs.c      |    2 +-
 security/selinux/ss/conditional.c |    2 +-
 security/selinux/ss/services.c    |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/security/selinux/hooks.c linux-2.6.15-rc5-mutex/security/selinux/hooks.c
--- /warthog/kernels/linux-2.6.15-rc5/security/selinux/hooks.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/security/selinux/hooks.c	2005-12-12 22:12:50.000000000 +0000
@@ -50,7 +50,7 @@
 #include <net/ip.h>		/* for sysctl_local_port_range[] */
 #include <net/tcp.h>		/* struct or_callable used in sock_rcv_skb */
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/ioctls.h>
 #include <linux/bitops.h>
 #include <linux/interrupt.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/security/selinux/selinuxfs.c linux-2.6.15-rc5-mutex/security/selinux/selinuxfs.c
--- /warthog/kernels/linux-2.6.15-rc5/security/selinux/selinuxfs.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/security/selinux/selinuxfs.c	2005-12-12 22:12:50.000000000 +0000
@@ -22,7 +22,7 @@
 #include <linux/seq_file.h>
 #include <linux/percpu.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 /* selinuxfs pseudo filesystem for exporting the security policy API.
    Based on the proc code and the fs/nfsd/nfsctl.c code. */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/security/selinux/ss/conditional.c linux-2.6.15-rc5-mutex/security/selinux/ss/conditional.c
--- /warthog/kernels/linux-2.6.15-rc5/security/selinux/ss/conditional.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/security/selinux/ss/conditional.c	2005-12-12 22:12:50.000000000 +0000
@@ -11,7 +11,7 @@
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/spinlock.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/slab.h>
 
 #include "security.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/security/selinux/ss/services.c linux-2.6.15-rc5-mutex/security/selinux/ss/services.c
--- /warthog/kernels/linux-2.6.15-rc5/security/selinux/ss/services.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/security/selinux/ss/services.c	2005-12-12 22:12:50.000000000 +0000
@@ -27,7 +27,7 @@
 #include <linux/in.h>
 #include <linux/sched.h>
 #include <linux/audit.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include "flask.h"
 #include "avc.h"
 #include "avc_ss.h"

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 16/19] MUTEX: IPC changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (15 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 17/19] MUTEX: Networking changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 19/19] MUTEX: Sound changes David Howells
                   ` (15 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the IPC files to use the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-ipc-2615rc5.diff
 ipc/compat.c |    2 +-
 ipc/util.c   |    2 +-
 ipc/util.h   |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/ipc/compat.c linux-2.6.15-rc5-mutex/ipc/compat.c
--- /warthog/kernels/linux-2.6.15-rc5/ipc/compat.c	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/ipc/compat.c	2005-12-12 22:12:50.000000000 +0000
@@ -29,8 +29,8 @@
 #include <linux/shm.h>
 #include <linux/slab.h>
 #include <linux/syscalls.h>
+#include <linux/semaphore.h>
 
-#include <asm/semaphore.h>
 #include <asm/uaccess.h>
 
 #include "util.h"
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/ipc/util.c linux-2.6.15-rc5-mutex/ipc/util.c
--- /warthog/kernels/linux-2.6.15-rc5/ipc/util.c	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/ipc/util.c	2005-12-12 17:40:08.000000000 +0000
@@ -67,7 +67,7 @@ __initcall(ipc_init);
 void __init ipc_init_ids(struct ipc_ids* ids, int size)
 {
 	int i;
-	sema_init(&ids->sem,1);
+	init_MUTEX(&ids->sem);
 
 	if(size > IPCMNI)
 		size = IPCMNI;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/ipc/util.h linux-2.6.15-rc5-mutex/ipc/util.h
--- /warthog/kernels/linux-2.6.15-rc5/ipc/util.h	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/ipc/util.h	2005-12-12 17:39:49.000000000 +0000
@@ -25,7 +25,7 @@ struct ipc_ids {
 	int max_id;
 	unsigned short seq;
 	unsigned short seq_max;
-	struct semaphore sem;	
+	struct mutex sem;	
 	struct ipc_id_ary nullentry;
 	struct ipc_id_ary* entries;
 };

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 17/19] MUTEX: Networking changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (14 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 18/19] MUTEX: Security changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-12 23:45 ` [PATCH 16/19] MUTEX: IPC changes David Howells
                   ` (16 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the networking files to use the new mutex
functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-net-2615rc5.diff
 net/atm/resources.h             |    2 +-
 net/bridge/netfilter/ebtables.c |   12 ++++++------
 net/core/flow.c                 |    2 +-
 net/dccp/proto.c                |    2 +-
 net/ipv4/ipcomp.c               |    2 +-
 net/ipv4/netfilter/arp_tables.c |    2 +-
 net/ipv4/netfilter/ip_tables.c  |    2 +-
 net/ipv6/ipcomp6.c              |    2 +-
 net/ipv6/netfilter/ip6_tables.c |    2 +-
 net/sunrpc/sched.c              |    2 --
 net/sunrpc/svcsock.c            |    2 +-
 11 files changed, 15 insertions(+), 17 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/atm/resources.h linux-2.6.15-rc5-mutex/net/atm/resources.h
--- /warthog/kernels/linux-2.6.15-rc5/net/atm/resources.h	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/atm/resources.h	2005-12-12 20:45:35.000000000 +0000
@@ -11,7 +11,7 @@
 
 
 extern struct list_head atm_devs;
-extern struct semaphore atm_dev_mutex;
+extern struct mutex atm_dev_mutex;
 
 int atm_dev_ioctl(unsigned int cmd, void __user *arg);
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/bridge/netfilter/ebtables.c linux-2.6.15-rc5-mutex/net/bridge/netfilter/ebtables.c
--- /warthog/kernels/linux-2.6.15-rc5/net/bridge/netfilter/ebtables.c	2005-11-01 13:19:23.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/bridge/netfilter/ebtables.c	2005-12-12 20:46:34.000000000 +0000
@@ -296,7 +296,7 @@ letscontinue:
 /* If it succeeds, returns element and locks mutex */
 static inline void *
 find_inlist_lock_noload(struct list_head *head, const char *name, int *error,
-   struct semaphore *mutex)
+   struct mutx *mutex)
 {
 	void *ret;
 
@@ -317,7 +317,7 @@ find_inlist_lock_noload(struct list_head
 #else
 static void *
 find_inlist_lock(struct list_head *head, const char *name, const char *prefix,
-   int *error, struct semaphore *mutex)
+   int *error, struct mutex *mutex)
 {
 	void *ret;
 
@@ -331,25 +331,25 @@ find_inlist_lock(struct list_head *head,
 #endif
 
 static inline struct ebt_table *
-find_table_lock(const char *name, int *error, struct semaphore *mutex)
+find_table_lock(const char *name, int *error, struct mutex *mutex)
 {
 	return find_inlist_lock(&ebt_tables, name, "ebtable_", error, mutex);
 }
 
 static inline struct ebt_match *
-find_match_lock(const char *name, int *error, struct semaphore *mutex)
+find_match_lock(const char *name, int *error, struct mutex *mutex)
 {
 	return find_inlist_lock(&ebt_matches, name, "ebt_", error, mutex);
 }
 
 static inline struct ebt_watcher *
-find_watcher_lock(const char *name, int *error, struct semaphore *mutex)
+find_watcher_lock(const char *name, int *error, struct mutex *mutex)
 {
 	return find_inlist_lock(&ebt_watchers, name, "ebt_", error, mutex);
 }
 
 static inline struct ebt_target *
-find_target_lock(const char *name, int *error, struct semaphore *mutex)
+find_target_lock(const char *name, int *error, struct mutex *mutex)
 {
 	return find_inlist_lock(&ebt_targets, name, "ebt_", error, mutex);
 }
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/core/flow.c linux-2.6.15-rc5-mutex/net/core/flow.c
--- /warthog/kernels/linux-2.6.15-rc5/net/core/flow.c	2005-11-01 13:19:23.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/core/flow.c	2005-12-12 22:12:50.000000000 +0000
@@ -20,9 +20,9 @@
 #include <linux/notifier.h>
 #include <linux/cpu.h>
 #include <linux/cpumask.h>
+#include <linux/semaphore.h>
 #include <net/flow.h>
 #include <asm/atomic.h>
-#include <asm/semaphore.h>
 
 struct flow_cache_entry {
 	struct flow_cache_entry	*next;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/dccp/proto.c linux-2.6.15-rc5-mutex/net/dccp/proto.c
--- /warthog/kernels/linux-2.6.15-rc5/net/dccp/proto.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/dccp/proto.c	2005-12-12 22:12:50.000000000 +0000
@@ -29,7 +29,7 @@
 #include <net/sock.h>
 #include <net/xfrm.h>
 
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/spinlock.h>
 #include <linux/timer.h>
 #include <linux/delay.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/ipv4/ipcomp.c linux-2.6.15-rc5-mutex/net/ipv4/ipcomp.c
--- /warthog/kernels/linux-2.6.15-rc5/net/ipv4/ipcomp.c	2005-11-01 13:19:24.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/ipv4/ipcomp.c	2005-12-12 22:12:50.000000000 +0000
@@ -16,7 +16,7 @@
 #include <linux/config.h>
 #include <linux/module.h>
 #include <asm/scatterlist.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/crypto.h>
 #include <linux/pfkeyv2.h>
 #include <linux/percpu.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/ipv4/netfilter/arp_tables.c linux-2.6.15-rc5-mutex/net/ipv4/netfilter/arp_tables.c
--- /warthog/kernels/linux-2.6.15-rc5/net/ipv4/netfilter/arp_tables.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/ipv4/netfilter/arp_tables.c	2005-12-12 22:12:50.000000000 +0000
@@ -19,9 +19,9 @@
 #include <linux/proc_fs.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/semaphore.h>
 
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
 
 #include <linux/netfilter_arp/arp_tables.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/ipv4/netfilter/ip_tables.c linux-2.6.15-rc5-mutex/net/ipv4/netfilter/ip_tables.c
--- /warthog/kernels/linux-2.6.15-rc5/net/ipv4/netfilter/ip_tables.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/ipv4/netfilter/ip_tables.c	2005-12-12 22:12:50.000000000 +0000
@@ -24,7 +24,7 @@
 #include <linux/icmp.h>
 #include <net/ip.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/proc_fs.h>
 #include <linux/err.h>
 #include <linux/cpumask.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/ipv6/ipcomp6.c linux-2.6.15-rc5-mutex/net/ipv6/ipcomp6.c
--- /warthog/kernels/linux-2.6.15-rc5/net/ipv6/ipcomp6.c	2005-12-08 16:23:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/ipv6/ipcomp6.c	2005-12-12 22:12:50.000000000 +0000
@@ -36,7 +36,7 @@
 #include <net/xfrm.h>
 #include <net/ipcomp.h>
 #include <asm/scatterlist.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/crypto.h>
 #include <linux/pfkeyv2.h>
 #include <linux/random.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/ipv6/netfilter/ip6_tables.c linux-2.6.15-rc5-mutex/net/ipv6/netfilter/ip6_tables.c
--- /warthog/kernels/linux-2.6.15-rc5/net/ipv6/netfilter/ip6_tables.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/ipv6/netfilter/ip6_tables.c	2005-12-12 22:12:50.000000000 +0000
@@ -25,7 +25,7 @@
 #include <linux/icmpv6.h>
 #include <net/ipv6.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <linux/proc_fs.h>
 #include <linux/cpumask.h>
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/sunrpc/sched.c linux-2.6.15-rc5-mutex/net/sunrpc/sched.c
--- /warthog/kernels/linux-2.6.15-rc5/net/sunrpc/sched.c	2005-11-01 13:19:26.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/sunrpc/sched.c	2005-12-12 17:57:01.000000000 +0000
@@ -971,8 +971,6 @@ void rpc_killall_tasks(struct rpc_clnt *
 	spin_unlock(&rpc_sched_lock);
 }
 
-static DECLARE_MUTEX_LOCKED(rpciod_running);
-
 static void rpciod_killall(void)
 {
 	unsigned long flags;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/net/sunrpc/svcsock.c linux-2.6.15-rc5-mutex/net/sunrpc/svcsock.c
--- /warthog/kernels/linux-2.6.15-rc5/net/sunrpc/svcsock.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/net/sunrpc/svcsock.c	2005-12-12 17:58:56.000000000 +0000
@@ -1351,7 +1351,7 @@ svc_setup_socket(struct svc_serv *serv, 
 	svsk->sk_lastrecv = get_seconds();
 	INIT_LIST_HEAD(&svsk->sk_deferred);
 	INIT_LIST_HEAD(&svsk->sk_ready);
-	sema_init(&svsk->sk_sem, 1);
+	init_MUTEX(&svsk->sk_sem);
 
 	/* Initialize the socket */
 	if (sock->type == SOCK_DGRAM)

^ permalink raw reply	[flat|nested] 249+ messages in thread

* [PATCH 19/19] MUTEX: Sound changes
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (16 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 16/19] MUTEX: IPC changes David Howells
@ 2005-12-12 23:45 ` David Howells
  2005-12-13  0:13 ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Nick Piggin
                   ` (14 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-12 23:45 UTC (permalink / raw)
  To: torvalds, akpm, hch, arjan, matthew; +Cc: linux-kernel, linux-arch

The attached patch modifies the sound files to use the new mutex functions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 mutex-sound-2615rc5.diff
 include/sound/ac97_codec.h          |    4 ++--
 include/sound/ad1848.h              |    2 +-
 include/sound/ak4531_codec.h        |    2 +-
 include/sound/core.h                |    4 ++--
 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                 |    2 +-
 include/sound/info.h                |    2 +-
 include/sound/mixer_oss.h           |    2 +-
 include/sound/opl3.h                |    2 +-
 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            |    2 +-
 include/sound/vx_core.h             |    2 +-
 sound/arm/aaci.h                    |    2 +-
 sound/arm/pxa2xx-ac97.c             |    2 +-
 sound/arm/sa11xx-uda1341.c          |    2 +-
 sound/core/memalloc.c               |    2 +-
 sound/core/seq/seq_clientmgr.h      |    2 +-
 sound/core/seq/seq_device.c         |    2 +-
 sound/core/seq/seq_midi.c           |    2 +-
 sound/core/seq/seq_queue.h          |    2 +-
 sound/core/timer.c                  |    2 +-
 sound/drivers/opl4/opl4_local.h     |    2 +-
 sound/oss/ac97_codec.c              |    2 +-
 sound/oss/aci.c                     |    4 ++--
 sound/oss/ad1889.h                  |    2 +-
 sound/oss/ali5455.c                 |    2 +-
 sound/oss/au1000.c                  |    4 ++--
 sound/oss/au1550_ac97.c             |    4 ++--
 sound/oss/btaudio.c                 |    2 +-
 sound/oss/cmpci.c                   |    2 +-
 sound/oss/cs4281/cs4281m.c          |    6 +++---
 sound/oss/cs46xx.c                  |    6 +++---
 sound/oss/dmasound/dmasound_awacs.c |    2 +-
 sound/oss/emu10k1/hwaccess.h        |    2 +-
 sound/oss/es1370.c                  |    4 ++--
 sound/oss/es1371.c                  |    4 ++--
 sound/oss/esssolo1.c                |    2 +-
 sound/oss/forte.c                   |    2 +-
 sound/oss/hal2.c                    |    2 +-
 sound/oss/i810_audio.c              |    2 +-
 sound/oss/ite8172.c                 |    2 +-
 sound/oss/maestro.c                 |    2 +-
 sound/oss/maestro3.c                |    2 +-
 sound/oss/nec_vrc5477.c             |    2 +-
 sound/oss/rme96xx.c                 |    2 +-
 sound/oss/sonicvibes.c              |    2 +-
 sound/oss/swarm_cs4297a.c           |    6 +++---
 sound/oss/trident.c                 |    4 ++--
 sound/oss/via82cxxx_audio.c         |    6 +++---
 sound/oss/vwsnd.c                   |    8 ++++----
 sound/oss/ymfpci.h                  |    2 +-
 sound/pci/atiixp.c                  |    2 +-
 sound/pci/atiixp_modem.c            |    2 +-
 sound/pci/cmipci.c                  |    2 +-
 sound/pci/ens1370.c                 |    2 +-
 sound/pci/es1968.c                  |    2 +-
 sound/pci/hda/hda_codec.h           |    4 ++--
 sound/pci/hda/hda_intel.c           |    2 +-
 sound/pci/hda/patch_analog.c        |    2 +-
 sound/pci/ice1712/ice1712.h         |    6 +++---
 sound/pci/korg1212/korg1212.c       |    2 +-
 sound/pci/mixart/mixart.h           |    6 +++---
 sound/pci/nm256/nm256.c             |    2 +-
 sound/sparc/cs4231.c                |    4 ++--
 sound/usb/usx2y/usbusx2y.h          |    2 +-
 75 files changed, 105 insertions(+), 105 deletions(-)

diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/ac97_codec.h linux-2.6.15-rc5-mutex/include/sound/ac97_codec.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/ac97_codec.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/ac97_codec.h	2005-12-12 19:38:31.000000000 +0000
@@ -486,8 +486,8 @@ struct _snd_ac97 {
 	snd_info_entry_t *proc_regs;
 	unsigned short subsystem_vendor;
 	unsigned short subsystem_device;
-	struct semaphore reg_mutex;
-	struct semaphore page_mutex;	/* mutex for AD18xx multi-codecs and paging (2.3) */
+	struct mutex reg_mutex;
+	struct mutex page_mutex; /* mutex for AD18xx multi-codecs and paging (2.3) */
 	unsigned short num;	/* number of codec: 0 = primary, 1 = secondary */
 	unsigned short addr;	/* physical address of codec [0-3] */
 	unsigned int id;	/* identification of codec */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/ad1848.h linux-2.6.15-rc5-mutex/include/sound/ad1848.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/ad1848.h	2005-03-02 12:09:01.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/ad1848.h	2005-12-12 19:41:15.000000000 +0000
@@ -149,7 +149,7 @@ struct _snd_ad1848 {
 	int thinkpad_flag;		/* Thinkpad CS4248 needs some extra help */
 
 	spinlock_t reg_lock;
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 };
 
 typedef struct _snd_ad1848 ad1848_t;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/ak4531_codec.h linux-2.6.15-rc5-mutex/include/sound/ak4531_codec.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/ak4531_codec.h	2005-03-02 12:09:01.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/ak4531_codec.h	2005-12-12 19:39:14.000000000 +0000
@@ -72,7 +72,7 @@ struct _snd_ak4531 {
 	void (*private_free) (ak4531_t *ak4531);
 	/* --- */
 	unsigned char regs[0x20];
-	struct semaphore reg_mutex;
+	struct mutex reg_mutex;
 };
 
 int snd_ak4531_mixer(snd_card_t * card, ak4531_t * _ak4531, ak4531_t ** rak4531);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/core.h linux-2.6.15-rc5-mutex/include/sound/core.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/core.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/core.h	2005-12-12 22:12:49.000000000 +0000
@@ -23,7 +23,7 @@
  */
 
 #include <linux/sched.h>		/* wake_up() */
-#include <asm/semaphore.h>		/* struct semaphore */
+#include <linux/semaphore.h>		/* struct mutex */
 #include <linux/rwsem.h>		/* struct rw_semaphore */
 #include <linux/workqueue.h>		/* struct workqueue_struct */
 #include <linux/pm.h>			/* pm_message_t */
@@ -176,7 +176,7 @@ struct _snd_card {
 	int (*pm_resume)(snd_card_t *card);
 	void *pm_private_data;
 	unsigned int power_state;	/* power state */
-	struct semaphore power_lock;	/* power lock */
+	struct mutex power_lock;	/* power lock */
 	wait_queue_head_t power_sleep;
 #endif
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/cs4231.h linux-2.6.15-rc5-mutex/include/sound/cs4231.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/cs4231.h	2005-03-02 12:09:01.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/cs4231.h	2005-12-12 19:38:41.000000000 +0000
@@ -287,8 +287,8 @@ struct _snd_cs4231 {
 #endif
 
 	spinlock_t reg_lock;
-	struct semaphore mce_mutex;
-	struct semaphore open_mutex;
+	struct mutex mce_mutex;
+	struct mutex open_mutex;
 
 	int (*rate_constraint) (snd_pcm_runtime_t *runtime);
 	void (*set_playback_format) (cs4231_t *chip, snd_pcm_hw_params_t *hw_params, unsigned char pdfr);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/cs46xx.h linux-2.6.15-rc5-mutex/include/sound/cs46xx.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/cs46xx.h	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/cs46xx.h	2005-12-12 19:41:15.000000000 +0000
@@ -1712,7 +1712,7 @@ struct _snd_cs46xx {
 	int current_gpio;
 #endif
 #ifdef CONFIG_SND_CS46XX_NEW_DSP
-	struct semaphore spos_mutex;
+	struct mutex spos_mutex;
 
 	dsp_spos_instance_t * dsp_spos_instance;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/emu10k1.h linux-2.6.15-rc5-mutex/include/sound/emu10k1.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/emu10k1.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/emu10k1.h	2005-12-12 19:41:15.000000000 +0000
@@ -1024,7 +1024,7 @@ typedef struct {
 	int gpr_size;			/* size of allocated GPR controls */
 	int gpr_count;			/* count of used kcontrols */
 	struct list_head gpr_ctl;	/* GPR controls */
-	struct semaphore lock;
+	struct mutex lock;
 	snd_emu10k1_fx8010_pcm_t pcm[8];
 	spinlock_t irq_lock;
 	snd_emu10k1_fx8010_irq_t *irq_handlers;
@@ -1118,7 +1118,7 @@ struct _snd_emu10k1 {
 	spinlock_t reg_lock;
 	spinlock_t emu_lock;
 	spinlock_t voice_lock;
-	struct semaphore ptb_lock;
+	struct mutex ptb_lock;
 
 	emu10k1_voice_t voices[NUM_G];
 	emu10k1_voice_t p16v_voices[4];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/emux_synth.h linux-2.6.15-rc5-mutex/include/sound/emux_synth.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/emux_synth.h	2004-06-18 13:44:05.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/emux_synth.h	2005-12-12 19:41:15.000000000 +0000
@@ -112,7 +112,7 @@ struct snd_emux {
 	snd_emux_voice_t *voices;	/* Voices (EMU 'channel') */
 	int use_time;	/* allocation counter */
 	spinlock_t voice_lock;	/* Lock for voice access */
-	struct semaphore register_mutex;
+	struct mutex register_mutex;
 	int client;		/* For the sequencer client */
 	int ports[SNDRV_EMUX_MAX_PORTS];	/* The ports for this device */
 	snd_emux_port_t *portptrs[SNDRV_EMUX_MAX_PORTS];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/gus.h linux-2.6.15-rc5-mutex/include/sound/gus.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/gus.h	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/gus.h	2005-12-12 19:39:26.000000000 +0000
@@ -210,7 +210,7 @@ typedef struct _snd_gf1_mem {
 	snd_gf1_bank_info_t banks_16[4];
 	snd_gf1_mem_block_t *first;
 	snd_gf1_mem_block_t *last;
-	struct semaphore memory_mutex;
+	struct mutex memory_mutex;
 } snd_gf1_mem_t;
 
 typedef struct snd_gf1_dma_block {
@@ -468,8 +468,8 @@ struct _snd_gus_card {
 	spinlock_t dma_lock;
 	spinlock_t pcm_volume_level_lock;
 	spinlock_t uart_cmd_lock;
-	struct semaphore dma_mutex;
-	struct semaphore register_mutex;
+	struct mutex dma_mutex;
+	struct mutex register_mutex;
 };
 
 /* I/O functions for GF1/InterWave chip - gus_io.c */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/hwdep.h linux-2.6.15-rc5-mutex/include/sound/hwdep.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/hwdep.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/hwdep.h	2005-12-12 19:38:54.000000000 +0000
@@ -62,7 +62,7 @@ struct _snd_hwdep {
 	void *private_data;
 	void (*private_free) (snd_hwdep_t *hwdep);
 
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 	int used;
 	unsigned int dsp_loaded;
 	unsigned int exclusive: 1;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/i2c.h linux-2.6.15-rc5-mutex/include/sound/i2c.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/i2c.h	2004-06-18 13:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/i2c.h	2005-12-12 19:39:11.000000000 +0000
@@ -58,7 +58,7 @@ struct _snd_i2c_bus {
 	snd_card_t *card;	/* card which I2C belongs to */
 	char name[32];		/* some useful label */
 
-	struct semaphore lock_mutex;
+	struct mutex lock_mutex;
 
 	snd_i2c_bus_t *master;	/* master bus when SCK/SCL is shared */
 	struct list_head buses;	/* master: slave buses sharing SCK/SCL, slave: link list */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/info.h linux-2.6.15-rc5-mutex/include/sound/info.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/info.h	2005-03-02 12:09:01.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/info.h	2005-12-12 19:38:46.000000000 +0000
@@ -86,7 +86,7 @@ struct snd_info_entry {
 	void *private_data;
 	void (*private_free)(snd_info_entry_t *entry);
 	struct proc_dir_entry *p;
-	struct semaphore access;
+	struct mutex access;
 };
 
 extern int snd_info_check_reserved_words(const char *str);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/mixer_oss.h linux-2.6.15-rc5-mutex/include/sound/mixer_oss.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/mixer_oss.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/mixer_oss.h	2005-12-12 19:39:05.000000000 +0000
@@ -59,7 +59,7 @@ struct _snd_oss_mixer {
 	snd_mixer_oss_put_recsrce_t put_recsrc;
 	void *private_data_recsrc;
 	void (*private_free_recsrc)(snd_mixer_oss_t *mixer);
-	struct semaphore reg_mutex;
+	struct mutex reg_mutex;
 	snd_info_entry_t *proc_entry;
 	int oss_dev_alloc;
 	/* --- */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/opl3.h linux-2.6.15-rc5-mutex/include/sound/opl3.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/opl3.h	2005-01-04 11:13:56.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/opl3.h	2005-12-12 19:38:35.000000000 +0000
@@ -312,7 +312,7 @@ struct snd_opl3 {
 	int sys_timer_status;		/* system timer run status */
 	spinlock_t sys_timer_lock;	/* Lock for system timer access */
 #endif
-	struct semaphore access_mutex;	/* locking */
+	struct mutex access_mutex;	/* locking */
 };
 
 /* opl3.c */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/pcm.h linux-2.6.15-rc5-mutex/include/sound/pcm.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/pcm.h	2005-12-08 16:23:55.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/pcm.h	2005-12-12 19:38:51.000000000 +0000
@@ -445,7 +445,7 @@ struct _snd_pcm {
 	char id[64];
 	char name[80];
 	snd_pcm_str_t streams[2];
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 	wait_queue_head_t open_wait;
 	void *private_data;
 	void (*private_free) (snd_pcm_t *pcm);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/pcm_oss.h linux-2.6.15-rc5-mutex/include/sound/pcm_oss.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/pcm_oss.h	2005-11-01 13:19:22.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/pcm_oss.h	2005-12-12 19:37:46.000000000 +0000
@@ -76,7 +76,7 @@ typedef struct _snd_pcm_oss_substream {
 
 typedef struct _snd_pcm_oss_stream {
 	snd_pcm_oss_setup_t *setup_list;	/* setup list */
-        struct semaphore setup_mutex;
+        struct mutex setup_mutex;
 	snd_info_entry_t *proc_entry;
 } snd_pcm_oss_stream_t;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/rawmidi.h linux-2.6.15-rc5-mutex/include/sound/rawmidi.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/rawmidi.h	2005-06-22 13:52:33.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/rawmidi.h	2005-12-12 22:12:49.000000000 +0000
@@ -26,7 +26,7 @@
 #include <linux/interrupt.h>
 #include <linux/spinlock.h>
 #include <linux/wait.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 
 #if defined(CONFIG_SND_SEQUENCER) || defined(CONFIG_SND_SEQUENCER_MODULE)
 #include "seq_device.h"
@@ -136,7 +136,7 @@ struct _snd_rawmidi {
 	void *private_data;
 	void (*private_free) (snd_rawmidi_t *rmidi);
 
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 	wait_queue_head_t open_wait;
 
 	snd_info_entry_t *dev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/sb16_csp.h linux-2.6.15-rc5-mutex/include/sound/sb16_csp.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/sb16_csp.h	2004-06-18 13:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/sb16_csp.h	2005-12-12 19:41:15.000000000 +0000
@@ -158,7 +158,7 @@ struct snd_sb_csp {
 	snd_kcontrol_t *qsound_switch;
 	snd_kcontrol_t *qsound_space;
 
-	struct semaphore access_mutex;	/* locking */
+	struct mutex access_mutex;	/* locking */
 };
 
 int snd_sb_csp_new(sb_t *chip, int device, snd_hwdep_t ** rhwdep);
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/seq_instr.h linux-2.6.15-rc5-mutex/include/sound/seq_instr.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/seq_instr.h	2004-06-18 13:44:06.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/seq_instr.h	2005-12-12 19:39:20.000000000 +0000
@@ -66,7 +66,7 @@ typedef struct {
 
 	spinlock_t lock;
 	spinlock_t ops_lock;
-	struct semaphore ops_mutex;
+	struct mutex ops_mutex;
 	unsigned long ops_flags;
 } snd_seq_kinstr_list_t;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/soundfont.h linux-2.6.15-rc5-mutex/include/sound/soundfont.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/soundfont.h	2005-03-02 12:09:01.000000000 +0000
+++ linux-2.6.15-rc5-mutex/include/sound/soundfont.h	2005-12-12 19:41:15.000000000 +0000
@@ -96,7 +96,7 @@ typedef struct snd_sf_list {
 	int sample_locked;	/* locked time for sample */
 	snd_sf_callback_t callback;	/* callback functions */
 	int presets_locked;
-	struct semaphore presets_mutex;
+	struct mutex presets_mutex;
 	spinlock_t lock;
 	snd_util_memhdr_t *memhdr;
 } snd_sf_list_t;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/util_mem.h linux-2.6.15-rc5-mutex/include/sound/util_mem.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/util_mem.h	2004-06-18 13:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/util_mem.h	2005-12-12 19:38:48.000000000 +0000
@@ -44,7 +44,7 @@ struct snd_util_memhdr {
 	int nblocks;			/* # of allocated blocks */
 	snd_util_unit_t used;		/* used memory size */
 	int block_extra_size;		/* extra data size of chunk */
-	struct semaphore block_mutex;	/* lock */
+	struct mutex block_mutex;	/* lock */
 };
 
 /*
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/include/sound/vx_core.h linux-2.6.15-rc5-mutex/include/sound/vx_core.h
--- /warthog/kernels/linux-2.6.15-rc5/include/sound/vx_core.h	2005-08-30 13:56:38.000000000 +0100
+++ linux-2.6.15-rc5-mutex/include/sound/vx_core.h	2005-12-12 19:41:15.000000000 +0000
@@ -207,7 +207,7 @@ struct snd_vx_core {
 	int audio_monitor[4];			/* playback hw-monitor level */
 	unsigned char audio_monitor_active[4];	/* playback hw-monitor mute/unmute */
 
-	struct semaphore mixer_mutex;
+	struct mutex mixer_mutex;
 
 	const struct firmware *firmware[4]; /* loaded firmware data */
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/arm/aaci.h linux-2.6.15-rc5-mutex/sound/arm/aaci.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/arm/aaci.h	2005-11-01 13:19:26.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/arm/aaci.h	2005-12-12 20:40:39.000000000 +0000
@@ -227,7 +227,7 @@ struct aaci {
 	unsigned int		fifosize;
 
 	/* AC'97 */
-	struct semaphore	ac97_sem;
+	struct mutex		ac97_sem;
 	ac97_bus_t		*ac97_bus;
 
 	u32			maincr;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/arm/pxa2xx-ac97.c linux-2.6.15-rc5-mutex/sound/arm/pxa2xx-ac97.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/arm/pxa2xx-ac97.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/arm/pxa2xx-ac97.c	2005-12-12 22:12:50.000000000 +0000
@@ -17,6 +17,7 @@
 #include <linux/interrupt.h>
 #include <linux/wait.h>
 #include <linux/delay.h>
+#include <linux/semaphore.h>
 
 #include <sound/driver.h>
 #include <sound/core.h>
@@ -25,7 +26,6 @@
 #include <sound/initval.h>
 
 #include <asm/irq.h>
-#include <asm/semaphore.h>
 #include <asm/hardware.h>
 #include <asm/arch/pxa-regs.h>
 #include <asm/arch/audio.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/arm/sa11xx-uda1341.c linux-2.6.15-rc5-mutex/sound/arm/sa11xx-uda1341.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/arm/sa11xx-uda1341.c	2005-11-01 13:19:27.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/arm/sa11xx-uda1341.c	2005-12-12 22:12:50.000000000 +0000
@@ -79,7 +79,7 @@
 #include <asm/dma.h>
 
 #ifdef CONFIG_H3600_HAL
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
 #include <asm/arch/h3600_hal.h>
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/core/memalloc.c linux-2.6.15-rc5-mutex/sound/core/memalloc.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/core/memalloc.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/core/memalloc.c	2005-12-12 22:12:50.000000000 +0000
@@ -31,7 +31,7 @@
 #include <asm/uaccess.h>
 #include <linux/dma-mapping.h>
 #include <linux/moduleparam.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <sound/memalloc.h>
 #ifdef CONFIG_SBUS
 #include <asm/sbus.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_clientmgr.h linux-2.6.15-rc5-mutex/sound/core/seq/seq_clientmgr.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_clientmgr.h	2005-03-02 12:09:12.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/core/seq/seq_clientmgr.h	2005-12-12 20:41:17.000000000 +0000
@@ -61,7 +61,7 @@ struct _snd_seq_client {
 	int num_ports;		/* number of ports */
 	struct list_head ports_list_head;
 	rwlock_t ports_lock;
-	struct semaphore ports_mutex;
+	struct mutex ports_mutex;
 	int convert32;		/* convert 32->64bit */
 
 	/* output pool */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_device.c linux-2.6.15-rc5-mutex/sound/core/seq/seq_device.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_device.c	2005-11-01 13:19:27.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/core/seq/seq_device.c	2005-12-12 20:41:14.000000000 +0000
@@ -74,7 +74,7 @@ struct ops_list {
 	struct list_head dev_list;	/* list of devices */
 	int num_devices;	/* number of associated devices */
 	int num_init_devices;	/* number of initialized devices */
-	struct semaphore reg_mutex;
+	struct mutex reg_mutex;
 
 	struct list_head list;	/* next driver */
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_midi.c linux-2.6.15-rc5-mutex/sound/core/seq/seq_midi.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_midi.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/core/seq/seq_midi.c	2005-12-12 22:12:50.000000000 +0000
@@ -32,7 +32,7 @@ Possible options for midisynth module:
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/moduleparam.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <sound/core.h>
 #include <sound/rawmidi.h>
 #include <sound/seq_kernel.h>
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_queue.h linux-2.6.15-rc5-mutex/sound/core/seq/seq_queue.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/core/seq/seq_queue.h	2005-08-30 13:56:45.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/core/seq/seq_queue.h	2005-12-12 20:41:11.000000000 +0000
@@ -54,7 +54,7 @@ struct _snd_seq_queue {
 	/* clients which uses this queue (bitmap) */
 	DECLARE_BITMAP(clients_bitmap, SNDRV_SEQ_MAX_CLIENTS);
 	unsigned int clients;	/* users of this queue */
-	struct semaphore timer_mutex;
+	struct mutex timer_mutex;
 
 	snd_use_lock_t use_lock;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/core/timer.c linux-2.6.15-rc5-mutex/sound/core/timer.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/core/timer.c	2005-12-08 16:23:57.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/core/timer.c	2005-12-12 20:41:08.000000000 +0000
@@ -70,7 +70,7 @@ typedef struct {
 	struct timespec tstamp;		/* trigger tstamp */
 	wait_queue_head_t qchange_sleep;
 	struct fasync_struct *fasync;
-	struct semaphore tread_sem;
+	struct mutex tread_sem;
 } snd_timer_user_t;
 
 /* list of timers */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/drivers/opl4/opl4_local.h linux-2.6.15-rc5-mutex/sound/drivers/opl4/opl4_local.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/drivers/opl4/opl4_local.h	2004-10-19 10:42:23.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/drivers/opl4/opl4_local.h	2005-12-12 20:45:26.000000000 +0000
@@ -182,7 +182,7 @@ struct opl4 {
 	snd_info_entry_t *proc_entry;
 	int memory_access;
 #endif
-	struct semaphore access_mutex;
+	struct mutex access_mutex;
 
 #if defined(CONFIG_SND_SEQUENCER) || defined(CONFIG_SND_SEQUENCER_MODULE)
 	int used;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/ac97_codec.c linux-2.6.15-rc5-mutex/sound/oss/ac97_codec.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/ac97_codec.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/ac97_codec.c	2005-12-12 22:12:50.000000000 +0000
@@ -54,8 +54,8 @@
 #include <linux/delay.h>
 #include <linux/pci.h>
 #include <linux/ac97_codec.h>
+#include <linux/semaphore.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
 
 #define CODEC_ID_BUFSZ 14
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/aci.c linux-2.6.15-rc5-mutex/sound/oss/aci.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/aci.c	2005-03-02 12:09:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/aci.c	2005-12-12 22:12:50.000000000 +0000
@@ -56,7 +56,7 @@
 #include <linux/module.h> 
 #include <linux/proc_fs.h>
 #include <linux/slab.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
 #include "sound_config.h"
@@ -79,7 +79,7 @@ static int aci_micpreamp=3; /* microphon
 			 * checked with ACI versions prior to 0xb0	*/
 
 static int mixer_device;
-static struct semaphore aci_sem;
+static struct mutex aci_sem;
 
 #ifdef MODULE
 static int reset;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/ad1889.h linux-2.6.15-rc5-mutex/sound/oss/ad1889.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/ad1889.h	2005-01-04 11:14:02.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/ad1889.h	2005-12-12 20:41:45.000000000 +0000
@@ -100,7 +100,7 @@ typedef struct ad1889_state {
 		unsigned int subdivision;
 	} dmabuf;
 
-	struct semaphore sem;
+	struct mutex sem;
 } ad1889_state_t;
 
 typedef struct ad1889_dev {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/ali5455.c linux-2.6.15-rc5-mutex/sound/oss/ali5455.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/ali5455.c	2005-06-22 13:52:38.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/ali5455.c	2005-12-12 20:43:28.000000000 +0000
@@ -234,7 +234,7 @@ struct ali_state {
 	struct ali_card *card;	/* Card info */
 
 	/* single open lock mechanism, only used for recording */
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	wait_queue_head_t open_wait;
 
 	/* file mode */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/au1000.c linux-2.6.15-rc5-mutex/sound/oss/au1000.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/au1000.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/au1000.c	2005-12-12 20:43:55.000000000 +0000
@@ -120,8 +120,8 @@ struct au1000_state {
 	int             no_vra;	// do not use VRA
 
 	spinlock_t      lock;
-	struct semaphore open_sem;
-	struct semaphore sem;
+	struct mutex open_sem;
+	struct mutex sem;
 	mode_t          open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/au1550_ac97.c linux-2.6.15-rc5-mutex/sound/oss/au1550_ac97.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/au1550_ac97.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/au1550_ac97.c	2005-12-12 20:43:16.000000000 +0000
@@ -90,8 +90,8 @@ static struct au1550_state {
 	int             no_vra;		/* do not use VRA */
 
 	spinlock_t      lock;
-	struct semaphore open_sem;
-	struct semaphore sem;
+	struct mutex open_sem;
+	struct mutex sem;
 	mode_t          open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/btaudio.c linux-2.6.15-rc5-mutex/sound/oss/btaudio.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/btaudio.c	2005-06-22 13:52:38.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/btaudio.c	2005-12-12 20:41:39.000000000 +0000
@@ -108,7 +108,7 @@ struct btaudio {
 
 	/* locking */
 	int            users;
-	struct semaphore lock;
+	struct mutex   lock;
 
 	/* risc instructions */
 	unsigned int   risc_size;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/cmpci.c linux-2.6.15-rc5-mutex/sound/oss/cmpci.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/cmpci.c	2005-08-30 13:56:46.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/cmpci.c	2005-12-12 20:44:06.000000000 +0000
@@ -392,7 +392,7 @@ struct cm_state {
 	unsigned char fmt, enable;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/cs4281/cs4281m.c linux-2.6.15-rc5-mutex/sound/oss/cs4281/cs4281m.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/cs4281/cs4281m.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/cs4281/cs4281m.c	2005-12-12 20:41:30.000000000 +0000
@@ -245,9 +245,9 @@ struct cs4281_state {
 	void *tmpbuff;		// tmp buffer for sample conversions
 	unsigned ena;
 	spinlock_t lock;
-	struct semaphore open_sem;
-	struct semaphore open_sem_adc;
-	struct semaphore open_sem_dac;
+	struct mutex open_sem;
+	struct mutex open_sem_adc;
+	struct mutex open_sem_dac;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 	wait_queue_head_t open_wait_adc;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/cs46xx.c linux-2.6.15-rc5-mutex/sound/oss/cs46xx.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/cs46xx.c	2005-08-30 13:56:46.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/cs46xx.c	2005-12-12 20:43:37.000000000 +0000
@@ -238,7 +238,7 @@ struct cs_state {
 	struct cs_card *card;	/* Card info */
 
 	/* single open lock mechanism, only used for recording */
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	wait_queue_head_t open_wait;
 
 	/* file mode */
@@ -297,7 +297,7 @@ struct cs_state {
 		unsigned subdivision;
 	} dmabuf;
 	/* Guard against mmap/write/read races */
-	struct semaphore sem;
+	struct mutex sem;
 };
 
 struct cs_card {
@@ -375,7 +375,7 @@ struct cs_card {
 		unsigned char ibuf[CS_MIDIINBUF];
 		unsigned char obuf[CS_MIDIOUTBUF];
 		mode_t open_mode;
-		struct semaphore open_sem;
+		struct mutex open_sem;
 	} midi;
 	struct cs46xx_pm pm;
 };
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/dmasound/dmasound_awacs.c linux-2.6.15-rc5-mutex/sound/oss/dmasound/dmasound_awacs.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/dmasound/dmasound_awacs.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/dmasound/dmasound_awacs.c	2005-12-12 22:12:50.000000000 +0000
@@ -80,7 +80,7 @@
 #include <linux/kmod.h>
 #include <linux/interrupt.h>
 #include <linux/input.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #ifdef CONFIG_ADB_CUDA
 #include <linux/cuda.h>
 #endif
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/emu10k1/hwaccess.h linux-2.6.15-rc5-mutex/sound/oss/emu10k1/hwaccess.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/emu10k1/hwaccess.h	2005-03-02 12:09:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/emu10k1/hwaccess.h	2005-12-12 20:43:59.000000000 +0000
@@ -181,7 +181,7 @@ struct emu10k1_card 
 	struct emu10k1_mpuout	*mpuout;
 	struct emu10k1_mpuin	*mpuin;
 
-	struct semaphore	open_sem;
+	struct mutex		open_sem;
 	mode_t			open_mode;
 	wait_queue_head_t	open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/es1370.c linux-2.6.15-rc5-mutex/sound/oss/es1370.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/es1370.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/es1370.c	2005-12-12 20:43:50.000000000 +0000
@@ -346,7 +346,7 @@ struct es1370_state {
 	unsigned sctrl;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
@@ -393,7 +393,7 @@ struct es1370_state {
 	struct gameport *gameport;
 #endif
 
-	struct semaphore sem;
+	struct mutex sem;
 };
 
 /* --------------------------------------------------------------------- */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/es1371.c linux-2.6.15-rc5-mutex/sound/oss/es1371.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/es1371.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/es1371.c	2005-12-12 20:44:25.000000000 +0000
@@ -419,7 +419,7 @@ struct es1371_state {
 	unsigned dac1rate, dac2rate, adcrate;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
@@ -462,7 +462,7 @@ struct es1371_state {
 	struct gameport *gameport;
 #endif
 
-	struct semaphore sem;
+	struct mutex sem;
 };
 
 /* --------------------------------------------------------------------- */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/esssolo1.c linux-2.6.15-rc5-mutex/sound/oss/esssolo1.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/esssolo1.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/esssolo1.c	2005-12-12 20:41:23.000000000 +0000
@@ -191,7 +191,7 @@ struct solo1_state {
 	unsigned ena;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/forte.c linux-2.6.15-rc5-mutex/sound/oss/forte.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/forte.c	2005-03-02 12:09:13.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/forte.c	2005-12-12 20:43:40.000000000 +0000
@@ -185,7 +185,7 @@ struct forte_chip {
 	unsigned long		iobase;
 	int			irq;
 
-	struct semaphore	open_sem; 	/* Device access */
+	struct mutex		open_sem; 	/* Device access */
 	spinlock_t		lock;		/* State */
 
 	spinlock_t		ac97_lock;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/hal2.c linux-2.6.15-rc5-mutex/sound/oss/hal2.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/hal2.c	2004-09-16 12:06:29.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/hal2.c	2005-12-12 20:43:45.000000000 +0000
@@ -92,7 +92,7 @@ struct hal2_codec {
 
 	wait_queue_head_t dma_wait;
 	spinlock_t lock;
-	struct semaphore sem;
+	struct mutex sem;
 
 	int usecount;			/* recording and playback are
 					 * independent */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/i810_audio.c linux-2.6.15-rc5-mutex/sound/oss/i810_audio.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/i810_audio.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/i810_audio.c	2005-12-12 20:41:42.000000000 +0000
@@ -330,7 +330,7 @@ struct i810_state {
 	struct i810_card *card;	/* Card info */
 
 	/* single open lock mechanism, only used for recording */
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	wait_queue_head_t open_wait;
 
 	/* file mode */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/ite8172.c linux-2.6.15-rc5-mutex/sound/oss/ite8172.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/ite8172.c	2005-11-01 13:19:27.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/ite8172.c	2005-12-12 20:43:43.000000000 +0000
@@ -304,7 +304,7 @@ struct it8172_state {
 	unsigned dacrate, adcrate;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/maestro3.c linux-2.6.15-rc5-mutex/sound/oss/maestro3.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/maestro3.c	2005-06-22 13:52:39.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/maestro3.c	2005-12-12 20:44:31.000000000 +0000
@@ -205,7 +205,7 @@ struct m3_state {
 		when irqhandler uses s->lock
 		and m3_assp_read uses card->lock ?
 		*/
-    struct semaphore open_sem;
+    struct mutex open_sem;
     wait_queue_head_t open_wait;
     mode_t open_mode;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/maestro.c linux-2.6.15-rc5-mutex/sound/oss/maestro.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/maestro.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/maestro.c	2005-12-12 20:43:09.000000000 +0000
@@ -401,7 +401,7 @@ struct ess_state {
 	/* this locks around the oss state in the driver */
 	spinlock_t lock;
 	/* only let 1 be opening at a time */
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	wait_queue_head_t open_wait;
 	mode_t open_mode;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/nec_vrc5477.c linux-2.6.15-rc5-mutex/sound/oss/nec_vrc5477.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/nec_vrc5477.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/nec_vrc5477.c	2005-12-12 20:44:11.000000000 +0000
@@ -198,7 +198,7 @@ struct vrc5477_ac97_state {
 	unsigned short extended_status;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/rme96xx.c linux-2.6.15-rc5-mutex/sound/oss/rme96xx.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/rme96xx.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/rme96xx.c	2005-12-12 20:43:12.000000000 +0000
@@ -326,7 +326,7 @@ typedef struct _rme96xx_info {
 
 		/* waiting and locking */
 		wait_queue_head_t wait;
-		struct semaphore  open_sem;
+		struct mutex  open_sem;
 		wait_queue_head_t open_wait;
 
 	} dma[RME96xx_MAX_DEVS]; 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/sonicvibes.c linux-2.6.15-rc5-mutex/sound/oss/sonicvibes.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/sonicvibes.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/sonicvibes.c	2005-12-12 20:41:34.000000000 +0000
@@ -328,7 +328,7 @@ struct sv_state {
 	unsigned char fmt, enable;
 
 	spinlock_t lock;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/swarm_cs4297a.c linux-2.6.15-rc5-mutex/sound/oss/swarm_cs4297a.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/swarm_cs4297a.c	2005-03-02 12:09:15.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/swarm_cs4297a.c	2005-12-12 20:43:25.000000000 +0000
@@ -291,9 +291,9 @@ struct cs4297a_state {
 	unsigned conversion:1;	// conversion from 16 to 8 bit in progress
 	unsigned ena;
 	spinlock_t lock;
-	struct semaphore open_sem;
-	struct semaphore open_sem_adc;
-	struct semaphore open_sem_dac;
+	struct mutex open_sem;
+	struct mutex open_sem_adc;
+	struct mutex open_sem_dac;
 	mode_t open_mode;
 	wait_queue_head_t open_wait;
 	wait_queue_head_t open_wait_adc;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/trident.c linux-2.6.15-rc5-mutex/sound/oss/trident.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/trident.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/trident.c	2005-12-12 20:44:04.000000000 +0000
@@ -351,7 +351,7 @@ struct trident_state {
 	unsigned chans_num;
 	unsigned long fmt_flag;
 	/* Guard against mmap/write/read races */
-	struct semaphore sem;
+	struct mutex sem;
 
 };
 
@@ -404,7 +404,7 @@ struct trident_card {
 	struct trident_card *next;
 
 	/* single open lock mechanism, only used for recording */
-	struct semaphore open_sem;
+	struct mutex open_sem;
 
 	/* The trident has a certain amount of cross channel interaction
 	   so we use a single per card lock */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/via82cxxx_audio.c linux-2.6.15-rc5-mutex/sound/oss/via82cxxx_audio.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/via82cxxx_audio.c	2005-08-30 13:56:47.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/oss/via82cxxx_audio.c	2005-12-12 22:12:50.000000000 +0000
@@ -36,9 +36,9 @@
 #include <linux/ioport.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
+#include <linux/semaphore.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
-#include <asm/semaphore.h>
 #include "sound_config.h"
 #include "dev_table.h"
 #include "mpu401.h"
@@ -311,8 +311,8 @@ struct via_info {
 	
 	int mixer_vol;		/* 8233/35 volume  - not yet implemented */
 
-	struct semaphore syscall_sem;
-	struct semaphore open_sem;
+	struct mutex syscall_sem;
+	struct mutex open_sem;
 
 	/* The 8233/8235 have 4 DX audio channels, two record and
 	   one six channel out. We bind ch_in to DX 1, ch_out to multichannel
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/vwsnd.c linux-2.6.15-rc5-mutex/sound/oss/vwsnd.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/vwsnd.c	2005-03-02 12:09:15.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/vwsnd.c	2005-12-12 22:12:50.000000000 +0000
@@ -148,7 +148,7 @@
 #include <linux/smp_lock.h>
 #include <linux/wait.h>
 #include <linux/interrupt.h>
-#include <asm/semaphore.h>
+#include <linux/semaphore.h>
 #include <asm/mach-visws/cobalt.h>
 
 #include "sound_config.h"
@@ -1507,9 +1507,9 @@ typedef struct vwsnd_dev {
 	int		audio_minor;	/* minor number of audio device */
 	int		mixer_minor;	/* minor number of mixer device */
 
-	struct semaphore open_sema;
-	struct semaphore io_sema;
-	struct semaphore mix_sema;
+	struct mutex open_sema;
+	struct mutex io_sema;
+	struct mutex mix_sema;
 	mode_t		open_mode;
 	wait_queue_head_t open_wait;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/oss/ymfpci.h linux-2.6.15-rc5-mutex/sound/oss/ymfpci.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/oss/ymfpci.h	2005-01-04 11:14:03.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/oss/ymfpci.h	2005-12-12 20:44:28.000000000 +0000
@@ -279,7 +279,7 @@ struct ymf_unit {
 
 	/* soundcore stuff */
 	int dev_audio;
-	struct semaphore open_sem;
+	struct mutex open_sem;
 
 	struct list_head ymf_devs;
 	struct list_head states;	/* List of states for this unit */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/atiixp.c linux-2.6.15-rc5-mutex/sound/pci/atiixp.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/atiixp.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/atiixp.c	2005-12-12 20:45:15.000000000 +0000
@@ -280,7 +280,7 @@ struct snd_atiixp {
 	unsigned int codec_not_ready_bits;	/* for codec detection */
 
 	int spdif_over_aclink;		/* passed from the module option */
-	struct semaphore open_mutex;	/* playback open mutex */
+	struct mutex open_mutex;	/* playback open mutex */
 };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/atiixp_modem.c linux-2.6.15-rc5-mutex/sound/pci/atiixp_modem.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/atiixp_modem.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/atiixp_modem.c	2005-12-12 20:45:13.000000000 +0000
@@ -258,7 +258,7 @@ struct snd_atiixp {
 	unsigned int codec_not_ready_bits;	/* for codec detection */
 
 	int spdif_over_aclink;		/* passed from the module option */
-	struct semaphore open_mutex;	/* playback open mutex */
+	struct mutex open_mutex;	/* playback open mutex */
 };
 
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/cmipci.c linux-2.6.15-rc5-mutex/sound/pci/cmipci.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/cmipci.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/cmipci.c	2005-12-12 20:45:08.000000000 +0000
@@ -440,7 +440,7 @@ struct snd_stru_cmipci {
 	snd_pcm_hardware_t *hw_info[3]; /* for playbacks */
 
 	int opened[2];	/* open mode */
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 
 	unsigned int mixer_insensitive: 1;
 	snd_kcontrol_t *mixer_res_ctl[CM_SAVED_MIXERS];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/ens1370.c linux-2.6.15-rc5-mutex/sound/pci/ens1370.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/ens1370.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/ens1370.c	2005-12-12 20:44:36.000000000 +0000
@@ -364,7 +364,7 @@ typedef struct _snd_ensoniq ensoniq_t;
 
 struct _snd_ensoniq {
 	spinlock_t reg_lock;
-	struct semaphore src_mutex;
+	struct mutex src_mutex;
 
 	int irq;
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/es1968.c linux-2.6.15-rc5-mutex/sound/pci/es1968.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/es1968.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/es1968.c	2005-12-12 20:45:10.000000000 +0000
@@ -573,7 +573,7 @@ struct snd_es1968 {
 	u16 maestro_map[32];
 	int bobclient;		/* active timer instancs */
 	int bob_freq;		/* timer frequency */
-	struct semaphore memory_mutex;	/* memory lock */
+	struct mutex memory_mutex;	/* memory lock */
 
 	/* APU states */
 	unsigned char apu[NR_APUS];
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/hda/hda_codec.h linux-2.6.15-rc5-mutex/sound/pci/hda/hda_codec.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/hda/hda_codec.h	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/hda/hda_codec.h	2005-12-12 21:45:18.000000000 +0000
@@ -432,7 +432,7 @@ struct hda_bus {
 	struct list_head codec_list;
 	struct hda_codec *caddr_tbl[HDA_MAX_CODEC_ADDRESS + 1]; /* caddr -> codec */
 
-	struct semaphore cmd_mutex;
+	struct mutex cmd_mutex;
 
 	/* unsolicited event queue */
 	struct hda_bus_unsolicited *unsol;
@@ -547,7 +547,7 @@ struct hda_codec {
 	int num_amp_entries;
 	struct hda_amp_info amp_info[128]; /* big enough? */
 
-	struct semaphore spdif_mutex;
+	struct mutex spdif_mutex;
 	unsigned int spdif_status;	/* IEC958 status bits */
 	unsigned short spdif_ctls;	/* SPDIF control bits */
 	unsigned int spdif_in_enable;	/* SPDIF input enable? */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/hda/hda_intel.c linux-2.6.15-rc5-mutex/sound/pci/hda/hda_intel.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/hda/hda_intel.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/hda/hda_intel.c	2005-12-12 21:45:18.000000000 +0000
@@ -298,7 +298,7 @@ struct snd_azx {
 
 	/* locks */
 	spinlock_t reg_lock;
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 
 	/* streams (x num_streams) */
 	azx_dev_t *azx_dev;
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/hda/patch_analog.c linux-2.6.15-rc5-mutex/sound/pci/hda/patch_analog.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/hda/patch_analog.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/hda/patch_analog.c	2005-12-12 21:45:18.000000000 +0000
@@ -58,7 +58,7 @@ struct ad198x_spec {
 	/* PCM information */
 	struct hda_pcm pcm_rec[2];	/* used in alc_build_pcms() */
 
-	struct semaphore amp_mutex;	/* PCM volume/mute control mutex */
+	struct mutex amp_mutex;	/* PCM volume/mute control mutex */
 	unsigned int spdif_route;
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/ice1712/ice1712.h linux-2.6.15-rc5-mutex/sound/pci/ice1712/ice1712.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/ice1712/ice1712.h	2005-08-30 13:56:48.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/pci/ice1712/ice1712.h	2005-12-12 20:45:01.000000000 +0000
@@ -334,7 +334,7 @@ struct _snd_ice1712 {
 	unsigned int num_total_adcs;	/* total ADCs */
 	unsigned int cur_rate;		/* current rate */
 
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 	snd_pcm_substream_t *pcm_reserved[4];
 	snd_pcm_hw_constraint_list_t *hw_rates; /* card-specific rate constraints */
 
@@ -342,7 +342,7 @@ struct _snd_ice1712 {
 	akm4xxx_t *akm;
 	struct snd_ice1712_spdif spdif;
 
-	struct semaphore i2c_mutex;	/* I2C mutex for ICE1724 registers */
+	struct mutex i2c_mutex;	/* I2C mutex for ICE1724 registers */
 	snd_i2c_bus_t *i2c;		/* I2C bus */
 	snd_i2c_device_t *cs8427;	/* CS8427 I2C device */
 	unsigned int cs8427_timeout;	/* CS8427 reset timeout in HZ/100 */
@@ -360,7 +360,7 @@ struct _snd_ice1712 {
 		void (*set_pro_rate)(ice1712_t *ice, unsigned int rate);
 		void (*i2s_mclk_changed)(ice1712_t *ice);
 	} gpio;
-	struct semaphore gpio_mutex;
+	struct mutex gpio_mutex;
 
 	/* other board-specific data */
 	union {
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/korg1212/korg1212.c linux-2.6.15-rc5-mutex/sound/pci/korg1212/korg1212.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/korg1212/korg1212.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/korg1212/korg1212.c	2005-12-12 20:44:34.000000000 +0000
@@ -324,7 +324,7 @@ struct _snd_korg1212 {
         int irq;
 
         spinlock_t    lock;
-	struct semaphore open_mutex;
+	struct mutex open_mutex;
 
 	struct timer_list timer;	/* timer callback for checking ack of stop request */
 	int stop_pending_cnt;		/* counter for stop pending check */
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/mixart/mixart.h linux-2.6.15-rc5-mutex/sound/pci/mixart/mixart.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/mixart/mixart.h	2005-06-22 13:52:39.000000000 +0100
+++ linux-2.6.15-rc5-mutex/sound/pci/mixart/mixart.h	2005-12-12 20:45:19.000000000 +0000
@@ -107,9 +107,9 @@ struct snd_mixart_mgr {
 
 	spinlock_t lock;              /* interrupt spinlock */
 	spinlock_t msg_lock;          /* mailbox spinlock */
-	struct semaphore msg_mutex;   /* mutex for blocking_requests */
+	struct mutex msg_mutex;   /* mutex for blocking_requests */
 
-	struct semaphore setup_mutex; /* mutex used in hw_params, open and close */
+	struct mutex setup_mutex; /* mutex used in hw_params, open and close */
 
 	/* hardware interface */
 	unsigned int dsp_loaded;      /* bit flags of loaded dsp indices */
@@ -122,7 +122,7 @@ struct snd_mixart_mgr {
 	int sample_rate;
 	int ref_count_rate;
 
-	struct semaphore mixer_mutex; /* mutex for mixer */
+	struct mutex mixer_mutex; /* mutex for mixer */
 
 };
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/pci/nm256/nm256.c linux-2.6.15-rc5-mutex/sound/pci/nm256/nm256.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/pci/nm256/nm256.c	2005-12-08 16:23:58.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/pci/nm256/nm256.c	2005-12-12 20:45:23.000000000 +0000
@@ -242,7 +242,7 @@ struct snd_nm256 {
 	int irq_acks;
 	irqreturn_t (*interrupt)(int, void *, struct pt_regs *);
 	int badintrcount;		/* counter to check bogus interrupts */
-	struct semaphore irq_mutex;
+	struct mutex irq_mutex;
 
 	nm256_stream_t streams[2];
 
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/sparc/cs4231.c linux-2.6.15-rc5-mutex/sound/sparc/cs4231.c
--- /warthog/kernels/linux-2.6.15-rc5/sound/sparc/cs4231.c	2005-12-08 16:23:59.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/sparc/cs4231.c	2005-12-12 20:40:31.000000000 +0000
@@ -116,8 +116,8 @@ struct snd_cs4231 {
 	unsigned char		image[32];	/* registers image */
 	int			mce_bit;
 	int			calibrate_mute;
-	struct semaphore	mce_mutex;
-	struct semaphore	open_mutex;
+	struct mutex		mce_mutex;
+	struct mutex		open_mutex;
 
 	union {
 #ifdef SBUS_SUPPORT
diff -uNrp /warthog/kernels/linux-2.6.15-rc5/sound/usb/usx2y/usbusx2y.h linux-2.6.15-rc5-mutex/sound/usb/usx2y/usbusx2y.h
--- /warthog/kernels/linux-2.6.15-rc5/sound/usb/usx2y/usbusx2y.h	2005-03-02 12:09:17.000000000 +0000
+++ linux-2.6.15-rc5-mutex/sound/usb/usx2y/usbusx2y.h	2005-12-12 20:40:25.000000000 +0000
@@ -35,7 +35,7 @@ typedef struct {
 	unsigned int		rate,
 				format;
 	int			chip_status;
-	struct semaphore	prepare_mutex;
+	struct mutex		prepare_mutex;
 	us428ctls_sharedmem_t	*us428ctls_sharedmem;
 	int			wait_iso_frame;
 	wait_queue_head_t	us428ctls_wait_queue_head;

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (17 preceding siblings ...)
  2005-12-12 23:45 ` [PATCH 19/19] MUTEX: Sound changes David Howells
@ 2005-12-13  0:13 ` Nick Piggin
  2005-12-13  0:19 ` Nick Piggin
                   ` (13 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-13  0:13 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:
> The attached patch introduces a simple mutex implementation as an alternative
> to the usual semaphore implementation where simple mutex functionality is all
> that is required.
> 
> This is useful in two ways:
> 
>  (1) A number of archs only provide very simple atomic instructions (such as
>      XCHG on i386, TAS on M68K, SWAP on FRV) which aren't sufficient to
>      implement full semaphore support directly. Instead spinlocks must be
>      employed to implement fuller functionality.
> 

We have atomic_cmpxchg. Can you use that for a sufficient generic
implementation?

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (18 preceding siblings ...)
  2005-12-13  0:13 ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Nick Piggin
@ 2005-12-13  0:19 ` Nick Piggin
  2005-12-13  0:19 ` Andrew Morton
                   ` (12 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-13  0:19 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:

> +	/* set up my own style of waitqueue */
> +	waiter.task = tsk;
> +

Any reason why you're setting up your own style of waitqueue in
mutex-simple.c instead of just using the kernel's style of waitqueue?

> +
> +/*
> + * release a single token back to a mutex
> + * - entered with lock held and interrupts disabled
> + * - the queue will not be empty
> + */
> +void __up(struct mutex *mutex)
> +{
> +	struct mutex_waiter *waiter;
> +	struct task_struct *tsk;
> +
> +	/* grant the token to the process at the front of the queue */
> +	waiter = list_entry(mutex->wait_list.next, struct mutex_waiter, list);
> +
> +	/* we must be careful not to touch 'waiter' after we set ->task = NULL.
> +	 * - it is an allocated on the waiter's stack and may become invalid at
> +	 *   any time after that point (due to a wakeup from another source).
> +	 */
> +	list_del_init(&waiter->list);
> +	tsk = waiter->task;
> +#ifdef CONFIG_DEBUG_MUTEX_OWNER
> +	mutex->__owner = tsk;
> +#endif
> +	mb();

This should be smp_mb(), I think.

> +	waiter->task = NULL;
> +	wake_up_process(tsk);
> +	put_task_struct(tsk);
> +}

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (19 preceding siblings ...)
  2005-12-13  0:19 ` Nick Piggin
@ 2005-12-13  0:19 ` Andrew Morton
  2005-12-13  7:54   ` Ingo Molnar
  2005-12-13  0:30 ` Arnd Bergmann
                   ` (11 subsequent siblings)
  32 siblings, 1 reply; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  0:19 UTC (permalink / raw)
  To: David Howells; +Cc: torvalds, hch, arjan, matthew, linux-kernel, linux-arch

David Howells <dhowells@redhat.com> wrote:
>
> The attached patch introduces a simple mutex implementation as an alternative
> to the usual semaphore implementation where simple mutex functionality is all
> that is required.
> 
> This is useful in two ways:
> 
>  (1) A number of archs only provide very simple atomic instructions (such as
>      XCHG on i386, TAS on M68K, SWAP on FRV) which aren't sufficient to
>      implement full semaphore support directly. Instead spinlocks must be
>      employed to implement fuller functionality.
> 
>  (2) This makes it obvious in what way the semaphore is being used: whether
>      it's being used as a mutex or being used as a counter.
> 
> This patch set does the following:
> 
>  (1) Provides a simple xchg() based semaphore as a default for all
>      architectures that don't wish to override it and provide their own.
> 
>      Overriding is possible by setting CONFIG_ARCH_IMPLEMENTS_MUTEX and
>      supplying asm/mutex.h
> 
>      Partial overriding is possible by #defining mutex_grab(), mutex_release()
>      and is_mutex_locked() to perform the appropriate optimised functions.
> 
>  (2) Provides linux/mutex.h as a common include for gaining access to mutex
>      semaphores.
> 
>  (3) Provides linux/semaphore.h as a common include for gaining access to all
>      the different types of semaphore that may be used from within the kernel.
> 
>  (4) Renames down*() to down_sem*() and up() to up_sem() for the traditional
>      semaphores, and removes init_MUTEX*() and DECLARE_MUTEX*() from
>      asm/semaphore.h
> 
>  (5) Redirects the following to apply to the new mutexes rather than the
>      traditional semaphores:
> 
> 	down()
> 	down_trylock()
> 	down_interruptible()
> 	up()
> 	init_MUTEX()
>      	init_MUTEX_LOCKED()
> 	DECLARE_MUTEX()
> 	DECLARE_MUTEX_LOCKED()
> 
>      On the basis that most usages of semaphores are as mutexes, this makes
>      sense for in most cases it's just then a matter of changing the type from
>      struct semaphore to struct mutex. In some cases, sema_init() has to be
>      changed to init_MUTEX*() also.
> 
>  (6) Generally include linux/semaphore.h in place of asm/semaphore.h.
> 
>  (7) Provides a debugging config option CONFIG_DEBUG_MUTEX_OWNER by which the
>      mutex owner can be tracked and by which over-upping can be detected.

Maybe I'm not understanding all this, but...

I'd have thought that the way to do this is to simply reimplement down(),
up(), down_trylock(), etc using the new xchg-based code and to then hunt
down those few parts of the kernel which actually use the old semaphore's
counting feature and convert them to use down_sem(), up_sem(), etc.  And
rename all the old semaphore code: s/down/down_sem/etc.

So after such a transformation, this new "mutex" thingy would not exist.

>  include/linux/mutex.h        |   32 +++++++

But it does.

> +#define mutex_grab(mutex)	(xchg(&(mutex)->state, 1) == 0)

mutex_trylock(), please.

> +#define is_mutex_locked(mutex)	((mutex)->state)

Let's keep the namespace consistent.  mutex_is_locked().

> +static inline void down(struct mutex *mutex)
> +{
> +	if (mutex_grab(mutex)) {

likely()

> +#ifdef CONFIG_DEBUG_MUTEX_OWNER
> +		mutex->__owner = current;
> +#endif
> +	}
> +	else {
> +		__down(mutex);
> +	}
> +}
> +
> +/*
> + * sleep interruptibly until we get the mutex
> + * - return 0 if successful, -EINTR if interrupted
> + */
> +static inline int down_interruptible(struct mutex *mutex)
> +{
> +	if (mutex_grab(mutex)) {

likely()

> +static inline int down_trylock(struct mutex *mutex)
> +{
> +	if (mutex_grab(mutex)) {

etc.

You could just put likely() into mutex_trylock().  err, mutex_grab().

> +/*
> + * release the mutex
> + */
> +static inline void up(struct mutex *mutex)
> +{
> +	unsigned long flags;
> +
> +#ifdef CONFIG_DEBUG_MUTEX_OWNER
> +	if (mutex->__owner != current)
> +		__up_bad(mutex);
> +	mutex->__owner = NULL;
> +#endif
> +
> +	/* must prevent a race */
> +	spin_lock_irqsave(&mutex->wait_lock, flags);
> +	if (!list_empty(&mutex->wait_list))
> +		__up(mutex);
> +	else
> +		mutex_release(mutex);
> +	spin_unlock_irqrestore(&mutex->wait_lock, flags);
> +}

This is too large to inline.

It's also significantly slower than the existing up()?


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (20 preceding siblings ...)
  2005-12-13  0:19 ` Andrew Morton
@ 2005-12-13  0:30 ` Arnd Bergmann
  2005-12-13  0:57 ` Daniel Walker
                   ` (10 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: Arnd Bergmann @ 2005-12-13  0:30 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

Am Dienstag 13 Dezember 2005 00:45 schrieb David Howells:
>  (7) Provides a debugging config option CONFIG_DEBUG_MUTEX_OWNER by which
> the mutex owner can be tracked and by which over-upping can be detected.

I can't see how your code actually detects the over-upping, although it's 
fairly obvious how it would be done. Did you miss one patch for this?

	Arnd <><

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (21 preceding siblings ...)
  2005-12-13  0:30 ` Arnd Bergmann
@ 2005-12-13  0:57 ` Daniel Walker
  2005-12-13  3:23   ` Steven Rostedt
  2005-12-13  2:57 ` Mark Lord
                   ` (9 subsequent siblings)
  32 siblings, 1 reply; 249+ messages in thread
From: Daniel Walker @ 2005-12-13  0:57 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

On Mon, 2005-12-12 at 23:45 +0000, David Howells wrote:

>  (1) Provides a simple xchg() based semaphore as a default for all
>      architectures that don't wish to override it and provide their own.
> 
>      Overriding is possible by setting CONFIG_ARCH_IMPLEMENTS_MUTEX and
>      supplying asm/mutex.h
> 
>      Partial overriding is possible by #defining mutex_grab(), mutex_release()
>      and is_mutex_locked() to perform the appropriate optimised functions.

Your code is really similar to the RT mutex, which does everything that
your mutex does at least ? Assuming you've reviewed the RT mutex, why
would we want to use yours over it?

Daniel


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (22 preceding siblings ...)
  2005-12-13  0:57 ` Daniel Walker
@ 2005-12-13  2:57 ` Mark Lord
  2005-12-13  3:17   ` Steven Rostedt
  2005-12-13  9:06   ` Christoph Hellwig
  2005-12-13  9:54 ` David Howells
                   ` (8 subsequent siblings)
  32 siblings, 2 replies; 249+ messages in thread
From: Mark Lord @ 2005-12-13  2:57 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

 > (5) Redirects the following to apply to the new mutexes rather than the
 >     traditional semaphores:
 >
 >	down()
 >	down_trylock()
 >	down_interruptible()
 >	up()

This will BREAK a lot of out-of-tree stuff if merged.

So please figure out some way to hang a HUGE banner out there
so that the external codebases know they need updating.

The simplest way would be to NOT re-use the up()/down() symbols,
but rather to either keep them as-is (counting semaphores),
or delete them entirely (so that external code *knows* of the change).

Cheers

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  2:57 ` Mark Lord
@ 2005-12-13  3:17   ` Steven Rostedt
  2005-12-13  9:06   ` Christoph Hellwig
  1 sibling, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-13  3:17 UTC (permalink / raw)
  To: Mark Lord
  Cc: linux-arch, linux-kernel, matthew, arjan, hch, akpm, torvalds,
	David Howells

On Mon, 2005-12-12 at 21:57 -0500, Mark Lord wrote:
>  > (5) Redirects the following to apply to the new mutexes rather than the
>  >     traditional semaphores:
>  >
>  >	down()
>  >	down_trylock()
>  >	down_interruptible()
>  >	up()
> 
> This will BREAK a lot of out-of-tree stuff if merged.
> 
> So please figure out some way to hang a HUGE banner out there
> so that the external codebases know they need updating.
> 
> The simplest way would be to NOT re-use the up()/down() symbols,
> but rather to either keep them as-is (counting semaphores),
> or delete them entirely (so that external code *knows* of the change).

Actually, up and down don't imply mutex at all.  So maybe it would be
better to keep up and down as normal semaphores, rename what you want to
mutex_lock / mutex_unlock which makes it obvious what it is, and then
you can go through and find all the semaphores that are being used as
mutexes (or is that mutices?) and make the change more incrementally.

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  0:57 ` Daniel Walker
@ 2005-12-13  3:23   ` Steven Rostedt
  0 siblings, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-13  3:23 UTC (permalink / raw)
  To: Daniel Walker
  Cc: linux-arch, linux-kernel, matthew, arjan, hch, akpm, torvalds,
	David Howells, Ingo Molnar

On Mon, 2005-12-12 at 16:57 -0800, Daniel Walker wrote:
> On Mon, 2005-12-12 at 23:45 +0000, David Howells wrote:
> 
> >  (1) Provides a simple xchg() based semaphore as a default for all
> >      architectures that don't wish to override it and provide their own.
> > 
> >      Overriding is possible by setting CONFIG_ARCH_IMPLEMENTS_MUTEX and
> >      supplying asm/mutex.h
> > 
> >      Partial overriding is possible by #defining mutex_grab(), mutex_release()
> >      and is_mutex_locked() to perform the appropriate optimised functions.
> 
> Your code is really similar to the RT mutex, which does everything that
> your mutex does at least ? Assuming you've reviewed the RT mutex, why
> would we want to use yours over it?

Maybe this would be the better !PREEMPT_RT version.  But the true mutex
that Ingo is making would be used for the PREEMPT_RT side.

This code at least brings down the over head of semaphores where they
are not really needed.  Looking at the code slightly (I must admit, I
spent maybe 30 seconds looking at it), it does seem a little similar to
Ingo's.  Could just be coincidence, since the methods are pretty much
what multiple people would come up with.  But you both work for RedHat,
hmm.

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  0:19 ` Andrew Morton
@ 2005-12-13  7:54   ` Ingo Molnar
  2005-12-13  7:58     ` Andi Kleen
                       ` (3 more replies)
  0 siblings, 4 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  7:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Howells, torvalds, hch, arjan, matthew, linux-kernel, linux-arch


* Andrew Morton <akpm@osdl.org> wrote:

> I'd have thought that the way to do this is to simply reimplement 
> down(), up(), down_trylock(), etc using the new xchg-based code and to 
> then hunt down those few parts of the kernel which actually use the 
> old semaphore's counting feature and convert them to use down_sem(), 
> up_sem(), etc.  And rename all the old semaphore code: 
> s/down/down_sem/etc.

even better than that, why not use the solution that we've implemented 
for the -rt patchset, more than a year ago?

the solution i took was this:

- i did not touch the 'struct semaphore' namespace, but introduced a
  'struct compat_semaphore'.

- i introduced a 'type-sensitive' macro wrapper that switches down() 
  (and the other APIs) to either to the assembly variant (if the 
  variable's type is struct compat_semaphore), or switches it to the new 
  generic mutex (if the type is struct semaphore), at build-time. There 
  is no runtime overhead due to this build-time-switching.

- for many months we worked with upstream maintainers to convert dozens
  of mutex users over to struct completion, where this was appropriate.

all this simplified the 'compatibility conversion' to the patch below.  
No other non-generic changes are needed.

	Ingo

----
convert the remaining users of 'full Linux semaphore semantics' over to 
compat_semaphore.

 drivers/acpi/osl.c                        |   12 ++++++------
 drivers/ieee1394/ieee1394_types.h         |    2 +-
 drivers/ieee1394/nodemgr.c                |    2 +-
 drivers/ieee1394/raw1394-private.h        |    2 +-
 drivers/media/dvb/dvb-core/dvb_frontend.c |    2 +-
 drivers/media/dvb/dvb-core/dvb_frontend.h |    2 +-
 drivers/net/3c527.c                       |    2 +-
 drivers/net/hamradio/6pack.c              |    2 +-
 drivers/net/hamradio/mkiss.c              |    2 +-
 drivers/net/plip.c                        |    5 ++++-
 drivers/net/ppp_async.c                   |    2 +-
 drivers/net/ppp_synctty.c                 |    2 +-
 drivers/pci/hotplug/cpci_hotplug_core.c   |    4 ++--
 drivers/pci/hotplug/cpqphp_ctrl.c         |    4 ++--
 drivers/pci/hotplug/ibmphp_hpc.c          |    2 +-
 drivers/pci/hotplug/pciehp_ctrl.c         |    4 ++--
 drivers/pci/hotplug/shpchp_ctrl.c         |    4 ++--
 drivers/scsi/aacraid/aacraid.h            |    4 ++--
 drivers/scsi/aic7xxx/aic79xx_osm.h        |    2 +-
 drivers/scsi/aic7xxx/aic7xxx_osm.h        |    2 +-
 drivers/scsi/qla2xxx/qla_def.h            |    2 +-
 drivers/usb/storage/usb.h                 |    2 +-
 fs/xfs/linux-2.6/mutex.h                  |    2 +-
 fs/xfs/linux-2.6/sema.h                   |    2 +-
 fs/xfs/linux-2.6/xfs_buf.h                |    4 ++--
 include/linux/jffs2_fs_i.h                |   10 +++++++++-
 include/linux/jffs2_fs_sb.h               |    6 +++---
 include/linux/parport.h                   |    2 +-
 include/pcmcia/ss.h                       |    2 +-
 include/scsi/scsi_transport_spi.h         |    2 +-
 30 files changed, 54 insertions(+), 43 deletions(-)

Index: linux/drivers/acpi/osl.c
===================================================================
--- linux.orig/drivers/acpi/osl.c
+++ linux/drivers/acpi/osl.c
@@ -728,14 +728,14 @@ void acpi_os_delete_lock(acpi_handle han
 acpi_status
 acpi_os_create_semaphore(u32 max_units, u32 initial_units, acpi_handle * handle)
 {
-	struct semaphore *sem = NULL;
+	struct compat_semaphore *sem = NULL;
 
 	ACPI_FUNCTION_TRACE("os_create_semaphore");
 
-	sem = acpi_os_allocate(sizeof(struct semaphore));
+	sem = acpi_os_allocate(sizeof(struct compat_semaphore));
 	if (!sem)
 		return_ACPI_STATUS(AE_NO_MEMORY);
-	memset(sem, 0, sizeof(struct semaphore));
+	memset(sem, 0, sizeof(struct compat_semaphore));
 
 	sema_init(sem, initial_units);
 
@@ -758,7 +758,7 @@ EXPORT_SYMBOL(acpi_os_create_semaphore);
 
 acpi_status acpi_os_delete_semaphore(acpi_handle handle)
 {
-	struct semaphore *sem = (struct semaphore *)handle;
+	struct compat_semaphore *sem = (struct compat_semaphore *)handle;
 
 	ACPI_FUNCTION_TRACE("os_delete_semaphore");
 
@@ -787,7 +787,7 @@ EXPORT_SYMBOL(acpi_os_delete_semaphore);
 acpi_status acpi_os_wait_semaphore(acpi_handle handle, u32 units, u16 timeout)
 {
 	acpi_status status = AE_OK;
-	struct semaphore *sem = (struct semaphore *)handle;
+	struct compat_semaphore *sem = (struct compat_semaphore *)handle;
 	int ret = 0;
 
 	ACPI_FUNCTION_TRACE("os_wait_semaphore");
@@ -868,7 +868,7 @@ EXPORT_SYMBOL(acpi_os_wait_semaphore);
  */
 acpi_status acpi_os_signal_semaphore(acpi_handle handle, u32 units)
 {
-	struct semaphore *sem = (struct semaphore *)handle;
+	struct compat_semaphore *sem = (struct compat_semaphore *)handle;
 
 	ACPI_FUNCTION_TRACE("os_signal_semaphore");
 
Index: linux/drivers/ieee1394/ieee1394_types.h
===================================================================
--- linux.orig/drivers/ieee1394/ieee1394_types.h
+++ linux/drivers/ieee1394/ieee1394_types.h
@@ -19,7 +19,7 @@ struct hpsb_tlabel_pool {
 	spinlock_t lock;
 	u8 next;
 	u32 allocations;
-	struct semaphore count;
+	struct compat_semaphore count;
 };
 
 #define HPSB_TPOOL_INIT(_tp)			\
Index: linux/drivers/ieee1394/nodemgr.c
===================================================================
--- linux.orig/drivers/ieee1394/nodemgr.c
+++ linux/drivers/ieee1394/nodemgr.c
@@ -114,7 +114,7 @@ struct host_info {
 	struct hpsb_host *host;
 	struct list_head list;
 	struct completion exited;
-	struct semaphore reset_sem;
+	struct compat_semaphore reset_sem;
 	int pid;
 	char daemon_name[15];
 	int kill_me;
Index: linux/drivers/ieee1394/raw1394-private.h
===================================================================
--- linux.orig/drivers/ieee1394/raw1394-private.h
+++ linux/drivers/ieee1394/raw1394-private.h
@@ -29,7 +29,7 @@ struct file_info {
 
         struct list_head req_pending;
         struct list_head req_complete;
-        struct semaphore complete_sem;
+        struct compat_semaphore complete_sem;
         spinlock_t reqlists_lock;
         wait_queue_head_t poll_wait_complete;
 
Index: linux/drivers/media/dvb/dvb-core/dvb_frontend.c
===================================================================
--- linux.orig/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ linux/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -95,7 +95,7 @@ struct dvb_frontend_private {
 	struct dvb_device *dvbdev;
 	struct dvb_frontend_parameters parameters;
 	struct dvb_fe_events events;
-	struct semaphore sem;
+	struct compat_semaphore sem;
 	struct list_head list_head;
 	wait_queue_head_t wait_queue;
 	pid_t thread_pid;
Index: linux/drivers/media/dvb/dvb-core/dvb_frontend.h
===================================================================
--- linux.orig/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ linux/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -86,7 +86,7 @@ struct dvb_fe_events {
 	int			  eventr;
 	int			  overflow;
 	wait_queue_head_t	  wait_queue;
-	struct semaphore	  sem;
+	struct compat_semaphore	  sem;
 };
 
 struct dvb_frontend {
Index: linux/drivers/net/3c527.c
===================================================================
--- linux.orig/drivers/net/3c527.c
+++ linux/drivers/net/3c527.c
@@ -182,7 +182,7 @@ struct mc32_local 
 
 	u16 rx_ring_tail;       /* index to rx de-queue end */ 
 
-	struct semaphore cmd_mutex;    /* Serialises issuing of execute commands */
+	struct compat_semaphore cmd_mutex;    /* Serialises issuing of execute commands */
         struct completion execution_cmd; /* Card has completed an execute command */
 	struct completion xceiver_cmd;   /* Card has completed a tx or rx command */
 };
Index: linux/drivers/net/hamradio/6pack.c
===================================================================
--- linux.orig/drivers/net/hamradio/6pack.c
+++ linux/drivers/net/hamradio/6pack.c
@@ -124,7 +124,7 @@ struct sixpack {
 	struct timer_list	tx_t;
 	struct timer_list	resync_t;
 	atomic_t		refcnt;
-	struct semaphore	dead_sem;
+	struct compat_semaphore	dead_sem;
 	spinlock_t		lock;
 };
 
Index: linux/drivers/net/hamradio/mkiss.c
===================================================================
--- linux.orig/drivers/net/hamradio/mkiss.c
+++ linux/drivers/net/hamradio/mkiss.c
@@ -85,7 +85,7 @@ struct mkiss {
 #define CRC_MODE_SMACK_TEST	4
 
 	atomic_t		refcnt;
-	struct semaphore	dead_sem;
+	struct compat_semaphore	dead_sem;
 };
 
 /*---------------------------------------------------------------------------*/
Index: linux/drivers/net/plip.c
===================================================================
--- linux.orig/drivers/net/plip.c
+++ linux/drivers/net/plip.c
@@ -229,7 +229,10 @@ struct net_local {
 	                              struct hh_cache *hh);
 	spinlock_t lock;
 	atomic_t kill_timer;
-	struct semaphore killed_timer_sem;
+	/*
+	 * PREEMPT_RT: this isnt a mutex, it should be struct completion.
+	 */
+	struct compat_semaphore killed_timer_sem;
 };
 
 static inline void enable_parport_interrupts (struct net_device *dev)
Index: linux/drivers/net/ppp_async.c
===================================================================
--- linux.orig/drivers/net/ppp_async.c
+++ linux/drivers/net/ppp_async.c
@@ -66,7 +66,7 @@ struct asyncppp {
 	struct tasklet_struct tsk;
 
 	atomic_t	refcnt;
-	struct semaphore dead_sem;
+	struct compat_semaphore dead_sem;
 	struct ppp_channel chan;	/* interface to generic ppp layer */
 	unsigned char	obuf[OBUFSIZE];
 };
Index: linux/drivers/net/ppp_synctty.c
===================================================================
--- linux.orig/drivers/net/ppp_synctty.c
+++ linux/drivers/net/ppp_synctty.c
@@ -70,7 +70,7 @@ struct syncppp {
 	struct tasklet_struct tsk;
 
 	atomic_t	refcnt;
-	struct semaphore dead_sem;
+	struct compat_semaphore dead_sem;
 	struct ppp_channel chan;	/* interface to generic ppp layer */
 };
 
Index: linux/drivers/pci/hotplug/cpci_hotplug_core.c
===================================================================
--- linux.orig/drivers/pci/hotplug/cpci_hotplug_core.c
+++ linux/drivers/pci/hotplug/cpci_hotplug_core.c
@@ -60,8 +60,8 @@ static int slots;
 static atomic_t extracting;
 int cpci_debug;
 static struct cpci_hp_controller *controller;
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore thread_exit;		/* guard ensure thread has exited before calling it quits */
+static struct compat_semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct compat_semaphore thread_exit;		/* guard ensure thread has exited before calling it quits */
 static int thread_finished = 1;
 
 static int enable_slot(struct hotplug_slot *slot);
Index: linux/drivers/pci/hotplug/cpqphp_ctrl.c
===================================================================
--- linux.orig/drivers/pci/hotplug/cpqphp_ctrl.c
+++ linux/drivers/pci/hotplug/cpqphp_ctrl.c
@@ -45,8 +45,8 @@ static int configure_new_function(struct
 			u8 behind_bridge, struct resource_lists *resources);
 static void interrupt_event_handler(struct controller *ctrl);
 
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
+static struct compat_semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct compat_semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
 static int event_finished;
 static unsigned long pushbutton_pending;	/* = 0 */
 
Index: linux/drivers/pci/hotplug/ibmphp_hpc.c
===================================================================
--- linux.orig/drivers/pci/hotplug/ibmphp_hpc.c
+++ linux/drivers/pci/hotplug/ibmphp_hpc.c
@@ -104,7 +104,7 @@ static int tid_poll;
 static struct semaphore sem_hpcaccess;	// lock access to HPC
 static struct semaphore semOperations;	// lock all operations and
 					// access to data structures
-static struct semaphore sem_exit;	// make sure polling thread goes away
+static struct compat_semaphore sem_exit;	// make sure polling thread goes away
 //----------------------------------------------------------------------------
 // local function prototypes
 //----------------------------------------------------------------------------
Index: linux/drivers/pci/hotplug/pciehp_ctrl.c
===================================================================
--- linux.orig/drivers/pci/hotplug/pciehp_ctrl.c
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c
@@ -37,8 +37,8 @@
 
 static void interrupt_event_handler(struct controller *ctrl);
 
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
+static struct compat_semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct compat_semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
 static int event_finished;
 static unsigned long pushbutton_pending;	/* = 0 */
 static unsigned long surprise_rm_pending;	/* = 0 */
Index: linux/drivers/pci/hotplug/shpchp_ctrl.c
===================================================================
--- linux.orig/drivers/pci/hotplug/shpchp_ctrl.c
+++ linux/drivers/pci/hotplug/shpchp_ctrl.c
@@ -37,8 +37,8 @@
 
 static void interrupt_event_handler(struct controller *ctrl);
 
-static struct semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
-static struct semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
+static struct compat_semaphore event_semaphore;	/* mutex for process loop (up if something to process) */
+static struct compat_semaphore event_exit;		/* guard ensure thread has exited before calling it quits */
 static int event_finished;
 static unsigned long pushbutton_pending;	/* = 0 */
 
Index: linux/drivers/scsi/aacraid/aacraid.h
===================================================================
--- linux.orig/drivers/scsi/aacraid/aacraid.h
+++ linux/drivers/scsi/aacraid/aacraid.h
@@ -735,7 +735,7 @@ struct aac_fib_context {
 	u32			unique;		// unique value representing this context
 	ulong			jiffies;	// used for cleanup - dmb changed to ulong
 	struct list_head	next;		// used to link context's into a linked list
-	struct semaphore 	wait_sem;	// this is used to wait for the next fib to arrive.
+	struct compat_semaphore	wait_sem;	// this is used to wait for the next fib to arrive.
 	int			wait;		// Set to true when thread is in WaitForSingleObject
 	unsigned long		count;		// total number of FIBs on FibList
 	struct list_head	fib_list;	// this holds fibs and their attachd hw_fibs
@@ -804,7 +804,7 @@ struct fib {
 	 *	This is the event the sendfib routine will wait on if the
 	 *	caller did not pass one and this is synch io.
 	 */
-	struct semaphore 	event_wait;
+	struct compat_semaphore	event_wait;
 	spinlock_t		event_lock;
 
 	u32			done;	/* gets set to 1 when fib is complete */
Index: linux/drivers/scsi/aic7xxx/aic79xx_osm.h
===================================================================
--- linux.orig/drivers/scsi/aic7xxx/aic79xx_osm.h
+++ linux/drivers/scsi/aic7xxx/aic79xx_osm.h
@@ -390,7 +390,7 @@ struct ahd_platform_data {
 	spinlock_t		 spin_lock;
 	u_int			 qfrozen;
 	struct timer_list	 reset_timer;
-	struct semaphore	 eh_sem;
+	struct compat_semaphore	 eh_sem;
 	struct Scsi_Host        *host;		/* pointer to scsi host */
 #define AHD_LINUX_NOIRQ	((uint32_t)~0)
 	uint32_t		 irq;		/* IRQ for this adapter */
Index: linux/drivers/scsi/aic7xxx/aic7xxx_osm.h
===================================================================
--- linux.orig/drivers/scsi/aic7xxx/aic7xxx_osm.h
+++ linux/drivers/scsi/aic7xxx/aic7xxx_osm.h
@@ -394,7 +394,7 @@ struct ahc_platform_data {
 	spinlock_t		 spin_lock;
 	u_int			 qfrozen;
 	struct timer_list	 reset_timer;
-	struct semaphore	 eh_sem;
+	struct compat_semaphore	 eh_sem;
 	struct Scsi_Host        *host;		/* pointer to scsi host */
 #define AHC_LINUX_NOIRQ	((uint32_t)~0)
 	uint32_t		 irq;		/* IRQ for this adapter */
Index: linux/drivers/scsi/qla2xxx/qla_def.h
===================================================================
--- linux.orig/drivers/scsi/qla2xxx/qla_def.h
+++ linux/drivers/scsi/qla2xxx/qla_def.h
@@ -2411,7 +2411,7 @@ typedef struct scsi_qla_host {
 	spinlock_t	mbx_reg_lock;   /* Mbx Cmd Register Lock */
 
 	struct semaphore mbx_cmd_sem;	/* Serialialize mbx access */
-	struct semaphore mbx_intr_sem;  /* Used for completion notification */
+	struct compat_semaphore mbx_intr_sem;  /* Used for completion notification */
 
 	uint32_t	mbx_flags;
 #define  MBX_IN_PROGRESS	BIT_0
Index: linux/drivers/usb/storage/usb.h
===================================================================
--- linux.orig/drivers/usb/storage/usb.h
+++ linux/drivers/usb/storage/usb.h
@@ -171,7 +171,7 @@ struct us_data {
 	dma_addr_t		iobuf_dma;
 
 	/* mutual exclusion and synchronization structures */
-	struct semaphore	sema;		 /* to sleep thread on	    */
+	struct compat_semaphore	sema;		 /* to sleep thread on	    */
 	struct completion	notify;		 /* thread begin/end	    */
 	wait_queue_head_t	delay_wait;	 /* wait during scan, reset */
 
Index: linux/fs/xfs/linux-2.6/mutex.h
===================================================================
--- linux.orig/fs/xfs/linux-2.6/mutex.h
+++ linux/fs/xfs/linux-2.6/mutex.h
@@ -28,7 +28,7 @@
  * callers.
  */
 #define MUTEX_DEFAULT		0x0
-typedef struct semaphore	mutex_t;
+typedef struct compat_semaphore	mutex_t;
 
 #define mutex_init(lock, type, name)		sema_init(lock, 1)
 #define mutex_destroy(lock)			sema_init(lock, -99)
Index: linux/fs/xfs/linux-2.6/sema.h
===================================================================
--- linux.orig/fs/xfs/linux-2.6/sema.h
+++ linux/fs/xfs/linux-2.6/sema.h
@@ -27,7 +27,7 @@
  * sema_t structure just maps to struct semaphore in Linux kernel.
  */
 
-typedef struct semaphore sema_t;
+typedef struct compat_semaphore sema_t;
 
 #define init_sema(sp, val, c, d)	sema_init(sp, val)
 #define initsema(sp, val)		sema_init(sp, val)
Index: linux/fs/xfs/linux-2.6/xfs_buf.h
===================================================================
--- linux.orig/fs/xfs/linux-2.6/xfs_buf.h
+++ linux/fs/xfs/linux-2.6/xfs_buf.h
@@ -114,7 +114,7 @@ typedef int (*page_buf_bdstrat_t)(struct
 #define PB_PAGES	2
 
 typedef struct xfs_buf {
-	struct semaphore	pb_sema;	/* semaphore for lockables  */
+	struct compat_semaphore	pb_sema;	/* semaphore for lockables  */
 	unsigned long		pb_queuetime;	/* time buffer was queued   */
 	atomic_t		pb_pin_count;	/* pin count		    */
 	wait_queue_head_t	pb_waiters;	/* unpin waiters	    */
@@ -134,7 +134,7 @@ typedef struct xfs_buf {
 	page_buf_iodone_t	pb_iodone;	/* I/O completion function */
 	page_buf_relse_t	pb_relse;	/* releasing function */
 	page_buf_bdstrat_t	pb_strat;	/* pre-write function */
-	struct semaphore	pb_iodonesema;	/* Semaphore for I/O waiters */
+	struct compat_semaphore	pb_iodonesema;	/* Semaphore for I/O waiters */
 	void			*pb_fspriv;
 	void			*pb_fspriv2;
 	void			*pb_fspriv3;
Index: linux/include/linux/jffs2_fs_i.h
===================================================================
--- linux.orig/include/linux/jffs2_fs_i.h
+++ linux/include/linux/jffs2_fs_i.h
@@ -14,7 +14,15 @@ struct jffs2_inode_info {
 	   before letting GC proceed. Or we'd have to put ugliness
 	   into the GC code so it didn't attempt to obtain the i_sem
 	   for the inode(s) which are already locked */
-	struct semaphore sem;
+	/*
+	 * (On PREEMPT_RT: while use of ei->sem is mostly mutex-alike, the
+	 * SLAB cache keeps the semaphore locked, which breaks the strict
+	 * "owner must exist" properties of rt_mutexes. Fix it the easy
+	 * way: by going to a compat_semaphore. But the real fix would be
+	 * to cache inodes in an unlocked state and lock them when
+	 * allocating a new inode.)
+	 */
+	struct compat_semaphore sem;
 
 	/* The highest (datanode) version number used for this ino */
 	uint32_t highest_version;
Index: linux/include/linux/jffs2_fs_sb.h
===================================================================
--- linux.orig/include/linux/jffs2_fs_sb.h
+++ linux/include/linux/jffs2_fs_sb.h
@@ -35,7 +35,7 @@ struct jffs2_sb_info {
 	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
+	struct compat_semaphore alloc_sem; /* Used to protect all the following
 					   fields, and also to protect against
 					   out-of-order writing of nodes. And GC. */
 	uint32_t cleanmarker_size;	/* Size of an _inline_ CLEANMARKER
@@ -93,7 +93,7 @@ struct jffs2_sb_info {
 	/* Sem to allow jffs2_garbage_collect_deletion_dirent to
 	   drop the erase_completion_lock while it's holding a pointer
 	   to an obsoleted node. I don't like this. Alternatives welcomed. */
-	struct semaphore erase_free_sem;
+	struct compat_semaphore erase_free_sem;
 
 	uint32_t wbuf_pagesize; /* 0 for NOR and other flashes with no wbuf */
 
@@ -104,7 +104,7 @@ struct jffs2_sb_info {
 	uint32_t wbuf_len;
 	struct jffs2_inodirty *wbuf_inodes;
 
-	struct rw_semaphore wbuf_sem;	/* Protects the write buffer */
+	struct compat_rw_semaphore wbuf_sem;	/* Protects the write buffer */
 
 	/* Information about out-of-band area usage... */
 	struct nand_oobinfo *oobinfo;
Index: linux/include/linux/parport.h
===================================================================
--- linux.orig/include/linux/parport.h
+++ linux/include/linux/parport.h
@@ -254,7 +254,7 @@ enum ieee1284_phase {
 struct ieee1284_info {
 	int mode;
 	volatile enum ieee1284_phase phase;
-	struct semaphore irq;
+	struct compat_semaphore irq;
 };
 
 /* A parallel port */
Index: linux/include/pcmcia/ss.h
===================================================================
--- linux.orig/include/pcmcia/ss.h
+++ linux/include/pcmcia/ss.h
@@ -243,7 +243,7 @@ struct pcmcia_socket {
 #endif
 
 	/* state thread */
-	struct semaphore		skt_sem;	/* protects socket h/w state */
+	struct compat_semaphore		skt_sem;	/* protects socket h/w state */
 
 	struct task_struct		*thread;
 	struct completion		thread_done;
Index: linux/include/scsi/scsi_transport_spi.h
===================================================================
--- linux.orig/include/scsi/scsi_transport_spi.h
+++ linux/include/scsi/scsi_transport_spi.h
@@ -51,7 +51,7 @@ struct spi_transport_attrs {
 	unsigned int support_qas; /* supports quick arbitration and selection */
 	/* Private Fields */
 	unsigned int dv_pending:1; /* Internal flag */
-	struct semaphore dv_sem; /* semaphore to serialise dv */
+	struct compat_semaphore dv_sem; /* semaphore to serialise dv */
 };
 
 enum spi_signal_type {

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  7:54   ` Ingo Molnar
@ 2005-12-13  7:58     ` Andi Kleen
  2005-12-13  8:42       ` Andrew Morton
  2005-12-13  8:00     ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Arjan van de Ven
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  7:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, David Howells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

> - i introduced a 'type-sensitive' macro wrapper that switches down() 
>   (and the other APIs) to either to the assembly variant (if the 
>   variable's type is struct compat_semaphore), or switches it to the new 
>   generic mutex (if the type is struct semaphore), at build-time. There 
>   is no runtime overhead due to this build-time-switching.

Didn't that drop compatibility with 2.95?  The necessary builtins
are only in 3.x. 

Not that I'm not in favour - I would like to use C99 everywhere 
and it would get of the ugly spinlock workaround for i386
and x86-64 doesn't support earlier compilers anyways - 
but others might not agree.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  7:54   ` Ingo Molnar
  2005-12-13  7:58     ` Andi Kleen
@ 2005-12-13  8:00     ` Arjan van de Ven
  2005-12-13  9:03       ` Ingo Molnar
  2005-12-13  9:02     ` Christoph Hellwig
  2005-12-13  9:55     ` Ingo Molnar
  3 siblings, 1 reply; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-13  8:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, David Howells, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Tue, 2005-12-13 at 08:54 +0100, Ingo Molnar wrote:
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > I'd have thought that the way to do this is to simply reimplement 
> > down(), up(), down_trylock(), etc using the new xchg-based code and to 
> > then hunt down those few parts of the kernel which actually use the 
> > old semaphore's counting feature and convert them to use down_sem(), 
> > up_sem(), etc.  And rename all the old semaphore code: 
> > s/down/down_sem/etc.
> 
> even better than that, why not use the solution that we've implemented 
> for the -rt patchset, more than a year ago?
> 
> the solution i took was this:
> 
> - i did not touch the 'struct semaphore' namespace, but introduced a
>   'struct compat_semaphore'.

which I think is wrong. THis naming sucks. Sure doing a full sed on the
tree is not pretty but it's also not THAT painful. And the pain of wrong
names is something the kernel needs to carry around for years.
> 
> - i introduced a 'type-sensitive' macro wrapper that switches down() 
>   (and the other APIs) to either to the assembly variant (if the 
>   variable's type is struct compat_semaphore), or switches it to the new 
>   generic mutex (if the type is struct semaphore), at build-time. There 
>   is no runtime overhead due to this build-time-switching.

while this is a smart trick, I rather prefer seperate functions, just so
that people are "aware" which they use. Since 99% of the users is a
mutex anyway, the new names are only used in a few special cases.



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  7:58     ` Andi Kleen
@ 2005-12-13  8:42       ` Andrew Morton
  2005-12-13  8:49         ` Andi Kleen
  2005-12-13  9:03         ` Christoph Hellwig
  0 siblings, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  8:42 UTC (permalink / raw)
  To: Andi Kleen
  Cc: mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel, linux-arch

Andi Kleen <ak@suse.de> wrote:
>
> > - i introduced a 'type-sensitive' macro wrapper that switches down() 
> >   (and the other APIs) to either to the assembly variant (if the 
> >   variable's type is struct compat_semaphore), or switches it to the new 
> >   generic mutex (if the type is struct semaphore), at build-time. There 
> >   is no runtime overhead due to this build-time-switching.
> 
> Didn't that drop compatibility with 2.95?  The necessary builtins
> are only in 3.x. 
> 
> Not that I'm not in favour - I would like to use C99 everywhere 
> and it would get of the ugly spinlock workaround for i386
> and x86-64 doesn't support earlier compilers anyways - 
> but others might not agree.
> 

2.95.x is basically buggered at present.  There's one scsi driver which
doesn't compile due to weird __VA_ARGS__ tricks and the rather useful
scsi/sd.c is currently getting an ICE.  None of the new SAS code compiles,
due to extensive use of anonymous unions.  The V4L guys are very good at
exploiting the gcc-2.95.x macro expansion bug (_why_ does each driver need
to implement its own debug macros?) and various people keep on sneaking in
anonymous unions.

It's time to give up on it and just drink more coffee or play more tetris
or something, I'm afraid.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:42       ` Andrew Morton
@ 2005-12-13  8:49         ` Andi Kleen
  2005-12-13  9:01           ` Andrew Morton
                             ` (3 more replies)
  2005-12-13  9:03         ` Christoph Hellwig
  1 sibling, 4 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  8:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andi Kleen, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

> It's time to give up on it and just drink more coffee or play more tetris
> or something, I'm afraid.

Or start using icecream (http://wiki.kde.org/icecream) 

Anyways cool.  Gratulations. Can you please apply the following patch then? 

Remove -Wdeclaration-after-statement

Now that gcc 2.95 is not supported anymore it's ok to use C99
style mixed declarations everywhere.

Signed-off-by: Andi Kleen <ak@suse.de>

Index: linux/Makefile
===================================================================
--- linux/Makefile
+++ linux/Makefile
@@ -535,9 +535,6 @@ include $(srctree)/arch/$(ARCH)/Makefile
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS     += $(NOSTDINC_FLAGS)
 
-# warn about C99 declaration after statement
-CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
-
 # disable pointer signedness warnings in gcc 4.0
 CFLAGS += $(call cc-option,-Wno-pointer-sign,)
 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:49         ` Andi Kleen
@ 2005-12-13  9:01           ` Andrew Morton
  2005-12-13  9:02             ` Andrew Morton
                               ` (2 more replies)
  2005-12-13  9:04           ` Christoph Hellwig
                             ` (2 subsequent siblings)
  3 siblings, 3 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  9:01 UTC (permalink / raw)
  To: Andi Kleen
  Cc: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

Andi Kleen <ak@suse.de> wrote:
>
> Can you please apply the following patch then? 
> 
>  Remove -Wdeclaration-after-statement

OK.

Thus far I have this:


From: Andrew Morton <akpm@osdl.org>

There's one scsi driver which doesn't compile due to weird __VA_ARGS__ tricks
and the rather useful scsi/sd.c is currently getting an ICE.  None of the new
SAS code compiles, due to extensive use of anonymous unions.  The V4L guys are
very good at exploiting the gcc-2.95.x macro expansion bug (_why_ does each
driver need to implement its own debug macros?) and various people keep on
sneaking in anonymous unions.

Plus anonymous unions are rather useful.

Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 dev/null                 |   29 -----------------------------
 include/linux/compiler.h |    2 --
 init/main.c              |    7 +------
 3 files changed, 1 insertion(+), 37 deletions(-)

diff -puN init/main.c~abandon-gcc-295x init/main.c
--- devel/init/main.c~abandon-gcc-295x	2005-12-13 00:48:17.000000000 -0800
+++ devel-akpm/init/main.c	2005-12-13 00:48:17.000000000 -0800
@@ -58,11 +58,6 @@
  * This is one of the first .c files built. Error out early
  * if we have compiler trouble..
  */
-#if __GNUC__ == 2 && __GNUC_MINOR__ == 96
-#ifdef CONFIG_FRAME_POINTER
-#error This compiler cannot compile correctly with frame pointers enabled
-#endif
-#endif
 
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/smp.h>
@@ -74,7 +69,7 @@
  * To avoid associated bogus bug reports, we flatly refuse to compile
  * with a gcc that is known to be too old from the very beginning.
  */
-#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 95)
+#if __GNUC__ < 3
 #error Sorry, your GCC is too old. It builds incorrect kernels.
 #endif
 
diff -L include/linux/compiler-gcc2.h -puN include/linux/compiler-gcc2.h~abandon-gcc-295x /dev/null
--- devel/include/linux/compiler-gcc2.h
+++ /dev/null	2003-09-15 06:40:47.000000000 -0700
@@ -1,29 +0,0 @@
-/* Never include this file directly.  Include <linux/compiler.h> instead.  */
-
-/* These definitions are for GCC v2.x.  */
-
-/* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
-   a mechanism by which the user can annotate likely branch directions and
-   expect the blocks to be reordered appropriately.  Define __builtin_expect
-   to nothing for earlier compilers.  */
-#include <linux/compiler-gcc.h>
-
-#if __GNUC_MINOR__ < 96
-# define __builtin_expect(x, expected_value) (x)
-#endif
-
-#define __attribute_used__	__attribute__((__unused__))
-
-/*
- * The attribute `pure' is not implemented in GCC versions earlier
- * than 2.96.
- */
-#if __GNUC_MINOR__ >= 96
-# define __attribute_pure__	__attribute__((pure))
-# define __attribute_const__	__attribute__((__const__))
-#endif
-
-/* GCC 2.95.x/2.96 recognize __va_copy, but not va_copy. Actually later GCC's
- * define both va_copy and __va_copy, but the latter may go away, so limit this
- * to this header */
-#define va_copy			__va_copy
diff -puN include/linux/compiler.h~abandon-gcc-295x include/linux/compiler.h
--- devel/include/linux/compiler.h~abandon-gcc-295x	2005-12-13 00:48:17.000000000 -0800
+++ devel-akpm/include/linux/compiler.h	2005-12-13 00:48:17.000000000 -0800
@@ -42,8 +42,6 @@ extern void __chk_io_ptr(void __iomem *)
 # include <linux/compiler-gcc4.h>
 #elif __GNUC__ == 3
 # include <linux/compiler-gcc3.h>
-#elif __GNUC__ == 2
-# include <linux/compiler-gcc2.h>
 #else
 # error Sorry, your compiler is too old/not recognized.
 #endif
_


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  7:54   ` Ingo Molnar
  2005-12-13  7:58     ` Andi Kleen
  2005-12-13  8:00     ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Arjan van de Ven
@ 2005-12-13  9:02     ` Christoph Hellwig
  2005-12-13  9:39       ` Ingo Molnar
  2005-12-13  9:55     ` Ingo Molnar
  3 siblings, 1 reply; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-13  9:02 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, David Howells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 08:54:41AM +0100, Ingo Molnar wrote:
> - i did not touch the 'struct semaphore' namespace, but introduced a
>   'struct compat_semaphore'.

Because it's totally brindead.  Your compat_semaphore is a real semaphore
and your semaphore is a mutex.  So name them as such.

> - i introduced a 'type-sensitive' macro wrapper that switches down() 
>   (and the other APIs) to either to the assembly variant (if the 
>   variable's type is struct compat_semaphore), or switches it to the new 
>   generic mutex (if the type is struct semaphore), at build-time. There 
>   is no runtime overhead due to this build-time-switching.

And this one is probably is a great help to win the obsfucated C contests,
but otherwise just harmfull.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:01           ` Andrew Morton
@ 2005-12-13  9:02             ` Andrew Morton
  2005-12-13 10:07               ` Jakub Jelinek
  2005-12-14 10:46               ` Russell King
  2005-12-13  9:05             ` Andi Kleen
  2005-12-13  9:11             ` Ingo Molnar
  2 siblings, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  9:02 UTC (permalink / raw)
  To: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

Andrew Morton <akpm@osdl.org> wrote:
>
> Thus far I have this:
>

And this:


From: Andrew Morton <akpm@osdl.org>

Remove various things which were checking for gcc-1.x and gcc-2.x compilers.


Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 arch/arm/kernel/asm-offsets.c     |    7 +------
 arch/arm26/kernel/asm-offsets.c   |    7 -------
 arch/ia64/kernel/head.S           |    2 +-
 arch/ia64/kernel/ia64_ksyms.c     |    2 +-
 arch/ia64/oprofile/backtrace.c    |    2 +-
 drivers/md/raid0.c                |    6 ------
 fs/xfs/xfs_log.h                  |    8 +-------
 include/asm-um/rwsem.h            |    4 ----
 include/asm-v850/unistd.h         |   18 ------------------
 include/linux/seccomp.h           |    6 +-----
 include/linux/spinlock_types_up.h |   14 --------------
 11 files changed, 6 insertions(+), 70 deletions(-)

diff -puN drivers/md/raid0.c~remove-gcc2-checks drivers/md/raid0.c
--- devel/drivers/md/raid0.c~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
+++ devel-akpm/drivers/md/raid0.c	2005-12-13 00:51:35.000000000 -0800
@@ -307,9 +307,6 @@ static int raid0_run (mddev_t *mddev)
 	printk("raid0 : conf->hash_spacing is %llu blocks.\n",
 		(unsigned long long)conf->hash_spacing);
 	{
-#if __GNUC__ < 3
-		volatile
-#endif
 		sector_t s = mddev->array_size;
 		sector_t space = conf->hash_spacing;
 		int round;
@@ -440,9 +437,6 @@ static int raid0_make_request (request_q
  
 
 	{
-#if __GNUC__ < 3
-		volatile
-#endif
 		sector_t x = block >> conf->preshift;
 		sector_div(x, (u32)conf->hash_spacing);
 		zone = conf->hash_table[x];
diff -puN fs/xfs/xfs_log.h~remove-gcc2-checks fs/xfs/xfs_log.h
--- devel/fs/xfs/xfs_log.h~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
+++ devel-akpm/fs/xfs/xfs_log.h	2005-12-13 00:52:10.000000000 -0800
@@ -30,13 +30,7 @@
  * By comparing each compnent, we don't have to worry about extra
  * endian issues in treating two 32 bit numbers as one 64 bit number
  */
-static
-#if defined(__GNUC__) && (__GNUC__ == 2) && ( (__GNUC_MINOR__ == 95) || (__GNUC_MINOR__ == 96))
-__attribute__((unused))	/* gcc 2.95, 2.96 miscompile this when inlined */
-#else
-__inline__
-#endif
-xfs_lsn_t	_lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2)
+static inline xfs_lsn_t	_lsn_cmp(xfs_lsn_t lsn1, xfs_lsn_t lsn2)
 {
 	if (CYCLE_LSN(lsn1) != CYCLE_LSN(lsn2))
 		return (CYCLE_LSN(lsn1)<CYCLE_LSN(lsn2))? -999 : 999;
diff -puN arch/arm/kernel/asm-offsets.c~remove-gcc2-checks arch/arm/kernel/asm-offsets.c
--- devel/arch/arm/kernel/asm-offsets.c~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
+++ devel-akpm/arch/arm/kernel/asm-offsets.c	2005-12-13 00:53:27.000000000 -0800
@@ -23,18 +23,13 @@
 #error Sorry, your compiler targets APCS-26 but this kernel requires APCS-32
 #endif
 /*
- * GCC 2.95.1, 2.95.2: ignores register clobber list in asm().
  * GCC 3.0, 3.1: general bad code generation.
  * GCC 3.2.0: incorrect function argument offset calculation.
  * GCC 3.2.x: miscompiles NEW_AUX_ENT in fs/binfmt_elf.c
  *            (http://gcc.gnu.org/PR8896) and incorrect structure
  *	      initialisation in fs/jffs2/erase.c
  */
-#if __GNUC__ < 2 || \
-   (__GNUC__ == 2 && __GNUC_MINOR__ < 95) || \
-   (__GNUC__ == 2 && __GNUC_MINOR__ == 95 && __GNUC_PATCHLEVEL__ != 0 && \
-					     __GNUC_PATCHLEVEL__ < 3) || \
-   (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
+#if __GNUC__ < 2 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
 #error Your compiler is too buggy; it is known to miscompile kernels.
 #error    Known good compilers: 2.95.3, 2.95.4, 2.96, 3.3
 #endif
diff -puN arch/arm26/kernel/asm-offsets.c~remove-gcc2-checks arch/arm26/kernel/asm-offsets.c
--- devel/arch/arm26/kernel/asm-offsets.c~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
+++ devel-akpm/arch/arm26/kernel/asm-offsets.c	2005-12-13 00:53:47.000000000 -0800
@@ -25,13 +25,6 @@
 #if defined(__APCS_32__) && defined(CONFIG_CPU_26)
 #error Sorry, your compiler targets APCS-32 but this kernel requires APCS-26
 #endif
-#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 95)
-#error Sorry, your compiler is known to miscompile kernels.  Only use gcc 2.95.3 and later.
-#endif
-#if __GNUC__ == 2 && __GNUC_MINOR__ == 95
-/* shame we can't detect the .1 or .2 releases */
-#warning GCC 2.95.2 and earlier miscompiles kernels.
-#endif
 
 /* Use marker if you need to separate the values later */
 
diff -puN arch/ia64/kernel/ia64_ksyms.c~remove-gcc2-checks arch/ia64/kernel/ia64_ksyms.c
--- devel/arch/ia64/kernel/ia64_ksyms.c~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
+++ devel-akpm/arch/ia64/kernel/ia64_ksyms.c	2005-12-13 00:54:02.000000000 -0800
@@ -103,7 +103,7 @@ EXPORT_SYMBOL(unw_init_running);
 
 #ifdef ASM_SUPPORTED
 # ifdef CONFIG_SMP
-#  if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
+#  if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
 /*
  * This is not a normal routine and we don't want a function descriptor for it, so we use
  * a fake declaration here.
diff -puN arch/ia64/kernel/head.S~remove-gcc2-checks arch/ia64/kernel/head.S
--- devel/arch/ia64/kernel/head.S~remove-gcc2-checks	2005-12-13 00:51:15.000000000 -0800
+++ devel-akpm/arch/ia64/kernel/head.S	2005-12-13 00:54:10.000000000 -0800
@@ -1060,7 +1060,7 @@ SET_REG(b5);
 	 * the clobber lists for spin_lock() in include/asm-ia64/spinlock.h.
 	 */
 
-#if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
+#if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
 
 GLOBAL_ENTRY(ia64_spinlock_contention_pre3_4)
 	.prologue
diff -puN arch/ia64/oprofile/backtrace.c~remove-gcc2-checks arch/ia64/oprofile/backtrace.c
--- devel/arch/ia64/oprofile/backtrace.c~remove-gcc2-checks	2005-12-13 00:51:15.000000000 -0800
+++ devel-akpm/arch/ia64/oprofile/backtrace.c	2005-12-13 00:54:16.000000000 -0800
@@ -32,7 +32,7 @@ typedef struct
 	u64 *prev_pfs_loc;	/* state for WAR for old spinlock ool code */
 } ia64_backtrace_t;
 
-#if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
+#if (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
 /*
  * Returns non-zero if the PC is in the spinlock contention out-of-line code
  * with non-standard calling sequence (on older compilers).
diff -puN include/linux/spinlock_types_up.h~remove-gcc2-checks include/linux/spinlock_types_up.h
--- devel/include/linux/spinlock_types_up.h~remove-gcc2-checks	2005-12-13 00:51:15.000000000 -0800
+++ devel-akpm/include/linux/spinlock_types_up.h	2005-12-13 00:55:14.000000000 -0800
@@ -22,30 +22,16 @@ typedef struct {
 
 #else
 
-/*
- * All gcc 2.95 versions and early versions of 2.96 have a nasty bug
- * with empty initializers.
- */
-#if (__GNUC__ > 2)
 typedef struct { } raw_spinlock_t;
 
 #define __RAW_SPIN_LOCK_UNLOCKED { }
-#else
-typedef struct { int gcc_is_buggy; } raw_spinlock_t;
-#define __RAW_SPIN_LOCK_UNLOCKED (raw_spinlock_t) { 0 }
-#endif
 
 #endif
 
-#if (__GNUC__ > 2)
 typedef struct {
 	/* no debug version on UP */
 } raw_rwlock_t;
 
 #define __RAW_RW_LOCK_UNLOCKED { }
-#else
-typedef struct { int gcc_is_buggy; } raw_rwlock_t;
-#define __RAW_RW_LOCK_UNLOCKED (raw_rwlock_t) { 0 }
-#endif
 
 #endif /* __LINUX_SPINLOCK_TYPES_UP_H */
diff -puN include/linux/seccomp.h~remove-gcc2-checks include/linux/seccomp.h
--- devel/include/linux/seccomp.h~remove-gcc2-checks	2005-12-13 00:51:15.000000000 -0800
+++ devel-akpm/include/linux/seccomp.h	2005-12-13 00:55:25.000000000 -0800
@@ -26,11 +26,7 @@ static inline int has_secure_computing(s
 
 #else /* CONFIG_SECCOMP */
 
-#if (__GNUC__ > 2)
-  typedef struct { } seccomp_t;
-#else
-  typedef struct { int gcc_is_buggy; } seccomp_t;
-#endif
+typedef struct { } seccomp_t;
 
 #define secure_computing(x) do { } while (0)
 /* static inline to preserve typechecking */
diff -puN include/asm-um/rwsem.h~remove-gcc2-checks include/asm-um/rwsem.h
--- devel/include/asm-um/rwsem.h~remove-gcc2-checks	2005-12-13 00:51:15.000000000 -0800
+++ devel-akpm/include/asm-um/rwsem.h	2005-12-13 00:55:41.000000000 -0800
@@ -1,10 +1,6 @@
 #ifndef __UM_RWSEM_H__
 #define __UM_RWSEM_H__
 
-#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 96)
-#define __builtin_expect(exp,c) (exp)
-#endif
-
 #include "asm/arch/rwsem.h"
 
 #endif
diff -puN include/asm-v850/unistd.h~remove-gcc2-checks include/asm-v850/unistd.h
--- devel/include/asm-v850/unistd.h~remove-gcc2-checks	2005-12-13 00:51:15.000000000 -0800
+++ devel-akpm/include/asm-v850/unistd.h	2005-12-13 00:56:07.000000000 -0800
@@ -241,9 +241,6 @@
 /* User programs sometimes end up including this header file
    (indirectly, via uClibc header files), so I'm a bit nervous just
    including <linux/compiler.h>.  */
-#if !defined(__builtin_expect) && __GNUC__ == 2 && __GNUC_MINOR__ < 96
-#define __builtin_expect(x, expected_value) (x)
-#endif
 
 #define __syscall_return(type, res)					      \
   do {									      \
@@ -346,20 +343,6 @@ type name (atype a, btype b, ctype c, dt
   __syscall_return (type, __ret);					      \
 }
 
-#if __GNUC__ < 3
-/* In older versions of gcc, `asm' statements with more than 10
-   input/output arguments produce a fatal error.  To work around this
-   problem, we use two versions, one for gcc-3.x and one for earlier
-   versions of gcc (the `earlier gcc' version doesn't work with gcc-3.x
-   because gcc-3.x doesn't allow clobbers to also be input arguments).  */
-#define __SYSCALL6_TRAP(syscall, ret, a, b, c, d, e, f)			      \
-  __asm__ __volatile__ ("trap " SYSCALL_LONG_TRAP			      \
-			: "=r" (ret), "=r" (syscall)			      \
-			: "1" (syscall),				      \
-			"r" (a), "r" (b), "r" (c), "r" (d),		      \
- 			"r" (e), "r" (f)				      \
-			: SYSCALL_CLOBBERS, SYSCALL_ARG4, SYSCALL_ARG5);
-#else /* __GNUC__ >= 3 */
 #define __SYSCALL6_TRAP(syscall, ret, a, b, c, d, e, f)			      \
   __asm__ __volatile__ ("trap " SYSCALL_LONG_TRAP			      \
 			: "=r" (ret), "=r" (syscall),			      \
@@ -368,7 +351,6 @@ type name (atype a, btype b, ctype c, dt
 			"r" (a), "r" (b), "r" (c), "r" (d),		      \
 			"2" (e), "3" (f)				      \
 			: SYSCALL_CLOBBERS);
-#endif
 
 #define _syscall6(type, name, atype, a, btype, b, ctype, c, dtype, d, etype, e, ftype, f) \
 type name (atype a, btype b, ctype c, dtype d, etype e, ftype f)	      \
_


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:42       ` Andrew Morton
  2005-12-13  8:49         ` Andi Kleen
@ 2005-12-13  9:03         ` Christoph Hellwig
  2005-12-13  9:14           ` Andrew Morton
  1 sibling, 1 reply; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-13  9:03 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andi Kleen, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 12:42:57AM -0800, Andrew Morton wrote:
> scsi/sd.c is currently getting an ICE.  None of the new SAS code compiles,
> due to extensive use of anonymous unions.

This is just the headers in the luben code which need redoing completely
because they're doing other stupid things like using bitfields for on the
wire structures.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:00     ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Arjan van de Ven
@ 2005-12-13  9:03       ` Ingo Molnar
  2005-12-13  9:09         ` Andi Kleen
  2005-12-13  9:19         ` Arjan van de Ven
  0 siblings, 2 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:03 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Andrew Morton, David Howells, torvalds, hch, matthew,
	linux-kernel, linux-arch

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]


* Arjan van de Ven <arjan@infradead.org> wrote:

> > even better than that, why not use the solution that we've implemented 
> > for the -rt patchset, more than a year ago?
> > 
> > the solution i took was this:
> > 
> > - i did not touch the 'struct semaphore' namespace, but introduced a
> >   'struct compat_semaphore'.
> 
> which I think is wrong. THis naming sucks. Sure doing a full sed on 
> the tree is not pretty but it's also not THAT painful. And the pain of 
> wrong names is something the kernel needs to carry around for years.

well, i'm all for renaming struct semaphore to struct mutex, but dont 
the same arguments apply as to 'struct timer_list'?

just to see the scope, i've attached semaphore-to-mutex.patch, which 
just dumbly converts all 'struct semaphore' occurances to 'struct 
mutex', against Linus-git-curr:

 405 files changed, 568 insertions(+), 568 deletions(-)

it's not _that_ bad, if done overnight. It does not touch any of the 
down/up APIs. Touching those would create a monster patch and monster 
impact.

	Ingo

[-- Attachment #2: semaphore-to-mutex.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 40881 bytes --]

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:49         ` Andi Kleen
  2005-12-13  9:01           ` Andrew Morton
@ 2005-12-13  9:04           ` Christoph Hellwig
  2005-12-13  9:13             ` Ingo Molnar
  2005-12-13 10:11             ` Jakub Jelinek
  2005-12-13  9:09           ` Ingo Molnar
  2005-12-13 16:16           ` Linus Torvalds
  3 siblings, 2 replies; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-13  9:04 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

> 
> Remove -Wdeclaration-after-statement
> 
> Now that gcc 2.95 is not supported anymore it's ok to use C99
> style mixed declarations everywhere.

Nack.  This code style is pure obsfucation and we should disallow it forever.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:01           ` Andrew Morton
  2005-12-13  9:02             ` Andrew Morton
@ 2005-12-13  9:05             ` Andi Kleen
  2005-12-13  9:15               ` Andrew Morton
  2005-12-13 22:18               ` Adrian Bunk
  2005-12-13  9:11             ` Ingo Molnar
  2 siblings, 2 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  9:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andi Kleen, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 01:01:26AM -0800, Andrew Morton wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> > Can you please apply the following patch then? 
> > 
> >  Remove -Wdeclaration-after-statement
> 
> OK.
> 
> Thus far I have this:

Would it be possible to drop support for gcc 3.0 too? 
AFAIK it has never been widely used. If we assume 3.1+ minimum it has the 
advantage that named assembly arguments work, which make
the inline assembly often a lot easier to read and maintain.

-Andi


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  2:57 ` Mark Lord
  2005-12-13  3:17   ` Steven Rostedt
@ 2005-12-13  9:06   ` Christoph Hellwig
  1 sibling, 0 replies; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-13  9:06 UTC (permalink / raw)
  To: Mark Lord
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

On Mon, Dec 12, 2005 at 09:57:40PM -0500, Mark Lord wrote:
> This will BREAK a lot of out-of-tree stuff if merged.

Well, bad luck for them.

> The simplest way would be to NOT re-use the up()/down() symbols,
> but rather to either keep them as-is (counting semaphores),
> or delete them entirely (so that external code *knows* of the change).

That I agree with actually.  Keeping the semaphore interface as-is
would simplify in-kernel transition a lot aswell and make it easier for
people to get the API read.  And the mutex symbols could get far more sensible
names like mutex_lock, mutex_unlock and mutex_trylock..

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:03       ` Ingo Molnar
@ 2005-12-13  9:09         ` Andi Kleen
  2005-12-13  9:34           ` Ingo Molnar
  2005-12-13  9:37           ` Ingo Molnar
  2005-12-13  9:19         ` Arjan van de Ven
  1 sibling, 2 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  9:09 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Arjan van de Ven, Andrew Morton, David Howells, torvalds, hch,
	matthew, linux-kernel, linux-arch

> it's not _that_ bad, if done overnight. It does not touch any of the 
> down/up APIs. Touching those would create a monster patch and monster 
> impact.

One argument for a full rename (and abandoning the old "struct semaphore"
name completely) would be that it would offer a clean break for out tree code,
no silent breakage. 

-Andi


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:49         ` Andi Kleen
  2005-12-13  9:01           ` Andrew Morton
  2005-12-13  9:04           ` Christoph Hellwig
@ 2005-12-13  9:09           ` Ingo Molnar
  2005-12-13  9:21             ` Andi Kleen
  2005-12-13 16:16           ` Linus Torvalds
  3 siblings, 1 reply; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:09 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch


* Andi Kleen <ak@suse.de> wrote:

> > It's time to give up on it and just drink more coffee or play more tetris
> > or something, I'm afraid.
> 
> Or start using icecream (http://wiki.kde.org/icecream)

distcc is pretty good too. I have a minimal kernel build done in 19 
seconds, a fuller build (1.5MB bzImage that boots on all my testboxes) 
done in 45 seconds, using gcc 4.0.2.

with the default settings, distcc wasnt saturating my boxes, the key was 
to start distccd with a longer queue size (/etc/sysconfig/distccd):

 OPTIONS="--nice 5 --jobs 128"

and to get the DISTCC_HOSTS tuning right:

 export DISTCC_HOSTS='j/16 n/120 v/40 s/13 e2/7'

in fact my distcc builds are almost as fast as a fully cached ccache 
build coming straight out of RAM ...

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:01           ` Andrew Morton
  2005-12-13  9:02             ` Andrew Morton
  2005-12-13  9:05             ` Andi Kleen
@ 2005-12-13  9:11             ` Ingo Molnar
  2 siblings, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:11 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andi Kleen, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch


* Andrew Morton <akpm@osdl.org> wrote:

> Andi Kleen <ak@suse.de> wrote:
> >
> > Can you please apply the following patch then? 
> > 
> >  Remove -Wdeclaration-after-statement
> 
> OK.
> 
> Thus far I have this:
> 
> 
> From: Andrew Morton <akpm@osdl.org>

hurray!!

This-Move-Is-Emphatically-Supported-by: Ingo Molnar <mingo@elte.hu>

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:04           ` Christoph Hellwig
@ 2005-12-13  9:13             ` Ingo Molnar
  2005-12-13 10:11             ` Jakub Jelinek
  1 sibling, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:13 UTC (permalink / raw)
  To: Christoph Hellwig, Andi Kleen, Andrew Morton, dhowells, torvalds,
	arjan, matthew, linux-kernel, linux-arch


* Christoph Hellwig <hch@infradead.org> wrote:

> > 
> > Remove -Wdeclaration-after-statement
> > 
> > Now that gcc 2.95 is not supported anymore it's ok to use C99
> > style mixed declarations everywhere.
> 
> Nack.  This code style is pure obsfucation and we should disallow it 
> forever.

agreed. I often get quilt mismerges uncovered by that warning. If 
someone wants to start a new section of code that is too large, it 
should go into a separate function.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:03         ` Christoph Hellwig
@ 2005-12-13  9:14           ` Andrew Morton
  2005-12-13  9:21             ` Christoph Hellwig
  2005-12-13 10:31             ` drivers/scsi/sd.c gcc-2.95.3 Alexey Dobriyan
  0 siblings, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  9:14 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Dec 13, 2005 at 12:42:57AM -0800, Andrew Morton wrote:
> > scsi/sd.c is currently getting an ICE.  None of the new SAS code compiles,
> > due to extensive use of anonymous unions.
> 
> This is just the headers in the luben code which need redoing completely
> because they're doing other stupid things like using bitfields for on the
> wire structures.

Don't think so (you're referring to Jeff's git-sas-jg.patch?).  It dies
with current -linus tree.


drivers/scsi/sd.c: In function `sd_read_capacity':
drivers/scsi/sd.c:1301: internal error--unrecognizable insn:
(insn 1274 1273 1797 (parallel[ 
            (set (reg:SI 0 %eax)
                (asm_operands ("") ("=a") 0[ 
                        (reg:DI 1 %edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("drivers/scsi/sd.c") 1282))
            (set (reg:SI 1 %edx)
                (asm_operands ("") ("=d") 1[ 
                        (reg:DI 1 %edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("drivers/scsi/sd.c") 1282))
        ] ) -1 (insn_list 1269 (nil))
    (nil))

It'll be workable aroundable of course, but it's a hassle.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:05             ` Andi Kleen
@ 2005-12-13  9:15               ` Andrew Morton
  2005-12-13  9:24                 ` Andi Kleen
  2005-12-13 22:18               ` Adrian Bunk
  1 sibling, 1 reply; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  9:15 UTC (permalink / raw)
  To: Andi Kleen
  Cc: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

Andi Kleen <ak@suse.de> wrote:
>
> On Tue, Dec 13, 2005 at 01:01:26AM -0800, Andrew Morton wrote:
> > Andi Kleen <ak@suse.de> wrote:
> > >
> > > Can you please apply the following patch then? 
> > > 
> > >  Remove -Wdeclaration-after-statement
> > 
> > OK.
> > 
> > Thus far I have this:
> 
> Would it be possible to drop support for gcc 3.0 too? 

Spose so - I don't know what people are using out there.

> AFAIK it has never been widely used. If we assume 3.1+ minimum it has the 
> advantage that named assembly arguments work, which make
> the inline assembly often a lot easier to read and maintain.

There are a few places in the tree which refuse to compile with 3.1 and 3.2.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:03       ` Ingo Molnar
  2005-12-13  9:09         ` Andi Kleen
@ 2005-12-13  9:19         ` Arjan van de Ven
  1 sibling, 0 replies; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-13  9:19 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, David Howells, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Tue, 2005-12-13 at 10:03 +0100, Ingo Molnar wrote:
> * Arjan van de Ven <arjan@infradead.org> wrote:
> 
> > > even better than that, why not use the solution that we've implemented 
> > > for the -rt patchset, more than a year ago?
> > > 
> > > the solution i took was this:
> > > 
> > > - i did not touch the 'struct semaphore' namespace, but introduced a
> > >   'struct compat_semaphore'.
> > 
> > which I think is wrong. THis naming sucks. Sure doing a full sed on 
> > the tree is not pretty but it's also not THAT painful. And the pain of 
> > wrong names is something the kernel needs to carry around for years.
> 
> well, i'm all for renaming struct semaphore to struct mutex, but dont 
> the same arguments apply as to 'struct timer_list'?

don't think so; this is not a "lets do them one by one over the year",
this is a "do them all right now at once" move.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:14           ` Andrew Morton
@ 2005-12-13  9:21             ` Christoph Hellwig
  2005-12-13 10:31             ` drivers/scsi/sd.c gcc-2.95.3 Alexey Dobriyan
  1 sibling, 0 replies; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-13  9:21 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Hellwig, ak, mingo, dhowells, torvalds, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 01:14:13AM -0800, Andrew Morton wrote:
> Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Dec 13, 2005 at 12:42:57AM -0800, Andrew Morton wrote:
> > > scsi/sd.c is currently getting an ICE.  None of the new SAS code compiles,
> > > due to extensive use of anonymous unions.
> > 
> > This is just the headers in the luben code which need redoing completely
> > because they're doing other stupid things like using bitfields for on the
> > wire structures.
> 
> Don't think so (you're referring to Jeff's git-sas-jg.patch?).  It dies
> with current -linus tree.

I didn't mean sd.c but the anonymous union usage.  Everything that's stuffed
into include/scsi/sas/ in -mm is far from mergeable.  It's really badly done
headers that need to be redone.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:09           ` Ingo Molnar
@ 2005-12-13  9:21             ` Andi Kleen
  0 siblings, 0 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  9:21 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andi Kleen, Andrew Morton, dhowells, torvalds, hch, arjan,
	matthew, linux-kernel, linux-arch

> > Or start using icecream (http://wiki.kde.org/icecream)
> 
> distcc is pretty good too. I have a minimal kernel build done in 19 
> seconds, a fuller build (1.5MB bzImage that boots on all my testboxes) 
> done in 45 seconds, using gcc 4.0.2.

icecream is better though - it reacts dynamically to your network
and it handles different installed compiler versions and cross compilation
nicely.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:15               ` Andrew Morton
@ 2005-12-13  9:24                 ` Andi Kleen
  2005-12-13  9:44                   ` Andrew Morton
                                     ` (2 more replies)
  0 siblings, 3 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  9:24 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andi Kleen, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

> Spose so - I don't know what people are using out there.

I don't think it was shipped in major distros at least (AFAIK) 
They all went from 2.95 to 3.1/3.2 

Perhaps stick an error for 3.0 in and wait if people are complaining? 

> 
> > AFAIK it has never been widely used. If we assume 3.1+ minimum it has the 
> > advantage that named assembly arguments work, which make
> > the inline assembly often a lot easier to read and maintain.
> 
> There are a few places in the tree which refuse to compile with 3.1 and 3.2.

Really? Which ones? 

Haven't seen that and I still use 3.2 occasionally (it's the default
compiler on SLES9 and I believe on RHEL3 too)  

-Andi


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:09         ` Andi Kleen
@ 2005-12-13  9:34           ` Ingo Molnar
  2005-12-13 14:33             ` Mark Lord
  2005-12-13  9:37           ` Ingo Molnar
  1 sibling, 1 reply; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:34 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Arjan van de Ven, Andrew Morton, David Howells, torvalds, hch,
	matthew, linux-kernel, linux-arch


* Andi Kleen <ak@suse.de> wrote:

> > it's not _that_ bad, if done overnight. It does not touch any of the 
> > down/up APIs. Touching those would create a monster patch and monster 
> > impact.
> 
> One argument for a full rename (and abandoning the old "struct 
> semaphore" name completely) would be that it would offer a clean break 
> for out tree code, no silent breakage.

yeah. Another way to handle it would be to keep 'struct semaphore' for 
the traditional semaphore type (together with the APIs), and to mark 
them deprecated. I.e. we'd have 3 separate types and 3 separate sets of 
APIs:

 'struct mutex' & APIs
 'struct semaphore' & APIs
 'struct compat_semaphore' & APIs

phase #1: we do an overnight rename to 'struct mutex' and to
          'struct compat_semaphore', based on the info that has been 
          mapped by the -rt tree. We mark 'struct semaphore' deprecated.

phase #2: we let out-of-tree code still work that uses struct 
          semaphore, but for new code applied, it must not be used.

phase #3: we remove 'struct semaphore' and APIs.

the problem with this approach is that it touches the semaphore APIs 
too, which increases the impact of the rename by a _factor of 10_. Right 
now we have ~600 places that use 'struct semaphore', but we have over 
7000 places that use the APIs! I dont think it's realistic to do an 
overnight change of all the APIs, we'd break every out-of-kernel tree in 
a massive way. (the type change alone is much more manageable)

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:09         ` Andi Kleen
  2005-12-13  9:34           ` Ingo Molnar
@ 2005-12-13  9:37           ` Ingo Molnar
  1 sibling, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:37 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Arjan van de Ven, Andrew Morton, David Howells, torvalds, hch,
	matthew, linux-kernel, linux-arch


* Andi Kleen <ak@suse.de> wrote:

> > it's not _that_ bad, if done overnight. It does not touch any of the 
> > down/up APIs. Touching those would create a monster patch and monster 
> > impact.
> 
> One argument for a full rename (and abandoning the old "struct 
> semaphore" name completely) would be that it would offer a clean break 
> for out tree code, no silent breakage.

btw., in the -rt tree we rarely had 'silent breakage' - roughly 80% of 
the cases were caught build-time: we eliminated DECLARE_MUTEX_LOCKED, 
which is a clear sign for non-mutex semaphore usage. Another 19% was 
caught by runtime checks: 'does owner unlock the mutex'. The remaining 
1% was breakage that was not found quickly.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:02     ` Christoph Hellwig
@ 2005-12-13  9:39       ` Ingo Molnar
  2005-12-13 10:00         ` Ingo Molnar
  0 siblings, 1 reply; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:39 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, David Howells, torvalds, arjan,
	matthew, linux-kernel, linux-arch


* Christoph Hellwig <hch@infradead.org> wrote:

> On Tue, Dec 13, 2005 at 08:54:41AM +0100, Ingo Molnar wrote:
> > - i did not touch the 'struct semaphore' namespace, but introduced a
> >   'struct compat_semaphore'.
> 
> Because it's totally braindead.  Your compat_semaphore is a real 
> semaphore and your semaphore is a mutex.  So name them as such.

well, i had the choice between a 30K patch, a 300K patch and a 3000K 
patch. I went for the 30K patch ;-)

> > - i introduced a 'type-sensitive' macro wrapper that switches down() 
> >   (and the other APIs) to either to the assembly variant (if the 
> >   variable's type is struct compat_semaphore), or switches it to the new 
> >   generic mutex (if the type is struct semaphore), at build-time. There 
> >   is no runtime overhead due to this build-time-switching.
> 
> And this one is probably is a great help to win the obsfucated C 
> contests, but otherwise just harmfull.

i never found it to be harmful in any way, and we've now got a year of 
experience with them. Could you elaborate?

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:24                 ` Andi Kleen
@ 2005-12-13  9:44                   ` Andrew Morton
  2005-12-13  9:49                     ` Andi Kleen
  2005-12-13 10:28                   ` Andreas Schwab
  2005-12-13 12:33                   ` Matthew Wilcox
  2 siblings, 1 reply; 249+ messages in thread
From: Andrew Morton @ 2005-12-13  9:44 UTC (permalink / raw)
  To: Andi Kleen
  Cc: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

Andi Kleen <ak@suse.de> wrote:
>
> > There are a few places in the tree which refuse to compile with 3.1 and 3.2.
> 
>  Really? Which ones? 

grep for __GNUC_MINOR__

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:44                   ` Andrew Morton
@ 2005-12-13  9:49                     ` Andi Kleen
  0 siblings, 0 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13  9:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andi Kleen, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 01:44:37AM -0800, Andrew Morton wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> > > There are a few places in the tree which refuse to compile with 3.1 and 3.2.
> > 
> >  Really? Which ones? 
> 
> grep for __GNUC_MINOR__

I reviewed them and I didn't find any that refused 3.2 or 3.3.

Some architectures have special code for old gccs, but nothing
generic.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (23 preceding siblings ...)
  2005-12-13  2:57 ` Mark Lord
@ 2005-12-13  9:54 ` David Howells
  2005-12-13 10:13   ` Ingo Molnar
                     ` (2 more replies)
  2005-12-13 10:48 ` David Howells
                   ` (7 subsequent siblings)
  32 siblings, 3 replies; 249+ messages in thread
From: David Howells @ 2005-12-13  9:54 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> We have atomic_cmpxchg. Can you use that for a sufficient generic
> implementation?

No. CMPXCHG/CAS is not as available as XCHG, and it's also unnecessary.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  7:54   ` Ingo Molnar
                       ` (2 preceding siblings ...)
  2005-12-13  9:02     ` Christoph Hellwig
@ 2005-12-13  9:55     ` Ingo Molnar
  3 siblings, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13  9:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Howells, torvalds, hch, arjan, matthew, linux-kernel, linux-arch

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]


* Ingo Molnar <mingo@elte.hu> wrote:

> all this simplified the 'compatibility conversion' to the patch below.  
> No other non-generic changes are needed.

there were 3 more patches needed, which convert some semaphores to 
completions:

 sx8-sem2completions.patch
 cpu5wdt-sem2completions.patch
 ide-gendev-sem-to-completion.patch

all attached.

	Ingo

[-- Attachment #2: sx8-sem2completions.patch --]
[-- Type: text/plain, Size: 1526 bytes --]

 drivers/block/sx8.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

Index: linux/drivers/block/sx8.c
===================================================================
--- linux.orig/drivers/block/sx8.c
+++ linux/drivers/block/sx8.c
@@ -27,6 +27,7 @@
 #include <linux/time.h>
 #include <linux/hdreg.h>
 #include <linux/dma-mapping.h>
+#include <linux/completion.h>
 #include <asm/io.h>
 #include <asm/semaphore.h>
 #include <asm/uaccess.h>
@@ -303,7 +304,7 @@ struct carm_host {
 
 	struct work_struct		fsm_task;
 
-	struct semaphore		probe_sem;
+	struct completion		probe_comp;
 };
 
 struct carm_response {
@@ -1365,7 +1366,7 @@ static void carm_fsm_task (void *_data)
 	}
 
 	case HST_PROBE_FINISHED:
-		up(&host->probe_sem);
+		complete(&host->probe_comp);
 		break;
 
 	case HST_ERROR:
@@ -1641,7 +1642,7 @@ static int carm_init_one (struct pci_dev
 	host->flags = pci_dac ? FL_DAC : 0;
 	spin_lock_init(&host->lock);
 	INIT_WORK(&host->fsm_task, carm_fsm_task, host);
-	init_MUTEX_LOCKED(&host->probe_sem);
+	init_completion(&host->probe_comp);
 
 	for (i = 0; i < ARRAY_SIZE(host->req); i++)
 		host->req[i].tag = i;
@@ -1710,8 +1711,8 @@ static int carm_init_one (struct pci_dev
 	if (rc)
 		goto err_out_free_irq;
 
-	DPRINTK("waiting for probe_sem\n");
-	down(&host->probe_sem);
+	DPRINTK("waiting for probe_comp\n");
+	wait_for_completion(&host->probe_comp);
 
 	printk(KERN_INFO "%s: pci %s, ports %d, io %lx, irq %u, major %d\n",
 	       host->name, pci_name(pdev), (int) CARM_MAX_PORTS,

[-- Attachment #3: cpu5wdt-sem2completions.patch --]
[-- Type: text/plain, Size: 1419 bytes --]

 drivers/char/watchdog/cpu5wdt.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

Index: linux/drivers/char/watchdog/cpu5wdt.c
===================================================================
--- linux.orig/drivers/char/watchdog/cpu5wdt.c
+++ linux/drivers/char/watchdog/cpu5wdt.c
@@ -28,6 +28,7 @@
 #include <linux/init.h>
 #include <linux/ioport.h>
 #include <linux/timer.h>
+#include <linux/completion.h>
 #include <linux/jiffies.h>
 #include <asm/io.h>
 #include <asm/uaccess.h>
@@ -57,7 +58,7 @@ static int ticks = 10000;
 /* some device data */
 
 static struct {
-	struct semaphore stop;
+	struct completion stop;
 	volatile int running;
 	struct timer_list timer;
 	volatile int queue;
@@ -85,7 +86,7 @@ static void cpu5wdt_trigger(unsigned lon
 	}
 	else {
 		/* ticks doesn't matter anyway */
-		up(&cpu5wdt_device.stop);
+		complete(&cpu5wdt_device.stop);
 	}
 
 }
@@ -239,7 +240,7 @@ static int __devinit cpu5wdt_init(void)
 	if ( !val )
 		printk(KERN_INFO PFX "sorry, was my fault\n");
 
-	init_MUTEX_LOCKED(&cpu5wdt_device.stop);
+	init_completion(&cpu5wdt_device.stop);
 	cpu5wdt_device.queue = 0;
 
 	clear_bit(0, &cpu5wdt_device.inuse);
@@ -269,7 +270,7 @@ static void __devexit cpu5wdt_exit(void)
 {
 	if ( cpu5wdt_device.queue ) {
 		cpu5wdt_device.queue = 0;
-		down(&cpu5wdt_device.stop);
+		wait_for_completion(&cpu5wdt_device.stop);
 	}
 
 	misc_deregister(&cpu5wdt_misc);

[-- Attachment #4: ide-gendev-sem-to-completion.patch --]
[-- Type: text/plain, Size: 3535 bytes --]

The following patch is from Montavista.  I modified it slightly.
Semaphores are currently being used where it makes more sense for
completions.  This patch corrects that.

-- Steve

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Source: MontaVista Software, Inc.
Signed-off-by: Aleksey Makarov <amakarov@ru.mvista.com>
Description:
	The patch changes semaphores that are initialized as 
	locked to complete().

 drivers/ide/ide-probe.c |    4 ++--
 drivers/ide/ide.c       |    8 ++++----
 include/linux/ide.h     |    5 +++--
 3 files changed, 9 insertions(+), 8 deletions(-)

Index: linux/drivers/ide/ide-probe.c
===================================================================
--- linux.orig/drivers/ide/ide-probe.c
+++ linux/drivers/ide/ide-probe.c
@@ -655,7 +655,7 @@ static void hwif_release_dev (struct dev
 {
 	ide_hwif_t *hwif = container_of(dev, ide_hwif_t, gendev);
 
-	up(&hwif->gendev_rel_sem);
+	complete(&hwif->gendev_rel_comp);
 }
 
 static void hwif_register (ide_hwif_t *hwif)
@@ -1325,7 +1325,7 @@ static void drive_release_dev (struct de
 	drive->queue = NULL;
 	spin_unlock_irq(&ide_lock);
 
-	up(&drive->gendev_rel_sem);
+	complete(&drive->gendev_rel_comp);
 }
 
 /*
Index: linux/drivers/ide/ide.c
===================================================================
--- linux.orig/drivers/ide/ide.c
+++ linux/drivers/ide/ide.c
@@ -222,7 +222,7 @@ static void init_hwif_data(ide_hwif_t *h
 	hwif->mwdma_mask = 0x80;	/* disable all mwdma */
 	hwif->swdma_mask = 0x80;	/* disable all swdma */
 
-	sema_init(&hwif->gendev_rel_sem, 0);
+	init_completion(&hwif->gendev_rel_comp);
 
 	default_hwif_iops(hwif);
 	default_hwif_transport(hwif);
@@ -245,7 +245,7 @@ static void init_hwif_data(ide_hwif_t *h
 		drive->is_flash			= 0;
 		drive->vdma			= 0;
 		INIT_LIST_HEAD(&drive->list);
-		sema_init(&drive->gendev_rel_sem, 0);
+		init_completion(&drive->gendev_rel_comp);
 	}
 }
 
@@ -602,7 +602,7 @@ void ide_unregister(unsigned int index)
 		}
 		spin_unlock_irq(&ide_lock);
 		device_unregister(&drive->gendev);
-		down(&drive->gendev_rel_sem);
+		wait_for_completion(&drive->gendev_rel_comp);
 		spin_lock_irq(&ide_lock);
 	}
 	hwif->present = 0;
@@ -662,7 +662,7 @@ void ide_unregister(unsigned int index)
 	/* More messed up locking ... */
 	spin_unlock_irq(&ide_lock);
 	device_unregister(&hwif->gendev);
-	down(&hwif->gendev_rel_sem);
+	wait_for_completion(&hwif->gendev_rel_comp);
 
 	/*
 	 * Remove us from the kernel's knowledge
Index: linux/include/linux/ide.h
===================================================================
--- linux.orig/include/linux/ide.h
+++ linux/include/linux/ide.h
@@ -18,6 +18,7 @@
 #include <linux/bio.h>
 #include <linux/device.h>
 #include <linux/pci.h>
+#include <linux/completion.h>
 #include <asm/byteorder.h>
 #include <asm/system.h>
 #include <asm/io.h>
@@ -759,7 +760,7 @@ typedef struct ide_drive_s {
 	int		crc_count;	/* crc counter to reduce drive speed */
 	struct list_head list;
 	struct device	gendev;
-	struct semaphore gendev_rel_sem;	/* to deal with device release() */
+	struct completion gendev_rel_comp;	/* to deal with device release() */
 } ide_drive_t;
 
 #define to_ide_device(dev)container_of(dev, ide_drive_t, gendev)
@@ -915,7 +916,7 @@ typedef struct hwif_s {
 	unsigned	sg_mapped  : 1;	/* sg_table and sg_nents are ready */
 
 	struct device	gendev;
-	struct semaphore gendev_rel_sem; /* To deal with device release() */
+	struct completion gendev_rel_comp; /* To deal with device release() */
 
 	void		*hwif_data;	/* extra hwif data */
 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:39       ` Ingo Molnar
@ 2005-12-13 10:00         ` Ingo Molnar
  2005-12-13 17:40           ` Paul Jackson
  2005-12-13 18:34           ` David Howells
  0 siblings, 2 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 10:00 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, David Howells, torvalds, arjan,
	matthew, linux-kernel, linux-arch


* Ingo Molnar <mingo@elte.hu> wrote:

> > On Tue, Dec 13, 2005 at 08:54:41AM +0100, Ingo Molnar wrote:
> > > - i did not touch the 'struct semaphore' namespace, but introduced a
> > >   'struct compat_semaphore'.
> > 
> > Because it's totally braindead.  Your compat_semaphore is a real 
> > semaphore and your semaphore is a mutex.  So name them as such.
> 
> well, i had the choice between a 30K patch, a 300K patch and a 3000K 
> patch. I went for the 30K patch ;-)

in that sense i'm all for going for the 300K patch, which is roughly the 
direction David is heading into: rename to 'struct mutex' but keep the 
down/up APIs, and introduce sem_down()/sem_up()/ for the cases that need 
full semaphores.

i dont think the 3000K patch (full API rename, introduction of 
mutex_down()/mutex_up()) is realistic.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:02             ` Andrew Morton
@ 2005-12-13 10:07               ` Jakub Jelinek
  2005-12-13 10:11                 ` Andi Kleen
  2005-12-14 10:46               ` Russell King
  1 sibling, 1 reply; 249+ messages in thread
From: Jakub Jelinek @ 2005-12-13 10:07 UTC (permalink / raw)
  To: Andrew Morton
  Cc: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

On Tue, Dec 13, 2005 at 01:02:33AM -0800, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Thus far I have this:
> >
> 
> And this:
> 
> 
> From: Andrew Morton <akpm@osdl.org>
> 
> Remove various things which were checking for gcc-1.x and gcc-2.x compilers.

> --- devel/arch/arm/kernel/asm-offsets.c~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
> +++ devel-akpm/arch/arm/kernel/asm-offsets.c	2005-12-13 00:53:27.000000000 -0800
> @@ -23,18 +23,13 @@
>  #error Sorry, your compiler targets APCS-26 but this kernel requires APCS-32
>  #endif
>  /*
> - * GCC 2.95.1, 2.95.2: ignores register clobber list in asm().
>   * GCC 3.0, 3.1: general bad code generation.
>   * GCC 3.2.0: incorrect function argument offset calculation.
>   * GCC 3.2.x: miscompiles NEW_AUX_ENT in fs/binfmt_elf.c
>   *            (http://gcc.gnu.org/PR8896) and incorrect structure
>   *	      initialisation in fs/jffs2/erase.c
>   */
> -#if __GNUC__ < 2 || \
> -   (__GNUC__ == 2 && __GNUC_MINOR__ < 95) || \
> -   (__GNUC__ == 2 && __GNUC_MINOR__ == 95 && __GNUC_PATCHLEVEL__ != 0 && \
> -					     __GNUC_PATCHLEVEL__ < 3) || \
> -   (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
> +#if __GNUC__ < 2 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
>  #error Your compiler is too buggy; it is known to miscompile kernels.
>  #error    Known good compilers: 2.95.3, 2.95.4, 2.96, 3.3
>  #endif

Guess

#if __GNUC__ == 3 && __GNUC_MINOR__ < 3
#error Your compiler is too buggy; it is known to miscompile kernels.
#error    Known good compilers: 3.3, 3.4, 4.0
#endif

would be better.  __GNUC__ < 2 will certainly be errored about in other
places and it is bad to suggest compilers that are no longer supported
as known good ones.

	Jakub

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:04           ` Christoph Hellwig
  2005-12-13  9:13             ` Ingo Molnar
@ 2005-12-13 10:11             ` Jakub Jelinek
  2005-12-13 10:19               ` Christoph Hellwig
  1 sibling, 1 reply; 249+ messages in thread
From: Jakub Jelinek @ 2005-12-13 10:11 UTC (permalink / raw)
  To: Christoph Hellwig, Andi Kleen, Andrew Morton, mingo, dhowells,
	torvalds, arjan, matthew, linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 09:04:29AM +0000, Christoph Hellwig wrote:
> > 
> > Remove -Wdeclaration-after-statement
> > 
> > Now that gcc 2.95 is not supported anymore it's ok to use C99
> > style mixed declarations everywhere.
> 
> Nack.  This code style is pure obsfucation and we should disallow it forever.

Why?  It greatly increases readability when variable declarations can be
moved close to their actual uses.  glibc changed a lot of its codebase
this way and from my experience it really helps.

	Jakub

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:07               ` Jakub Jelinek
@ 2005-12-13 10:11                 ` Andi Kleen
  2005-12-13 10:15                   ` Jakub Jelinek
  2005-12-13 10:25                   ` Andrew Morton
  0 siblings, 2 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13 10:11 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Andrew Morton, ak, mingo, dhowells, torvalds, hch, arjan,
	matthew, linux-kernel, linux-arch

> Guess
> 
> #if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> #error Your compiler is too buggy; it is known to miscompile kernels.
> #error    Known good compilers: 3.3, 3.4, 4.0
> #endif
> 
> would be better.  __GNUC__ < 2 will certainly be errored about in other
> places and it is bad to suggest compilers that are no longer supported
> as known good ones.

Are there really any known serious miscompilation with 3.1/3.2?  
(I knew it used to miscompile some loops on x86-64, but I think I worked
around all that) 

Preventing SLES9 and RHEL3 users from easily compiling new kernels
isn't good.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:54 ` David Howells
@ 2005-12-13 10:13   ` Ingo Molnar
  2005-12-13 10:34     ` Ingo Molnar
  2005-12-14  1:00   ` Nick Piggin
  2005-12-14 10:54   ` David Howells
  2 siblings, 1 reply; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 10:13 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch


* David Howells <dhowells@redhat.com> wrote:

> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> > We have atomic_cmpxchg. Can you use that for a sufficient generic
> > implementation?
> 
> No. CMPXCHG/CAS is not as available as XCHG, and it's also unnecessary.

take a look at the PREEMPT_RT implementation of mutexes: it uses 
cmpxchg(), and thus both the down() and the up() fastpath is lockless!  
(And that is a mutex type that does alot more things, as it supports 
priority inheritance.)

architectures which dont have cmpxchg can use a spinlock just fine.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:11                 ` Andi Kleen
@ 2005-12-13 10:15                   ` Jakub Jelinek
  2005-12-13 10:25                   ` Andrew Morton
  1 sibling, 0 replies; 249+ messages in thread
From: Jakub Jelinek @ 2005-12-13 10:15 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 11:11:53AM +0100, Andi Kleen wrote:
> > Guess
> > 
> > #if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> > #error Your compiler is too buggy; it is known to miscompile kernels.
> > #error    Known good compilers: 3.3, 3.4, 4.0
> > #endif
> > 
> > would be better.  __GNUC__ < 2 will certainly be errored about in other
> > places and it is bad to suggest compilers that are no longer supported
> > as known good ones.
> 
> Are there really any known serious miscompilation with 3.1/3.2?  
> (I knew it used to miscompile some loops on x86-64, but I think I worked
> around all that) 
> 
> Preventing SLES9 and RHEL3 users from easily compiling new kernels
> isn't good.

The above is ARM solely, the comment there mentions some ARM postreload bug
that was only fixed in 3.3+.
I'd say 3.2 should be generally supported for the time being on arches
where there weren't significant problems with it.

	Jakub

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:11             ` Jakub Jelinek
@ 2005-12-13 10:19               ` Christoph Hellwig
  2005-12-13 10:27                 ` Ingo Molnar
  2005-12-15  4:53                 ` Miles Bader
  0 siblings, 2 replies; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-13 10:19 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Christoph Hellwig, Andi Kleen, Andrew Morton, mingo, dhowells,
	torvalds, arjan, matthew, linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 05:11:41AM -0500, Jakub Jelinek wrote:
> On Tue, Dec 13, 2005 at 09:04:29AM +0000, Christoph Hellwig wrote:
> > > 
> > > Remove -Wdeclaration-after-statement
> > > 
> > > Now that gcc 2.95 is not supported anymore it's ok to use C99
> > > style mixed declarations everywhere.
> > 
> > Nack.  This code style is pure obsfucation and we should disallow it forever.
> 
> Why?  It greatly increases readability when variable declarations can be
> moved close to their actual uses.  glibc changed a lot of its codebase
> this way and from my experience it really helps.

mentioning glibc and readability in the same sentence disqualies your here,
sorry ;-)

But serious, having to look all over the source instead of just a block
beginning decreases code readability a lot.  And if you have to scroll more
than a page to the block beginning on a 80x24 terminal means the code needs
a refactoring anyway.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:11                 ` Andi Kleen
  2005-12-13 10:15                   ` Jakub Jelinek
@ 2005-12-13 10:25                   ` Andrew Morton
  1 sibling, 0 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-13 10:25 UTC (permalink / raw)
  To: Andi Kleen
  Cc: jakub, ak, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

Andi Kleen <ak@suse.de> wrote:
>
> > Guess
> > 
> > #if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> > #error Your compiler is too buggy; it is known to miscompile kernels.
> > #error    Known good compilers: 3.3, 3.4, 4.0
> > #endif
> > 
> > would be better.  __GNUC__ < 2 will certainly be errored about in other
> > places and it is bad to suggest compilers that are no longer supported
> > as known good ones.
> 
> Are there really any known serious miscompilation with 3.1/3.2?  
> (I knew it used to miscompile some loops on x86-64, but I think I worked
> around all that) 
> 
> Preventing SLES9 and RHEL3 users from easily compiling new kernels
> isn't good.
> 

3.2.1 works OK on x86.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:19               ` Christoph Hellwig
@ 2005-12-13 10:27                 ` Ingo Molnar
  2005-12-15  4:53                 ` Miles Bader
  1 sibling, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 10:27 UTC (permalink / raw)
  To: Christoph Hellwig, Jakub Jelinek, Andi Kleen, Andrew Morton,
	dhowells, torvalds, arjan, matthew, linux-kernel, linux-arch


* Christoph Hellwig <hch@infradead.org> wrote:

> On Tue, Dec 13, 2005 at 05:11:41AM -0500, Jakub Jelinek wrote:
> > On Tue, Dec 13, 2005 at 09:04:29AM +0000, Christoph Hellwig wrote:
> > > > 
> > > > Remove -Wdeclaration-after-statement
> > > > 
> > > > Now that gcc 2.95 is not supported anymore it's ok to use C99
> > > > style mixed declarations everywhere.
> > > 
> > > Nack.  This code style is pure obsfucation and we should disallow it forever.
> > 
> > Why?  It greatly increases readability when variable declarations can be
> > moved close to their actual uses.  glibc changed a lot of its codebase
> > this way and from my experience it really helps.
> 
> mentioning glibc and readability in the same sentence disqualies your 
> here, sorry ;-)

it's a different coding style, but otherwise i find glibc highly 
readable and well-maintained. It is also a more mature piece of code 
than say the kernel, e.g. API-wise, so we could indeed learn a few 
things. Just consider the fact that glibc has 10 times more APIs than 
the kernel, and still it is breaking apps less often than the kernel.  
But i digress :-)

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:24                 ` Andi Kleen
  2005-12-13  9:44                   ` Andrew Morton
@ 2005-12-13 10:28                   ` Andreas Schwab
  2005-12-13 10:30                     ` Andi Kleen
  2005-12-13 12:33                   ` Matthew Wilcox
  2 siblings, 1 reply; 249+ messages in thread
From: Andreas Schwab @ 2005-12-13 10:28 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

Andi Kleen <ak@suse.de> writes:

> Haven't seen that and I still use 3.2 occasionally (it's the default
> compiler on SLES9 and I believe on RHEL3 too)  

SLES9 has 3.3-hammer.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:28                   ` Andreas Schwab
@ 2005-12-13 10:30                     ` Andi Kleen
  0 siblings, 0 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13 10:30 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Andi Kleen, Andrew Morton, mingo, dhowells, torvalds, hch, arjan,
	matthew, linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 11:28:41AM +0100, Andreas Schwab wrote:
> Andi Kleen <ak@suse.de> writes:
> 
> > Haven't seen that and I still use 3.2 occasionally (it's the default
> > compiler on SLES9 and I believe on RHEL3 too)  
> 
> SLES9 has 3.3-hammer.

You're right - i meant to write SLES8 where 3.2 was default.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* drivers/scsi/sd.c gcc-2.95.3
  2005-12-13  9:14           ` Andrew Morton
  2005-12-13  9:21             ` Christoph Hellwig
@ 2005-12-13 10:31             ` Alexey Dobriyan
  1 sibling, 0 replies; 249+ messages in thread
From: Alexey Dobriyan @ 2005-12-13 10:31 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Christoph Hellwig, ak, mingo, dhowells, torvalds, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 01:14:13AM -0800, Andrew Morton wrote:
> drivers/scsi/sd.c: In function `sd_read_capacity':
> drivers/scsi/sd.c:1301: internal error--unrecognizable insn:
> (insn 1274 1273 1797 (parallel[ 
>             (set (reg:SI 0 %eax)
>                 (asm_operands ("") ("=a") 0[ 
>                         (reg:DI 1 %edx)
>                     ] 
>                     [ 
>                         (asm_input:DI ("A"))
>                     ]  ("drivers/scsi/sd.c") 1282))
>             (set (reg:SI 1 %edx)
>                 (asm_operands ("") ("=d") 1[ 
>                         (reg:DI 1 %edx)
>                     ] 
>                     [ 
>                         (asm_input:DI ("A"))
>                     ]  ("drivers/scsi/sd.c") 1282))
>         ] ) -1 (insn_list 1269 (nil))
>     (nil))
> 
> It'll be workable aroundable of course, but it's a hassle.

FWIW,

--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1282,9 +1282,9 @@ got_data:
 		sector_div(mb, 1950);
 
 		printk(KERN_NOTICE "SCSI device %s: "
-		       "%llu %d-byte hdwr sectors (%llu MB)\n",
+		       "%llu %d-byte hdwr sectors\n",
 		       diskname, (unsigned long long)sdkp->capacity,
-		       hard_sector, (unsigned long long)mb);
+		       hard_sector);
 	}
 
 	/* Rescale capacity to 512-byte units */


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:13   ` Ingo Molnar
@ 2005-12-13 10:34     ` Ingo Molnar
  2005-12-13 10:37       ` Ingo Molnar
  2005-12-13 12:47       ` Oliver Neukum
  0 siblings, 2 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 10:34 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch


* Ingo Molnar <mingo@elte.hu> wrote:

> > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > 
> > > We have atomic_cmpxchg. Can you use that for a sufficient generic
> > > implementation?
> > 
> > No. CMPXCHG/CAS is not as available as XCHG, and it's also unnecessary.
> 
> take a look at the PREEMPT_RT implementation of mutexes: it uses 
> cmpxchg(), and thus both the down() and the up() fastpath is lockless!  
> (And that is a mutex type that does alot more things, as it supports 
> priority inheritance.)
> 
> architectures which dont have cmpxchg can use a spinlock just fine.

the cost of a spinlock-based generic_cmpxchg could be significantly 
reduced by adding a generic_cmpxchg() variant that also includes a 
'spinlock pointer' parameter.

Architectures that do not have the instruction, can use the specified 
spinlock to do the cmpxchg. This means that there wont be one single 
global spinlock to emulate cmpxchg, but the mutex's own spinlock can be 
used for it.

Architectures that have the cmpxchg instruction would simply ignore the 
parameter, and would incur no overhead.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:34     ` Ingo Molnar
@ 2005-12-13 10:37       ` Ingo Molnar
  2005-12-13 12:47       ` Oliver Neukum
  1 sibling, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 10:37 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch


* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > > 
> > > > We have atomic_cmpxchg. Can you use that for a sufficient generic
> > > > implementation?
> > > 
> > > No. CMPXCHG/CAS is not as available as XCHG, and it's also unnecessary.
> > 
> > take a look at the PREEMPT_RT implementation of mutexes: it uses 
> > cmpxchg(), and thus both the down() and the up() fastpath is lockless!  
> > (And that is a mutex type that does alot more things, as it supports 
> > priority inheritance.)
> > 
> > architectures which dont have cmpxchg can use a spinlock just fine.
> 
> the cost of a spinlock-based generic_cmpxchg could be significantly 
> reduced by adding a generic_cmpxchg() variant that also includes a 
> 'spinlock pointer' parameter.
> 
> Architectures that do not have the instruction, can use the specified 
> spinlock to do the cmpxchg. This means that there wont be one single 
> global spinlock to emulate cmpxchg, but the mutex's own spinlock can 
> be used for it.
> 
> Architectures that have the cmpxchg instruction would simply ignore 
> the parameter, and would incur no overhead.

an additional twist: we could add generic_cmpxchg_lock(), which would 
return the spinlock locked if the cmpxchg fails. (this is what we want 
to do anyway) This way architectures that dont have CMPXCHG would take 
the spinlock unconditionally and do the cmp-xchg emulation, while the 
other architectures would take it only if the cmpxchg fails.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (24 preceding siblings ...)
  2005-12-13  9:54 ` David Howells
@ 2005-12-13 10:48 ` David Howells
  2005-12-13 12:39   ` Matthew Wilcox
  2005-12-13 10:54 ` Ingo Molnar
                   ` (6 subsequent siblings)
  32 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-13 10:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Howells, torvalds, hch, arjan, matthew, mingo,
	linux-kernel, linux-arch

Andrew Morton <akpm@osdl.org> wrote:

> Maybe I'm not understanding all this, but...
> 
> I'd have thought that the way to do this is to simply reimplement down(),
> up(), down_trylock(), etc using the new xchg-based code

Which I did.

> and to then hunt down those few parts of the kernel which actually use the
> old semaphore's counting feature and convert them to use down_sem(),
> up_sem(), etc.

Done, I think. It's not always 100% obvious.

> And rename all the old semaphore code: s/down/down_sem/etc.

Done.

> So after such a transformation, this new "mutex" thingy would not exist.

Why not? I want to make them different types so that you can't use the wrong
operators by accident or mix them.

> >  include/linux/mutex.h        |   32 +++++++
> 
> But it does.

Well, I could fold this into each asm/semaphore.h.

> > +#define mutex_grab(mutex)	(xchg(&(mutex)->state, 1) == 0)
> 
> mutex_trylock(), please.

You're right.

> > +#define is_mutex_locked(mutex)	((mutex)->state)
> 
> Let's keep the namespace consistent.  mutex_is_locked().

But that's a poor name: it turns it from a question into a statement:-(

> > +static inline void down(struct mutex *mutex)
> > +{
> > +	if (mutex_grab(mutex)) {
> 
> likely()

No... down_trylock().

> > +static inline int down_interruptible(struct mutex *mutex)
> > +{
> > +	if (mutex_grab(mutex)) {
> 
> likely()

down_trylock() again.

> > +static inline int down_trylock(struct mutex *mutex)
> > +{
> > +	if (mutex_grab(mutex)) {
> 
> etc.

Yes.

> You could just put likely() into mutex_trylock().  err, mutex_grab().
> 
> > +/*
> > + * release the mutex
> > + */
> > +static inline void up(struct mutex *mutex)
> > +{
> > +	unsigned long flags;
> > +
> > +#ifdef CONFIG_DEBUG_MUTEX_OWNER
> > +	if (mutex->__owner != current)
> > +		__up_bad(mutex);
> > +	mutex->__owner = NULL;
> > +#endif
> > +
> > +	/* must prevent a race */
> > +	spin_lock_irqsave(&mutex->wait_lock, flags);
> > +	if (!list_empty(&mutex->wait_list))
> > +		__up(mutex);
> > +	else
> > +		mutex_release(mutex);
> > +	spin_unlock_irqrestore(&mutex->wait_lock, flags);
> > +}
> 
> This is too large to inline.

You're probably right.

> It's also significantly slower than the existing up()?

Hmmm... If you've only got two states available to you and/or you can only
exchange states, then there's a limit to what you can actually do. You can lose
the spinlock in the up() fastpath if you're willing to forgo fairness or resort
to waking up processes superfluously.

Ingo and Nick have a point about using CMPXCHG or equivalent if it's
available. This lets you modify the state you have, rather than swapping it for
a whole new state; in which case the state can be annotated to indicate that
there is waking up to be done, thus permitting the fast path to be much
faster. But this can only be done in the case where the state may be modified.

As I tried to make clear: this is the simplest I could come up with, but I have
made provision for overriding it with something better if that's possible.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (25 preceding siblings ...)
  2005-12-13 10:48 ` David Howells
@ 2005-12-13 10:54 ` Ingo Molnar
  2005-12-13 11:23 ` David Howells
                   ` (5 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 10:54 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch


* David Howells <dhowells@redhat.com> wrote:

>      	init_MUTEX_LOCKED()
> 	DECLARE_MUTEX_LOCKED()

please kill these two in the simple mutex implementation - they are a 
sign of mutexes used as completions.

>  (7) Provides a debugging config option CONFIG_DEBUG_MUTEX_OWNER by which the
>      mutex owner can be tracked and by which over-upping can be detected.

another simplification: also enforce that only the owner can unlock the 
mutex. This is what we are doing in the -rt patch. (This rule also 
ensures that such mutexes can be used for priority inheritance.)

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (26 preceding siblings ...)
  2005-12-13 10:54 ` Ingo Molnar
@ 2005-12-13 11:23 ` David Howells
  2005-12-13 11:24 ` David Howells
                   ` (4 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-13 11:23 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Any reason why you're setting up your own style of waitqueue in
> mutex-simple.c instead of just using the kernel's style of waitqueue?

Because I can steal the code from FRV's semaphores or rw-semaphores, and this
way I can be sure of what I'm doing.

Note that the sleeping processes are generally dequeued and dispatched by the
up() function, which means they don't have to take the spinlock themselves.
This may be possible to do magically with the waitqueue stuff, but I'm not sure
how to do it; it's horribly complicated to read through the sources and there
isn't much documentation.

> > +	mb();
> 
> This should be smp_mb(), I think.

Yes.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (27 preceding siblings ...)
  2005-12-13 11:23 ` David Howells
@ 2005-12-13 11:24 ` David Howells
  2005-12-13 13:45   ` Ingo Molnar
  2005-12-13 11:34 ` David Howells
                   ` (3 subsequent siblings)
  32 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-13 11:24 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Ingo Molnar <mingo@elte.hu> wrote:

> >      	init_MUTEX_LOCKED()
> > 	DECLARE_MUTEX_LOCKED()
> 
> please kill these two in the simple mutex implementation - they are a 
> sign of mutexes used as completions.

That can be done later. It's not necessary to do it in this particular patch
set.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (28 preceding siblings ...)
  2005-12-13 11:24 ` David Howells
@ 2005-12-13 11:34 ` David Howells
  2005-12-13 13:05 ` Alan Cox
                   ` (2 subsequent siblings)
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-13 11:34 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

David Howells <dhowells@redhat.com> wrote:

> > Any reason why you're setting up your own style of waitqueue in
> > mutex-simple.c instead of just using the kernel's style of waitqueue?
> 
> Because I can steal the code from FRV's semaphores or rw-semaphores, and this
> way I can be sure of what I'm doing.

And because:

	struct mutex {
		int			state;
		wait_queue_head_t	wait_queue;
	};

Wastes 8 more bytes of memory than:

	struct mutex {
		int			state;
		spinlock_t		wait_lock;
		struct list_head	wait_list;
	};

on a 64-bit machine if spinlock_t is 4 bytes. Both waste 4 bytes if spinlock_t
is 8 bytes.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:24                 ` Andi Kleen
  2005-12-13  9:44                   ` Andrew Morton
  2005-12-13 10:28                   ` Andreas Schwab
@ 2005-12-13 12:33                   ` Matthew Wilcox
  2 siblings, 0 replies; 249+ messages in thread
From: Matthew Wilcox @ 2005-12-13 12:33 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, torvalds, hch, arjan,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 10:24:37AM +0100, Andi Kleen wrote:
> > Spose so - I don't know what people are using out there.
> 
> I don't think it was shipped in major distros at least (AFAIK) 
> They all went from 2.95 to 3.1/3.2 

Debian Woody (3.0) shipped a mess of compilers -- 2.95 for most, 2.96
for ia64 and 3.0 for parisc.  That was released in July 2002.  Sarge
(3.1) shipped in June 2005 and uses GCC 3.3 on all architectures.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:48 ` David Howells
@ 2005-12-13 12:39   ` Matthew Wilcox
  0 siblings, 0 replies; 249+ messages in thread
From: Matthew Wilcox @ 2005-12-13 12:39 UTC (permalink / raw)
  To: David Howells
  Cc: Andrew Morton, torvalds, hch, arjan, mingo, linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 10:48:19AM +0000, David Howells wrote:
> > > +#define is_mutex_locked(mutex)	((mutex)->state)
> > 
> > Let's keep the namespace consistent.  mutex_is_locked().
> 
> But that's a poor name: it turns it from a question into a statement:-(

Ah, but look at it in context of how it's used:

	if (is_mutex_locked())
That's gramatically incorrect!

	if (mutex_is_locked())
much better.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:34     ` Ingo Molnar
  2005-12-13 10:37       ` Ingo Molnar
@ 2005-12-13 12:47       ` Oliver Neukum
  2005-12-13 13:09         ` Alan Cox
  1 sibling, 1 reply; 249+ messages in thread
From: Oliver Neukum @ 2005-12-13 12:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: David Howells, Nick Piggin, torvalds, akpm, hch, arjan, matthew,
	linux-kernel, linux-arch

Am Dienstag, 13. Dezember 2005 11:34 schrieb Ingo Molnar:

> the cost of a spinlock-based generic_cmpxchg could be significantly 
> reduced by adding a generic_cmpxchg() variant that also includes a 
> 'spinlock pointer' parameter.
> 
> Architectures that do not have the instruction, can use the specified 
> spinlock to do the cmpxchg. This means that there wont be one single 
> global spinlock to emulate cmpxchg, but the mutex's own spinlock can be 
> used for it.

Can't you use the pointer as a hash input?

	Regards
		Oliver

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (29 preceding siblings ...)
  2005-12-13 11:34 ` David Howells
@ 2005-12-13 13:05 ` Alan Cox
  2005-12-13 13:15   ` Alan Cox
  2005-12-13 13:32 ` David Howells
  2005-12-13 21:03 ` David Howells
  32 siblings, 1 reply; 249+ messages in thread
From: Alan Cox @ 2005-12-13 13:05 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

On Llu, 2005-12-12 at 23:45 +0000, David Howells wrote:
>  (5) Redirects the following to apply to the new mutexes rather than the
>      traditional semaphores:
> 
> 	down()
> 	down_trylock()
> 	down_interruptible()
> 	up()
> 	init_MUTEX()
>      	init_MUTEX_LOCKED()
> 	DECLARE_MUTEX()
> 	DECLARE_MUTEX_LOCKED()

And you've audited every occurence ?

>      On the basis that most usages of semaphores are as mutexes, this makes
>      sense for in most cases it's just then a matter of changing the type from
>      struct semaphore to struct mutex. 

You propose to rename the existing up and down, which are counting
semaphores, documented and used that way everywhere with mutexes which
are not. Worse still up/down are, second to P/V, the usual forms of
referring to _counting_ semaphores.

It seems to me it would be far far saner to define something like

	sleep_lock(&foo)
	sleep_unlock(&foo)
	sleep_trylock(&foo)

given the new mutex interface is actually a sleeping interface with the
semantics of the spin_lock interface. Its then obvious what it does, you
don't randomly break other drivers you've not reviewed and the interface
is intuitive rather than obfuscated.

It won't take long for people to then change the name of the performance
critical cases and the others will catch up in time.

It also saves breaking every piece of out of tree kernel code for now
good reason.

Alan


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 12:47       ` Oliver Neukum
@ 2005-12-13 13:09         ` Alan Cox
  2005-12-13 13:13           ` Matthew Wilcox
  2005-12-13 13:24           ` Oliver Neukum
  0 siblings, 2 replies; 249+ messages in thread
From: Alan Cox @ 2005-12-13 13:09 UTC (permalink / raw)
  To: Oliver Neukum
  Cc: Ingo Molnar, David Howells, Nick Piggin, torvalds, akpm, hch,
	arjan, matthew, linux-kernel, linux-arch

On Maw, 2005-12-13 at 13:47 +0100, Oliver Neukum wrote:
> > spinlock to do the cmpxchg. This means that there wont be one single 
> > global spinlock to emulate cmpxchg, but the mutex's own spinlock can be 
> > used for it.
> 
> Can't you use the pointer as a hash input?

Some platforms already do this for certain sets of operations like
atomic_t. The downside however is that you no longer control the lock
contention or cache line bouncing. It becomes a question of luck rather
than science as to how well it scales.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:09         ` Alan Cox
@ 2005-12-13 13:13           ` Matthew Wilcox
  2005-12-13 14:04             ` Alan Cox
  2005-12-13 13:24           ` Oliver Neukum
  1 sibling, 1 reply; 249+ messages in thread
From: Matthew Wilcox @ 2005-12-13 13:13 UTC (permalink / raw)
  To: Alan Cox
  Cc: Oliver Neukum, Ingo Molnar, David Howells, Nick Piggin, torvalds,
	akpm, hch, arjan, linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 01:09:31PM +0000, Alan Cox wrote:
> On Maw, 2005-12-13 at 13:47 +0100, Oliver Neukum wrote:
> > Can't you use the pointer as a hash input?
> 
> Some platforms already do this for certain sets of operations like
> atomic_t. The downside however is that you no longer control the lock
> contention or cache line bouncing. It becomes a question of luck rather
> than science as to how well it scales.

s/luck/statistics/

You can always increase the size of the hash table if you encounter
scaling problems.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:05 ` Alan Cox
@ 2005-12-13 13:15   ` Alan Cox
  2005-12-13 23:21     ` Nikita Danilov
  0 siblings, 1 reply; 249+ messages in thread
From: Alan Cox @ 2005-12-13 13:15 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

Actually a PS to this while I think about it. spin_locks and mutex type
locks could both do with a macro for

	call_locked(&lock, foo(a,b,c,d))

to cut down on all the error path forgot to release a lock type errors.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:09         ` Alan Cox
  2005-12-13 13:13           ` Matthew Wilcox
@ 2005-12-13 13:24           ` Oliver Neukum
  1 sibling, 0 replies; 249+ messages in thread
From: Oliver Neukum @ 2005-12-13 13:24 UTC (permalink / raw)
  To: Alan Cox
  Cc: Ingo Molnar, David Howells, Nick Piggin, torvalds, akpm, hch,
	arjan, matthew, linux-kernel, linux-arch

Am Dienstag, 13. Dezember 2005 14:09 schrieb Alan Cox:
> On Maw, 2005-12-13 at 13:47 +0100, Oliver Neukum wrote:
> > > spinlock to do the cmpxchg. This means that there wont be one single 
> > > global spinlock to emulate cmpxchg, but the mutex's own spinlock can be 
> > > used for it.
> > 
> > Can't you use the pointer as a hash input?
> 
> Some platforms already do this for certain sets of operations like
> atomic_t. The downside however is that you no longer control the lock
> contention or cache line bouncing. It becomes a question of luck rather
> than science as to how well it scales.

On the other hand you don't control cache eviction either, do you?

	Regards
		Oliver

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (30 preceding siblings ...)
  2005-12-13 13:05 ` Alan Cox
@ 2005-12-13 13:32 ` David Howells
  2005-12-13 14:00   ` Alan Cox
                     ` (4 more replies)
  2005-12-13 21:03 ` David Howells
  32 siblings, 5 replies; 249+ messages in thread
From: David Howells @ 2005-12-13 13:32 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> >  (5) Redirects the following to apply to the new mutexes rather than the
> >      traditional semaphores:
> > 
> > 	down()
> ...
> 
> And you've audited every occurence ?

Outside of the arch directories, yes; but I don't know that I've made the
correct decision in 100% of the cases.

I've changed some of the uses into completions, and found about a dozen or so
uses of counting semaphores; but the vast majority of occurrences seem to be
wanting mutex behaviour.

> It seems to me it would be far far saner to define something like
> 
> 	sleep_lock(&foo)
> 	sleep_unlock(&foo)
> 	sleep_trylock(&foo)

Which would be a _lot_ more work. It would involve about ten times as many
changes, I think, and thus be more prone to errors.

> Its then obvious what it does, you don't randomly break other drivers you've
> not reviewed and the interface is intuitive rather than obfuscated.

I've attempted to review everything in 2.6.15-rc5 outside of most of the archs.
I can't easily modify any driver not contained in that tarball, but at least
the compiler will barf and force a review.

> It won't take long for people to then change the name of the performance
> critical cases and the others will catch up in time.

It took about ten hours to go through the declarations of struct semaphore and
review them; I hate to think how long it'd take to go through all the ups and
downs too.

> It also saves breaking every piece of out of tree kernel code for now
> good reason.

But my patch means the changes required are in the most cases minimal: just
changing struct semaphore to struct mutex is sufficient for the vast majority
of cases.

Your way requires a lot more work, both in the tree and out of it.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 11:24 ` David Howells
@ 2005-12-13 13:45   ` Ingo Molnar
  0 siblings, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-13 13:45 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch


* David Howells <dhowells@redhat.com> wrote:

> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > >      	init_MUTEX_LOCKED()
> > > 	DECLARE_MUTEX_LOCKED()
> > 
> > please kill these two in the simple mutex implementation - they are a 
> > sign of mutexes used as completions.
> 
> That can be done later. It's not necessary to do it in this particular 
> patch set.

i disagree - it's necessary that we dont build complexities into the 
'simple' mutex type, or the whole game starts again. I.e. the 'owner 
unlocks the mutex' rule must be enforced - which makes 
DECLARE_MUTEX_LOCKED() meaningless.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:32 ` David Howells
@ 2005-12-13 14:00   ` Alan Cox
  2005-12-13 14:35   ` Christopher Friesen
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 249+ messages in thread
From: Alan Cox @ 2005-12-13 14:00 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

On Maw, 2005-12-13 at 13:32 +0000, David Howells wrote:
> > Its then obvious what it does, you don't randomly break other drivers you've
> > not reviewed and the interface is intuitive rather than obfuscated.
> 
> I've attempted to review everything in 2.6.15-rc5 outside of most of the archs.
> I can't easily modify any driver not contained in that tarball, but at least
> the compiler will barf and force a review.


Is there a reason you didnt answer the comment about down/up being the
usual way computing refers to the operations on counting semaphores but
just deleted it ?


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:13           ` Matthew Wilcox
@ 2005-12-13 14:04             ` Alan Cox
  0 siblings, 0 replies; 249+ messages in thread
From: Alan Cox @ 2005-12-13 14:04 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Oliver Neukum, Ingo Molnar, David Howells, Nick Piggin, torvalds,
	akpm, hch, arjan, linux-kernel, linux-arch

On Maw, 2005-12-13 at 06:13 -0700, Matthew Wilcox wrote:
> > Some platforms already do this for certain sets of operations like
> > atomic_t. The downside however is that you no longer control the lock
> > contention or cache line bouncing. It becomes a question of luck rather
> > than science as to how well it scales.
> 
> s/luck/statistics/

Unfortunately not always. Statistical probability models generally
assume that samples are independent, as does just growing the hash
table. If there are correlations then how those correlations and the
hash function interact isn't simple statistics so growing the hash might
not work as well as would be hoped.

A second problem with the hash is it makes priority inversions
entertaining and unpredictable when using Ingo's -rt work. That isn't a
big problem with the atomic_t stuff in the parisc tree because atomic_t
is effectively the top of the lock ordering for the system.

Growing the hash while it may improve the behaviour isn't going to work
as well as embedding the lock in the object.

Alan


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:34           ` Ingo Molnar
@ 2005-12-13 14:33             ` Mark Lord
  2005-12-13 14:45               ` Arjan van de Ven
  0 siblings, 1 reply; 249+ messages in thread
From: Mark Lord @ 2005-12-13 14:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andi Kleen, Arjan van de Ven, Andrew Morton, David Howells,
	torvalds, hch, matthew, linux-kernel, linux-arch

 >'struct compat_semaphore'

I really think this data type needs a better name,
one that reflects what it does.

Something like 'struct binary_semaphore' or something.

Cheers

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:32 ` David Howells
  2005-12-13 14:00   ` Alan Cox
@ 2005-12-13 14:35   ` Christopher Friesen
  2005-12-13 14:44     ` Arjan van de Ven
  2005-12-13 15:23   ` David Howells
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 249+ messages in thread
From: Christopher Friesen @ 2005-12-13 14:35 UTC (permalink / raw)
  To: David Howells
  Cc: Alan Cox, torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>>It seems to me it would be far far saner to define something like
>>
>>	sleep_lock(&foo)
>>	sleep_unlock(&foo)
>>	sleep_trylock(&foo)
> 
> Which would be a _lot_ more work. It would involve about ten times as many
> changes, I think, and thus be more prone to errors.

"lots of work" has never been a valid reason for not doing a kernel 
change...

In this case, introducing a new API means the changes can be made over time.

As time goes on you can convert more and more code to the mutex/sleep 
lock and any tricky code just stays with the older API until someone who 
understands it can vet it.

As Alan mentioned, the standard counting semaphore API is up/down. 
Making those refer to a sleeping mutex violates the principle of least 
surprise.

Chris


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 14:35   ` Christopher Friesen
@ 2005-12-13 14:44     ` Arjan van de Ven
  2005-12-13 14:59       ` Christopher Friesen
  0 siblings, 1 reply; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-13 14:44 UTC (permalink / raw)
  To: Christopher Friesen
  Cc: David Howells, Alan Cox, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Tue, 2005-12-13 at 08:35 -0600, Christopher Friesen wrote:
> David Howells wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> >>It seems to me it would be far far saner to define something like
> >>
> >>	sleep_lock(&foo)
> >>	sleep_unlock(&foo)
> >>	sleep_trylock(&foo)
> > 
> > Which would be a _lot_ more work. It would involve about ten times as many
> > changes, I think, and thus be more prone to errors.
> 
> "lots of work" has never been a valid reason for not doing a kernel 
> change...
> 
> In this case, introducing a new API means the changes can be made over time.

in this case, doing this change gradual I think is a mistake. We should
do all of the in-kernel code at least... 


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 14:33             ` Mark Lord
@ 2005-12-13 14:45               ` Arjan van de Ven
  0 siblings, 0 replies; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-13 14:45 UTC (permalink / raw)
  To: Mark Lord
  Cc: Ingo Molnar, Andi Kleen, Andrew Morton, David Howells, torvalds,
	hch, matthew, linux-kernel, linux-arch

On Tue, 2005-12-13 at 09:33 -0500, Mark Lord wrote:
>  >'struct compat_semaphore'
> 
> I really think this data type needs a better name,
> one that reflects what it does.
> 
> Something like 'struct binary_semaphore' or something.

see the thing is.. this is the counting one ;)
the -rt naming is just too confusing (but done to keep patch maintenance
reasonable, which is fair enough for that purpose, but not good enough
for kernel.org)


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 14:44     ` Arjan van de Ven
@ 2005-12-13 14:59       ` Christopher Friesen
  0 siblings, 0 replies; 249+ messages in thread
From: Christopher Friesen @ 2005-12-13 14:59 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: David Howells, Alan Cox, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

Arjan van de Ven wrote:
> On Tue, 2005-12-13 at 08:35 -0600, Christopher Friesen wrote:

>>In this case, introducing a new API means the changes can be made over time.
> 
> 
> in this case, doing this change gradual I think is a mistake. We should
> do all of the in-kernel code at least... 

This means verifying all the users before patch submission, which may be 
problematic.

I guess the point I'm trying to make is that if you create a new API you 
have the option of converting the obvious cases first, which should 
cover the majority of users.  Anywhere the behaviour is non-obvious can 
be left using the old API, and the out-of-tree users will continue to 
work correctly.

Chris

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:32 ` David Howells
  2005-12-13 14:00   ` Alan Cox
  2005-12-13 14:35   ` Christopher Friesen
@ 2005-12-13 15:23   ` David Howells
  2005-12-15  5:24     ` Miles Bader
  2005-12-13 15:39   ` David Howells
  2005-12-13 20:04   ` Steven Rostedt
  4 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-13 15:23 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Is there a reason you didnt answer the comment about down/up being the
> usual way computing refers to the operations on counting semaphores but
> just deleted it ?

up/down is also used in conjunction with mutexes and R/W semaphores, so
counting semaphores do not have exclusive rights to the terminology.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:32 ` David Howells
                     ` (2 preceding siblings ...)
  2005-12-13 15:23   ` David Howells
@ 2005-12-13 15:39   ` David Howells
  2005-12-13 16:10     ` Alan Cox
  2005-12-14  8:31     ` Ingo Molnar
  2005-12-13 20:04   ` Steven Rostedt
  4 siblings, 2 replies; 249+ messages in thread
From: David Howells @ 2005-12-13 15:39 UTC (permalink / raw)
  To: Christopher Friesen
  Cc: David Howells, Alan Cox, torvalds, akpm, hch, arjan, matthew,
	linux-kernel, linux-arch

Christopher Friesen <cfriesen@nortel.com> wrote:

> > Which would be a _lot_ more work. It would involve about ten times as many
> > changes, I think, and thus be more prone to errors.
> 
> "lots of work" has never been a valid reason for not doing a kernel change...

There are a number of considerations:

 (1) If _I_ am going to be doing the work, then I'm quite happy to reduce the
     load by 90%. And I think it'd be at least that, probably more. Finding
     struct semaphore with grep is much easier than finding up/down with grep
     because of:

	(a) comments

	(b) other instances of up/down names, including rw_semaphores

     There are a lot fewer instances of struct semaphore than up and down.

 (2) It makes it easier for other people. In most cases, all they need do is
     change "struct semaphore" to "struct mutex". If they've used
     DECLARE_MUTEX() then they need do nothing at all, and if they've used
     init_MUTEX(), then they don't need to convert sema_init() either.

 (3) It forces people to reconsider how they want to use their semaphores.

I have no objection to making life easier for other people. I suspect most
other people don't care that their semaphores are now mutexes, and think of
them that way anyway.

I admit that there are downsides:

 (1) up and down now do something effectively different (though in most cases
     it's also exactly the same).

 (2) Users of counting semaphores have to change, but they're in the minority
     by quite a way.

 (3) Some people want mutexes to be:

     (a) only releasable in the same context as they were taken

     (b) not accessible in interrupt context, or that (a) applies here also

     (c) not initialisable to the locked state

     But this means that the current usages all have to be carefully audited,
     and sometimes that unobvious.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 15:39   ` David Howells
@ 2005-12-13 16:10     ` Alan Cox
  2005-12-14 10:29       ` Arjan van de Ven
  2005-12-14  8:31     ` Ingo Molnar
  1 sibling, 1 reply; 249+ messages in thread
From: Alan Cox @ 2005-12-13 16:10 UTC (permalink / raw)
  To: David Howells
  Cc: Christopher Friesen, torvalds, akpm, hch, arjan, matthew,
	linux-kernel, linux-arch

On Maw, 2005-12-13 at 15:39 +0000, David Howells wrote:
>  (3) Some people want mutexes to be:
> 
>      (a) only releasable in the same context as they were taken
> 
>      (b) not accessible in interrupt context, or that (a) applies here also
> 
>      (c) not initialisable to the locked state
> 
>      But this means that the current usages all have to be carefully audited,
>      and sometimes that unobvious.

Only if you insist on replacing them immediately. If you submit a
*small* patch which just adds the new mutexes then a series of small
patches can gradually convert code where mutexes are better. People will
naturally hit the hot and critical points first meaning that in a short
time the users of semaphores will be those who need it, and those who
are not critical to performance.

There is a problemn with init_MUTEX*/DECLARE_MUTEX naming being used for
semaphore struct init and I don't see a nice way to fix that either. I'd
rather see people just have to fix those as compiler errors (or a perl
-e regexp run to make them all init_SEM/DECLARE_SEM before any other
changes are made).



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  8:49         ` Andi Kleen
                             ` (2 preceding siblings ...)
  2005-12-13  9:09           ` Ingo Molnar
@ 2005-12-13 16:16           ` Linus Torvalds
  2005-12-13 21:56             ` Using C99 in the kernel was " Andi Kleen
  3 siblings, 1 reply; 249+ messages in thread
From: Linus Torvalds @ 2005-12-13 16:16 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, hch, arjan, matthew,
	linux-kernel, linux-arch



On Tue, 13 Dec 2005, Andi Kleen wrote:
> 
> Remove -Wdeclaration-after-statement

Please don't.

It's a coding style issue. We put our variable declarations where people 
can _find_ them, not in random places in the code.

Putting variables in the middle of code only improves readability when you 
have messy code. 

Now, one feature that _may_ be worth it is the loop counter thing:

	for (int i = 10; i; i--)
		...

kind of syntax actually makes sense and is a real feature (it makes "i" 
local to the loop, and can actually help people avoid bugs - you can't use 
"i" by mistake after the loop).

But I think you need "--std=c99" for gcc to take that.

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:00         ` Ingo Molnar
@ 2005-12-13 17:40           ` Paul Jackson
  2005-12-13 18:34           ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: Paul Jackson @ 2005-12-13 17:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: hch, akpm, dhowells, torvalds, arjan, matthew, linux-kernel, linux-arch

If we are doing global rename patches, could we make one of the
deliverables a sed or perl script that exactly produces the patch,
suitable for running one-time on out-of-kernel trees?  Add the script
in the kernel scripts directory.

It is usually too easy to produce a nearly correct script, and too
difficult to produce an exactly right one, for all but serious sed or
perl regex hackers.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:00         ` Ingo Molnar
  2005-12-13 17:40           ` Paul Jackson
@ 2005-12-13 18:34           ` David Howells
  2005-12-13 22:31             ` Paul Jackson
                               ` (2 more replies)
  1 sibling, 3 replies; 249+ messages in thread
From: David Howells @ 2005-12-13 18:34 UTC (permalink / raw)
  To: Paul Jackson
  Cc: Ingo Molnar, hch, akpm, dhowells, torvalds, arjan, matthew,
	linux-kernel, linux-arch

Paul Jackson <pj@sgi.com> wrote:

> It is usually too easy to produce a nearly correct script, and too
> difficult to produce an exactly right one, for all but serious sed or
> perl regex hackers.

I'd be especially impressed if you can get it to also analyse the context in
which the semaphore is used and determine whether or not it should be a
counting semaphore, a mutex or a completion. You can probably do this sort of
thing with Perl regexes... they seem to be terrifically[*] powerful.

 [*] and I mean that in the proper sense:-)

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:32 ` David Howells
                     ` (3 preceding siblings ...)
  2005-12-13 15:39   ` David Howells
@ 2005-12-13 20:04   ` Steven Rostedt
  4 siblings, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-13 20:04 UTC (permalink / raw)
  To: David Howells
  Cc: Ingo Molnar, linux-arch, linux-kernel, matthew, arjan, hch, akpm,
	torvalds, Alan Cox

On Tue, 2005-12-13 at 13:32 +0000, David Howells wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > >  (5) Redirects the following to apply to the new mutexes rather than the
> > >      traditional semaphores:
> > > 
> > > 	down()
> > ...
> > 
> > And you've audited every occurence ?
> 
> Outside of the arch directories, yes; but I don't know that I've made the
> correct decision in 100% of the cases.

I'm in the crowd that thinks that the mutex downs and ups should be
converted to mutex_lock/mutex_unlock.  Simply because that is basically
what a mutex is doing.  I rather not have another "historical" API in
the kernel.

> 
> I've changed some of the uses into completions, and found about a dozen or so
> uses of counting semaphores; but the vast majority of occurrences seem to be
> wanting mutex behaviour.

And we can take our time in looking at this in a case by case basis.

> 
> > It seems to me it would be far far saner to define something like
> > 
> > 	sleep_lock(&foo)
> > 	sleep_unlock(&foo)
> > 	sleep_trylock(&foo)
> 
> Which would be a _lot_ more work. It would involve about ten times as many
> changes, I think, and thus be more prone to errors.

I don't think this should be a one shot patch.  Your patch (and what you
would be responsible for) would just introduce the use of the mutex.
Let others go around and find the places where a semaphore is used where
a mutex should be.  Yes there is a lot more mutexes than true
semaphores, and that is why we really should look at this in a case by
case basis.  One big global change will probably more likely miss a case
that should be a semaphore.

> 
> > Its then obvious what it does, you don't randomly break other drivers you've
> > not reviewed and the interface is intuitive rather than obfuscated.
> 
> I've attempted to review everything in 2.6.15-rc5 outside of most of the archs.
> I can't easily modify any driver not contained in that tarball, but at least
> the compiler will barf and force a review.
> 
> > It won't take long for people to then change the name of the performance
> > critical cases and the others will catch up in time.
> 
> It took about ten hours to go through the declarations of struct semaphore and
> review them; I hate to think how long it'd take to go through all the ups and
> downs too.

That's why this should be a step by step integration.

> 
> > It also saves breaking every piece of out of tree kernel code for now
> > good reason.
> 
> But my patch means the changes required are in the most cases minimal: just
> changing struct semaphore to struct mutex is sufficient for the vast majority
> of cases.

But not every case.

> 
> Your way requires a lot more work, both in the tree and out of it.

Not really.  Over time this would be all cleaned up, but introducing a
new API should be the first step, then we can go to each and every spot
to find where a semaphore should be a mutex.  You'll get a lot more
people helping you in that method then you globally changing it, and
people only help when it breaks.

I'm sure I'm not the only one that would be happy to send patches in to
convert semaphores to mutexes where I find them.  But I'd be more
confused if something suddenly breaks that use to work, and then have to
see that "Oh this was a semaphore that mistakenly became a mutex!".

-- Steve


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
                   ` (31 preceding siblings ...)
  2005-12-13 13:32 ` David Howells
@ 2005-12-13 21:03 ` David Howells
  32 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-13 21:03 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Arnd Bergmann <arnd@arndb.de> wrote:

> I can't see how your code actually detects the over-upping, although it's 
> fairly obvious how it would be done. Did you miss one patch for this?

If owner is NULL, then you've probably upped twice.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Using C99 in the kernel was Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 16:16           ` Linus Torvalds
@ 2005-12-13 21:56             ` Andi Kleen
  2005-12-13 23:05               ` Al Viro
  0 siblings, 1 reply; 249+ messages in thread
From: Andi Kleen @ 2005-12-13 21:56 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andi Kleen, Andrew Morton, mingo, dhowells, hch, arjan, matthew,
	linux-kernel, rth

[dropping linux-arch because it seems to generate bounces]

On Tue, Dec 13, 2005 at 08:16:39AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 13 Dec 2005, Andi Kleen wrote:
> > 
> > Remove -Wdeclaration-after-statement
> 
> Please don't.
> 
> It's a coding style issue. We put our variable declarations where people 
> can _find_ them, not in random places in the code.
> 
> Putting variables in the middle of code only improves readability when you 
> have messy code. 

I like it when the scopes for variables are as small as possible because then 
I also find it good documentation when the first initialization
of a variable also has the type. 

While it's possible with nested {} blocks too that imho makes the code ugly
because you either end up with non syntactic elements with wrong 
indentation (driving emacs/indent etc crazy) or with too much
indentation.

I can see Ingo's argument about catching merging mistakes though -
that is a good point against it that I didn't consider.

> 
> Now, one feature that _may_ be worth it is the loop counter thing:
> 
> 	for (int i = 10; i; i--)
> 		...
> 
> kind of syntax actually makes sense and is a real feature (it makes "i" 
> local to the loop, and can actually help people avoid bugs - you can't use 
> "i" by mistake after the loop).
> 
> But I think you need "--std=c99" for gcc to take that.

Ok. So should we enable that?  Or rather --std=gnu99

But actually I tried it and it causes lots of

mm/page_alloc.c:49: error: initializer element is not constant

It looks like casts in constant initializers for global structures are not 
allowed anymore: struct foo x = (struct foo) { ... }; warns.  That's
not good because when the (struct foo){} is generated in a macro
then it's the only easy way to allow initialization outside a declaration.

Common case is SPIN_LOCK_UNLOCKED() / DEFINE_SPINLOCK().

Richard, any comments on that? 

P.S.: Linus, I wish you weren't so fond of using downcounting loops: I find
them always slightly confusing (or rather they need more consideration
than a standard upcounting loop to understand) and gcc is perfectly
capable of reversing loops when suitable on its own.

-Andi


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:05             ` Andi Kleen
  2005-12-13  9:15               ` Andrew Morton
@ 2005-12-13 22:18               ` Adrian Bunk
  2005-12-13 22:25                 ` Andi Kleen
  1 sibling, 1 reply; 249+ messages in thread
From: Adrian Bunk @ 2005-12-13 22:18 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 10:05:18AM +0100, Andi Kleen wrote:
> On Tue, Dec 13, 2005 at 01:01:26AM -0800, Andrew Morton wrote:
> > Andi Kleen <ak@suse.de> wrote:
> > >
> > > Can you please apply the following patch then? 
> > > 
> > >  Remove -Wdeclaration-after-statement
> > 
> > OK.
> > 
> > Thus far I have this:
> 
> Would it be possible to drop support for gcc 3.0 too? 
> AFAIK it has never been widely used. If we assume 3.1+ minimum it has the 
> advantage that named assembly arguments work, which make
> the inline assembly often a lot easier to read and maintain.

3.2+ would be better than 3.1+

Remember that 3.2 would have been named 3.1.2 if there wasn't the C++
ABI change, and I don't remember any big Linux distribution actually 
using gcc 3.1 as default compiler.

And since gcc 3.2 was released one and a half years before kernel 2.6.0, 
I doubt there's any distribution both supporting kernel 2.6 and not 
shipping any gcc >= 3.2 .

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 22:18               ` Adrian Bunk
@ 2005-12-13 22:25                 ` Andi Kleen
  2005-12-13 22:32                   ` Adrian Bunk
  0 siblings, 1 reply; 249+ messages in thread
From: Andi Kleen @ 2005-12-13 22:25 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Andi Kleen, Andrew Morton, mingo, dhowells, torvalds, hch, arjan,
	matthew, linux-kernel, linux-arch

> 3.2+ would be better than 3.1+
> 
> Remember that 3.2 would have been named 3.1.2 if there wasn't the C++
> ABI change, and I don't remember any big Linux distribution actually 
> using gcc 3.1 as default compiler.

Yes, but the kernel doesn't use C++ and afaik other than that there were only
a few minor bugfixes between 3.1 and 3.2. So it doesn't make any
difference for this special case.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 18:34           ` David Howells
@ 2005-12-13 22:31             ` Paul Jackson
  2005-12-14 11:02             ` David Howells
  2005-12-14 11:12             ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: Paul Jackson @ 2005-12-13 22:31 UTC (permalink / raw)
  To: David Howells
  Cc: mingo, hch, akpm, dhowells, torvalds, arjan, matthew,
	linux-kernel, linux-arch

> I'd be especially impressed if you can get it to also analyse the context in
> which the semaphore is used and determine whether or not it should be a
> counting semaphore, a mutex or a completion

That would impress me too, if I could do that.

I think that is well beyond my humble capabilities.

The sed/perl script to make the textual change should be practical.
Indeed, I would claim that the initial big patch -should- be done
that way.  Keep refining a sed script until manual inspection and
trial builds of all arch's, allconfig, show that it seems to be right.
Each time you find an error doing this, don't manually edit the
kernel source; rather refine the script and try applying it again.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 22:25                 ` Andi Kleen
@ 2005-12-13 22:32                   ` Adrian Bunk
  0 siblings, 0 replies; 249+ messages in thread
From: Adrian Bunk @ 2005-12-13 22:32 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, mingo, dhowells, torvalds, hch, arjan, matthew,
	linux-kernel, linux-arch

On Tue, Dec 13, 2005 at 11:25:43PM +0100, Andi Kleen wrote:
> > 3.2+ would be better than 3.1+
> > 
> > Remember that 3.2 would have been named 3.1.2 if there wasn't the C++
> > ABI change, and I don't remember any big Linux distribution actually 
> > using gcc 3.1 as default compiler.
> 
> Yes, but the kernel doesn't use C++ and afaik other than that there were only
> a few minor bugfixes between 3.1 and 3.2. So it doesn't make any
> difference for this special case.

gcc 3.2.3 is four bugfix releases and nine months later than 3.1.1, and 
there are virtually no gcc 3.1 users.

It's not a strong opinion, but if the question is whether to draw the 
line before or after gcc 3.1 I'd vote for dropping gcc 3.1 support.

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: Using C99 in the kernel was Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 21:56             ` Using C99 in the kernel was " Andi Kleen
@ 2005-12-13 23:05               ` Al Viro
  2005-12-13 23:41                 ` Andi Kleen
  0 siblings, 1 reply; 249+ messages in thread
From: Al Viro @ 2005-12-13 23:05 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Linus Torvalds, Andrew Morton, mingo, dhowells, hch, arjan,
	matthew, linux-kernel, rth

On Tue, Dec 13, 2005 at 10:56:10PM +0100, Andi Kleen wrote:
> It looks like casts in constant initializers for global structures are not 
> allowed anymore: struct foo x = (struct foo) { ... }; warns.  That's
> not good because when the (struct foo){} is generated in a macro
> then it's the only easy way to allow initialization outside a declaration.
> 
> Common case is SPIN_LOCK_UNLOCKED() / DEFINE_SPINLOCK().

There are two similar things - struct initializers and compound literals.
They are *not* the same, though; compound literal defines an unnamed
object, so
{
	struct foo x = (struct foo){...};

is equivalent to
	struct foo unnamed_variable = {....};
	struct foo x = unnamed_variable;

For auto variables it's fine; there initializer doesn't have to be
constant.  For globals it's _not_.

Note that it's really a definition of object - e.. you can say
	f(&(struct foo){....});
and have it work just fine.

IOW, DEFINE_SPINLOCK() should be spinlock_t x = __SPIN_LOCK_UNLOCKED()
and SPIN_LOCK_UNLOCKED - (spinlock_t) __SPIN_LOCK_UNLOCKED.  That's
enough to make it valid C99...

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 13:15   ` Alan Cox
@ 2005-12-13 23:21     ` Nikita Danilov
  0 siblings, 0 replies; 249+ messages in thread
From: Nikita Danilov @ 2005-12-13 23:21 UTC (permalink / raw)
  To: Alan Cox; +Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

Alan Cox writes:
 > Actually a PS to this while I think about it. spin_locks and mutex type
 > locks could both do with a macro for
 > 
 > 	call_locked(&lock, foo(a,b,c,d))

reiser4 code was publicly humiliated for such macros, but indeed they
are useful. The only problem is that one needs two macros: one for foo()
returning void and one for all other cases.

 > 
 > to cut down on all the error path forgot to release a lock type errors.
 > 

Nikita.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: Using C99 in the kernel was Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 23:05               ` Al Viro
@ 2005-12-13 23:41                 ` Andi Kleen
  0 siblings, 0 replies; 249+ messages in thread
From: Andi Kleen @ 2005-12-13 23:41 UTC (permalink / raw)
  To: Al Viro
  Cc: Andi Kleen, Linus Torvalds, Andrew Morton, mingo, dhowells, hch,
	arjan, matthew, linux-kernel, rth

> There are two similar things - struct initializers and compound literals.

I know they are not the same, but it's still annoying that gcc arbitarily
changes the definition of "GNU C" again. That is why I would consider
it more a bug than a feature. 

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:54 ` David Howells
  2005-12-13 10:13   ` Ingo Molnar
@ 2005-12-14  1:00   ` Nick Piggin
  2005-12-14 10:54   ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-14  1:00 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>We have atomic_cmpxchg. Can you use that for a sufficient generic
>>implementation?
> 
> 
> No. CMPXCHG/CAS is not as available as XCHG, and it's also unnecessary.
> 

atomic_cmpxchg should be available on all platforms.

While it may be strictly unnecessary, if it can be used to avoid
having a crappy default implementation that requires it to be
reimplemented in all architectures then that would be a good thing.

Any arguments about bad scalability or RT behaviour of the hashed
spinlock emulation atomic_t implementations are silly because they
are used by all atomic_ operations. It is an arch implementation
detail that generic code should not have to worry about.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 15:39   ` David Howells
  2005-12-13 16:10     ` Alan Cox
@ 2005-12-14  8:31     ` Ingo Molnar
  1 sibling, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-14  8:31 UTC (permalink / raw)
  To: David Howells
  Cc: Christopher Friesen, Alan Cox, torvalds, akpm, hch, arjan,
	matthew, linux-kernel, linux-arch


* David Howells <dhowells@redhat.com> wrote:

>  (3) Some people want mutexes to be:
> 
>      (a) only releasable in the same context as they were taken
> 
>      (b) not accessible in interrupt context, or that (a) applies here also
> 
>      (c) not initialisable to the locked state
> 
>      But this means that the current usages all have to be carefully audited,
>      and sometimes that unobvious.

(a) and (c) is not a big problem, are they are essentially the 
constraints of -rt mutexes. As long as there's good debugging code, it's 
very much doable. We dont want to change semantics _yet again_, later 
down the line.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 16:10     ` Alan Cox
@ 2005-12-14 10:29       ` Arjan van de Ven
  2005-12-14 11:03         ` Arjan van de Ven
  2005-12-14 11:03         ` Alan Cox
  0 siblings, 2 replies; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-14 10:29 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, Christopher Friesen, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Tue, 2005-12-13 at 16:10 +0000, Alan Cox wrote:
> On Maw, 2005-12-13 at 15:39 +0000, David Howells wrote:
> >  (3) Some people want mutexes to be:
> > 
> >      (a) only releasable in the same context as they were taken
> > 
> >      (b) not accessible in interrupt context, or that (a) applies here also
> > 
> >      (c) not initialisable to the locked state
> > 
> >      But this means that the current usages all have to be carefully audited,
> >      and sometimes that unobvious.
> 
> Only if you insist on replacing them immediately. If you submit a
> *small* patch which just adds the new mutexes then a series of small
> patches can gradually convert code where mutexes are better. 

this unfortunately is not very realistic in practice... 


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:02             ` Andrew Morton
  2005-12-13 10:07               ` Jakub Jelinek
@ 2005-12-14 10:46               ` Russell King
  1 sibling, 0 replies; 249+ messages in thread
From: Russell King @ 2005-12-14 10:46 UTC (permalink / raw)
  To: Andrew Morton
  Cc: ak, mingo, dhowells, torvalds, hch, arjan, matthew, linux-kernel,
	linux-arch

On Tue, Dec 13, 2005 at 01:02:33AM -0800, Andrew Morton wrote:
> diff -puN arch/arm/kernel/asm-offsets.c~remove-gcc2-checks arch/arm/kernel/asm-offsets.c
> --- devel/arch/arm/kernel/asm-offsets.c~remove-gcc2-checks	2005-12-13 00:51:14.000000000 -0800
> +++ devel-akpm/arch/arm/kernel/asm-offsets.c	2005-12-13 00:53:27.000000000 -0800
> @@ -23,18 +23,13 @@
>  #error Sorry, your compiler targets APCS-26 but this kernel requires APCS-32
>  #endif
>  /*
> - * GCC 2.95.1, 2.95.2: ignores register clobber list in asm().
>   * GCC 3.0, 3.1: general bad code generation.
>   * GCC 3.2.0: incorrect function argument offset calculation.
>   * GCC 3.2.x: miscompiles NEW_AUX_ENT in fs/binfmt_elf.c
>   *            (http://gcc.gnu.org/PR8896) and incorrect structure
>   *	      initialisation in fs/jffs2/erase.c
>   */
> -#if __GNUC__ < 2 || \
> -   (__GNUC__ == 2 && __GNUC_MINOR__ < 95) || \
> -   (__GNUC__ == 2 && __GNUC_MINOR__ == 95 && __GNUC_PATCHLEVEL__ != 0 && \
> -					     __GNUC_PATCHLEVEL__ < 3) || \
> -   (__GNUC__ == 3 && __GNUC_MINOR__ < 3)
> +#if __GNUC__ < 2 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)

Shouldn't this be:

+#if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3)

?

>  #error Your compiler is too buggy; it is known to miscompile kernels.
>  #error    Known good compilers: 2.95.3, 2.95.4, 2.96, 3.3

And this should also have the 2.95 and 2.96 stuff edited out.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13  9:54 ` David Howells
  2005-12-13 10:13   ` Ingo Molnar
  2005-12-14  1:00   ` Nick Piggin
@ 2005-12-14 10:54   ` David Howells
  2005-12-14 11:17     ` Nick Piggin
  2005-12-14 11:46     ` David Howells
  2 siblings, 2 replies; 249+ messages in thread
From: David Howells @ 2005-12-14 10:54 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> atomic_cmpxchg should be available on all platforms.

Two points:

 (1) If it's using spinlocks, then it's pointless to use atomic_cmpxchg.

 (2) atomic_t is a 32-bit type, and on a 64-bit platform I will want a 64-bit
     type so that I can stick the owner address in there (I've got a second
     variant not yet released).

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 18:34           ` David Howells
  2005-12-13 22:31             ` Paul Jackson
@ 2005-12-14 11:02             ` David Howells
  2005-12-14 11:12             ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-14 11:02 UTC (permalink / raw)
  To: Paul Jackson
  Cc: David Howells, mingo, hch, akpm, torvalds, arjan, matthew,
	linux-kernel, linux-arch

Paul Jackson <pj@sgi.com> wrote:

> The sed/perl script to make the textual change should be practical.
> Indeed, I would claim that the initial big patch -should- be done
> that way.  Keep refining a sed script until manual inspection and
> trial builds of all arch's, allconfig, show that it seems to be right.
> Each time you find an error doing this, don't manually edit the
> kernel source; rather refine the script and try applying it again.

Actually, you may have a point.

If the order of patches is:

 (1) Create new mutex as struct mutex/up_mutex/down_mutex, say.

 (2) Make counting semaphore implementation struct semaphore/up_sem/down_sem.

 (3) Convert uses of semaphores that should be completions into completions.

 (4) Convert uses of semaphores that should be counting semaphores to use
     up_sem/down_sem.

 (5) Mass convert by script all the remaining ups and downs into up_mutex and
     down_mutex.

 (6) Make wrappers for up/down that map to counting semaphores with the
     deprecation attribute set.

That might work, and would be a lot easier; except for the humongous patch
generated at step 5 - which could be regenerated by script. I think I can make
a simple perl script to do that.

Note that I am assuming above that down == down/down_trylock/down_interruptible
for clarity.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 10:29       ` Arjan van de Ven
@ 2005-12-14 11:03         ` Arjan van de Ven
  2005-12-14 11:03         ` Alan Cox
  1 sibling, 0 replies; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-14 11:03 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, Christopher Friesen, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Wed, 2005-12-14 at 11:29 +0100, Arjan van de Ven wrote:
> On Tue, 2005-12-13 at 16:10 +0000, Alan Cox wrote:
> > On Maw, 2005-12-13 at 15:39 +0000, David Howells wrote:
> > >  (3) Some people want mutexes to be:
> > > 
> > >      (a) only releasable in the same context as they were taken
> > > 
> > >      (b) not accessible in interrupt context, or that (a) applies here also
> > > 
> > >      (c) not initialisable to the locked state
> > > 
> > >      But this means that the current usages all have to be carefully audited,
> > >      and sometimes that unobvious.
> > 
> > Only if you insist on replacing them immediately. If you submit a
> > *small* patch which just adds the new mutexes then a series of small
> > patches can gradually convert code where mutexes are better. 
> 
> this unfortunately is not very realistic in practice... 

to expand on this; this kind of change no matter what needs a mass
change inside the kernel, or the point of it all is sort of moot. The
idea is to make the mutex type the most common one, since most users ARE
mutexes. To make that happen a one time "rather big" change is needed
and planned afaics.

What's remaining is
1) transition period for in kernel stuff
2) out of the kernel code compatibility
3) should a forgotten item be a compile time failure or be allowed to
work still 

1) is a matter of "do we do it all now" or in phases. I don't see a
reason to not do it all now, otherwise a 2 year process will happen

2) that is a semi moot issue; sure a big bang change will break this
compatibility, but so will a gradual switchover. A gradual switchover of
converting core semaphores into mutexes will need changes in external
modules regardless (think vfs but there's many more). The question is
doing it once or doing it multiple times over a period of 2 years.

3) history has shown that non-compiletime items keep lingering on
forever, since there is no incentive or even detection of "old" use. At
minimum a compiler warning is needed. Just look at the sleep_on_*() api;
more than half the users in 2.6 are *new code* in 2.6, even though it's
a deprecated api for ... how long? 


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 10:29       ` Arjan van de Ven
  2005-12-14 11:03         ` Arjan van de Ven
@ 2005-12-14 11:03         ` Alan Cox
  2005-12-14 11:08           ` Arjan van de Ven
  1 sibling, 1 reply; 249+ messages in thread
From: Alan Cox @ 2005-12-14 11:03 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: David Howells, Christopher Friesen, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Mer, 2005-12-14 at 11:29 +0100, Arjan van de Ven wrote:
> > >      But this means that the current usages all have to be carefully audited,
> > >      and sometimes that unobvious.
> > 
> > Only if you insist on replacing them immediately. If you submit a
> > *small* patch which just adds the new mutexes then a series of small
> > patches can gradually convert code where mutexes are better. 
> 
> this unfortunately is not very realistic in practice... 

Strange because it is how most such work has been done in the past, from
the big kernel lock to the scsi core rewrite. You also forgot to attach
a reason you think it isnt realistic ?

Alan

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:03         ` Alan Cox
@ 2005-12-14 11:08           ` Arjan van de Ven
  2005-12-14 11:24             ` Alan Cox
  0 siblings, 1 reply; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-14 11:08 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, Christopher Friesen, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Wed, 2005-12-14 at 11:03 +0000, Alan Cox wrote:
> On Mer, 2005-12-14 at 11:29 +0100, Arjan van de Ven wrote:
> > > >      But this means that the current usages all have to be carefully audited,
> > > >      and sometimes that unobvious.
> > > 
> > > Only if you insist on replacing them immediately. If you submit a
> > > *small* patch which just adds the new mutexes then a series of small
> > > patches can gradually convert code where mutexes are better. 
> > 
> > this unfortunately is not very realistic in practice... 
> 
> Strange because it is how most such work has been done in the past, from
> the big kernel lock to the scsi core rewrite.

1) the BKL change hasn't finished, and we're 5 years down the line. API
changes done gradual tend to take forever in practice, esp if there's no
"compile" incentive for people to fix things. 

2) the scsi rewrite was a major functional change. that's different from
a basically pure API change (split). Splitting functional changes to one
part of the kernel up into a sequence is very good. THat's different
though: even in the scsi change, API changes that went outside the scsi
core into the drivers were mostly done in one bang (not all of them, the
ones that weren't ended up being rather painful)


>  You also forgot to attach
> a reason you think it isnt realistic ?
> 
that was in a follow up email



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 18:34           ` David Howells
  2005-12-13 22:31             ` Paul Jackson
  2005-12-14 11:02             ` David Howells
@ 2005-12-14 11:12             ` David Howells
  2005-12-14 11:18               ` Alan Cox
  2005-12-14 12:35               ` David Howells
  2 siblings, 2 replies; 249+ messages in thread
From: David Howells @ 2005-12-14 11:12 UTC (permalink / raw)
  To: David Howells
  Cc: Paul Jackson, mingo, hch, akpm, torvalds, arjan, matthew,
	linux-kernel, linux-arch

David Howells <dhowells@redhat.com> wrote:

> 
>  (6) Make wrappers for up/down that map to counting semaphores with the
>      deprecation attribute set.

 (7) After a couple of months, remove up and down entirely.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 10:54   ` David Howells
@ 2005-12-14 11:17     ` Nick Piggin
  2005-12-14 11:46     ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-14 11:17 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>atomic_cmpxchg should be available on all platforms.
> 
> 
> Two points:
> 
>  (1) If it's using spinlocks, then it's pointless to use atomic_cmpxchg.
> 

Why?

>  (2) atomic_t is a 32-bit type, and on a 64-bit platform I will want a 64-bit
>      type so that I can stick the owner address in there (I've got a second
>      variant not yet released).
> 

I'm sure you could use a seperate field as it would be a debug
option, right?

But atomic longs are coming along and it is probably feasable to
do 64-bit atomic_cmpxchg on all 64-bit word architectures if you
really needed that.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:12             ` David Howells
@ 2005-12-14 11:18               ` Alan Cox
  2005-12-14 12:35               ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: Alan Cox @ 2005-12-14 11:18 UTC (permalink / raw)
  To: David Howells
  Cc: Paul Jackson, mingo, hch, akpm, torvalds, arjan, matthew,
	linux-kernel, linux-arch

On Mer, 2005-12-14 at 11:12 +0000, David Howells wrote:
> David Howells <dhowells@redhat.com> wrote:
> 
> > 
> >  (6) Make wrappers for up/down that map to counting semaphores with the
> >      deprecation attribute set.
> 
>  (7) After a couple of months, remove up and down entirely.

Why bother. As has already been discussed up and down are the natural
and normal names for counting semaphores. You don't need to obsolete the
old API thats just silly, you need to add a new one and wait for people
to use it.

The old API is still very useful for some applications that want
counting semaphores.


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:08           ` Arjan van de Ven
@ 2005-12-14 11:24             ` Alan Cox
  2005-12-14 11:35               ` Andrew Morton
  2005-12-14 11:42               ` Arjan van de Ven
  0 siblings, 2 replies; 249+ messages in thread
From: Alan Cox @ 2005-12-14 11:24 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: David Howells, Christopher Friesen, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Mer, 2005-12-14 at 12:08 +0100, Arjan van de Ven wrote:
> 1) the BKL change hasn't finished, and we're 5 years down the line. API
> changes done gradual tend to take forever in practice, esp if there's no
> "compile" incentive for people to fix things. 

This isn't a "fix" however, its merely a performance tweak. Drivers
using the old API are not a problem because

a) The old API is needed long term for true counting sem users
b) Its a minor performance hit at most

Thats rather different to the BKL


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:24             ` Alan Cox
@ 2005-12-14 11:35               ` Andrew Morton
  2005-12-14 11:44                 ` Arjan van de Ven
                                   ` (2 more replies)
  2005-12-14 11:42               ` Arjan van de Ven
  1 sibling, 3 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-14 11:35 UTC (permalink / raw)
  To: Alan Cox
  Cc: arjan, dhowells, cfriesen, torvalds, hch, matthew, linux-kernel,
	linux-arch


Could someone please remind me why we're even discussing this, given that
mutex_down() is slightly more costly than current down(), and mutex_up() is
appreciably more costly than current up()?

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:24             ` Alan Cox
  2005-12-14 11:35               ` Andrew Morton
@ 2005-12-14 11:42               ` Arjan van de Ven
  1 sibling, 0 replies; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-14 11:42 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, Christopher Friesen, torvalds, akpm, hch, matthew,
	linux-kernel, linux-arch

On Wed, 2005-12-14 at 11:24 +0000, Alan Cox wrote:
> On Mer, 2005-12-14 at 12:08 +0100, Arjan van de Ven wrote:
> > 1) the BKL change hasn't finished, and we're 5 years down the line. API
> > changes done gradual tend to take forever in practice, esp if there's no
> > "compile" incentive for people to fix things. 
> 
> This isn't a "fix" however, its merely a performance tweak.

it's a conceptual API split that, if nothing else, declares intent and
usage pattern more specifically. Performance is just one of the angles.
Other angles are that it's possible to treat mutex users different (like
Ingo is doing in -rt, where you can temporary boost a mutex owner if the
mutex gets contended, other uses are better hold time metrics etc etc)

>  Drivers
> using the old API are not a problem because
> 
> a) The old API is needed long term for true counting sem users

this is skipping one bridge ;)
A counting semaphore is needed long term. API is up for debate in the
sense that it's not clear that a non-compile-time thing is the right
solution.

> Thats rather different to the BKL

BKL is different in that it's more work to do a conversion (eg the BKL
semantics are rather complex compared to normal spinlock / semaphore /
mutex semantics). So yes BKL is harder, and not really possible to do in
one go. Unlike these...
For BKL there was no choice. Here there is.




^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:35               ` Andrew Morton
@ 2005-12-14 11:44                 ` Arjan van de Ven
  2005-12-14 11:52                   ` Andi Kleen
  2005-12-14 11:57                 ` David Howells
  2005-12-14 12:17                 ` Christoph Hellwig
  2 siblings, 1 reply; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-14 11:44 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alan Cox, dhowells, cfriesen, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Wed, 2005-12-14 at 03:35 -0800, Andrew Morton wrote:
> Could someone please remind me why we're even discussing this,

* cleaner API
* more declarative in terms of intent

which in turn allow
* higher performance
* enhanced options like the -rt patch is doing, such as boosting
processes when a semaphore they're holding hits contention
* mutex use is a candidate for a "spinaphore" treatment (unlike counting
semaphores)

>  given that
> mutex_down() is slightly more costly than current down(), and mutex_up() is
> appreciably more costly than current up()?

that's an implementation flaw in the current implementation that is not
needed by any means and that Ingo has fixed in his version of this



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 10:54   ` David Howells
  2005-12-14 11:17     ` Nick Piggin
@ 2005-12-14 11:46     ` David Howells
  2005-12-14 21:23       ` Nick Piggin
  2005-12-16 12:00       ` David Howells
  1 sibling, 2 replies; 249+ messages in thread
From: David Howells @ 2005-12-14 11:46 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> >  (1) If it's using spinlocks, then it's pointless to use atomic_cmpxchg.
> > 
> 
> Why?

Because you're going to end up with loops around the cmpxchg bit in certain
places, and if you do, then you've effectively got this:

	spin_lock_irqsave(mutexlock, flags);
	do {
		new = calc_state(orig, oldstate);
		spin_lock_irqsave(atomiclock, flags2);
		oldstate = __cmpxchg(&mutex->count, orig, new)
		spin_unlock_irqrestore(atomiclock, flags2);
	} while (oldstate != orig);
	spin_unlock_irqrestore(mutexlock, flags);

which is very bad. You _should_ have:

	spin_lock_irqsave(mutexlock, flags);
	oldstate = mutex->count;
	mutex->count = modify_state(mutex->count);
	spin_unlock_irqrestore(mutexlock, flags);

instead.

No. If you have XCHG/TAS/BSET/SWAP, but not CMPXCHG/CAS then you can do a lot
better by not pretending that cmpxchg exists. That way the fast paths don't
have to take any spinlocks at all.

And if you've got LLD/SCD or LDARX/STDCX or similar then you can probably do
better than CMPXCHG also.

If you want an illustration, then consider this:

	#define __mutex_trylock(mutex)					\
	({								\
		int oldstate;						\
									\
		asm volatile("swap%I0 %M0,%1"				\
			     : "+m"(mutex->state), "=r"(oldstate)	\
			     : "1"(1)					\
			     : "memory");				\
									\
		oldstate == 0;						\
	})

	static inline int down_trylock(struct mutex *mutex)
	{
		if (likely(__mutex_trylock(mutex))) {
			/* success */
			return 0;
		}

		/* failure */
		return 1;
	}

	void fastcall __sched down(struct mutex *mutex)
	{
		if (down_trylock(mutex) == 1)
			__down(mutex);
	}

	EXPORT_SYMBOL(down);

On FRV, this can be made to map to:

	setlos	0x1,gr4
	ori	gr4,0,gr5
	swap	@(gr8,gr0),gr5
	subicc	gr5,0,gr0,icc0
	beqlr	icc0,0x2	<-- probable-rated conditional return
	sethi.p	0xc01c,gr14
	setlo	0x9df0,gr14
	jmpl	@(gr14,gr0)

That's an out-of-line fast path of _5_ instructions. Attempting to emulate
CMPXCHG requires a lot more. On FRV, the case is alleviated somewhat since it
doesn't yet provide spinlocks and support SMP, but you'd be very hard pressed
to squeeze it down to just five instructions.

> >  (2) atomic_t is a 32-bit type, and on a 64-bit platform I will want a
> >      64-bit type so that I can stick the owner address in there (I've got
> >      a second variant not yet released).
> > 
> 
> I'm sure you could use a seperate field as it would be a debug
> option, right?

True. Ingo suggested this, and it seems reasonable. OTOH, shrinking the count
by 4 bytes would allow the whole structure to shrink by 8 on a 64-bit platform
with a 4-byte spinlock, which would be even better.

> But atomic longs are coming along and it is probably feasable to
> do 64-bit atomic_cmpxchg on all 64-bit word architectures if you
> really needed that.

That would be fine; except they don't yet exist. The way I'd do it is to
provide a default __mutex_cmpxchg() that the arch can override if it wants to.

> Send instant messages to your online friends http://au.messenger.yahoo.com 

No thanks.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:44                 ` Arjan van de Ven
@ 2005-12-14 11:52                   ` Andi Kleen
  2005-12-14 11:55                     ` Arjan van de Ven
  0 siblings, 1 reply; 249+ messages in thread
From: Andi Kleen @ 2005-12-14 11:52 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Andrew Morton, Alan Cox, dhowells, cfriesen, torvalds, hch,
	matthew, linux-kernel, linux-arch

> * mutex use is a candidate for a "spinaphore" treatment (unlike counting
> semaphores)

I think that would be interesting experiment for page faults.
But they actually use rwsems, not normal semaphores.

-Andi

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:52                   ` Andi Kleen
@ 2005-12-14 11:55                     ` Arjan van de Ven
  0 siblings, 0 replies; 249+ messages in thread
From: Arjan van de Ven @ 2005-12-14 11:55 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Andrew Morton, Alan Cox, dhowells, cfriesen, torvalds, hch,
	matthew, linux-kernel, linux-arch

On Wed, 2005-12-14 at 12:52 +0100, Andi Kleen wrote:
> > * mutex use is a candidate for a "spinaphore" treatment (unlike counting
> > semaphores)
> 
> I think that would be interesting experiment for page faults.
> But they actually use rwsems, not normal semaphores.

at least rwsems are only used as mutexes afaik... so those would just
end up being mutexes.. .and could thus do this too...

(I don't think anyone ever thought of doing a counting rwsem... at least
I sure hope so; the page fault one sure is a mutex)


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:35               ` Andrew Morton
  2005-12-14 11:44                 ` Arjan van de Ven
@ 2005-12-14 11:57                 ` David Howells
  2005-12-14 12:19                   ` Jakub Jelinek
                                     ` (3 more replies)
  2005-12-14 12:17                 ` Christoph Hellwig
  2 siblings, 4 replies; 249+ messages in thread
From: David Howells @ 2005-12-14 11:57 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Andrew Morton, Alan Cox, dhowells, cfriesen, torvalds, hch,
	matthew, linux-kernel, linux-arch

Arjan van de Ven <arjan@infradead.org> wrote:

> >  given that
> > mutex_down() is slightly more costly than current down(), and mutex_up() is
> > appreciably more costly than current up()?
> 
> that's an implementation flaw in the current implementation that is not
> needed by any means and that Ingo has fixed in his version of this

As do I. I wrote it yesterday with Ingo looking over my shoulder, as it were,
but I haven't released it yet.

What I provided was a base implementation that anything can use provided it
has an atomic op capable of exchanging between two states, and I suspect
everything that can do multiprocessing has - if you can do spinlocks, then you
can do this. I ALSO provided a mechanism by which it could be overridden if
there's something better available on that arch.

As I see it there are four classes of arch:

 (0) Those that have no atomic ops at all - in which case xchg is trivially
     implemented by disabling interrupts, and spinlocks must be null because
     they can't be implemented.

 (1) Those that only have a limited exchange functionality. Several archs do
     fall into this category: arm, frv, mn10300, 68000, i386.

 (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64, sparc.

 (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.

(This isn't an exhaustive list of archs)

Each higher class can emulate all the lower classes, but can probably do a
better implementation than the lower class because they have more flexibility.

For instance class (1) mutexes can only practically support two states, but
class (2) and (3) can support multiple states, and so can improve the up()
fastpath as well as the down() fastpaths.

With some archs, such as FRV, it might be possible to emulate a higher class,
but it's not necessarily practical in all circumstances.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:35               ` Andrew Morton
  2005-12-14 11:44                 ` Arjan van de Ven
  2005-12-14 11:57                 ` David Howells
@ 2005-12-14 12:17                 ` Christoph Hellwig
  2 siblings, 0 replies; 249+ messages in thread
From: Christoph Hellwig @ 2005-12-14 12:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alan Cox, arjan, dhowells, cfriesen, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Wed, Dec 14, 2005 at 03:35:36AM -0800, Andrew Morton wrote:
> 
> Could someone please remind me why we're even discussing this, given that
> mutex_down() is slightly more costly than current down(), and mutex_up() is
> appreciably more costly than current up()?

That's a good question.  The new mutex implementation here is big regression
to what we have right now.  What I had in mind when brainstorming something
like this would be to have a slow-path pure C semaphore implementation that
is cross-platform, and keep the current semaphore code as mutex.  Once that
is done the mutex code could be optimized further because it doesn't need to
deal with the broader uses of the semaphore, and we could add lots of useful
debugging.

The current patchkit is far from that.

What might be more useful as a start is to implement a mutex type ontop
of the current semaphore that has lots of additional checks for the DEBUG
build so we have nice diagnostics.  Once we have all users of mutex semantics
using that API we can change the underlying implementation to whatever we want.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:57                 ` David Howells
@ 2005-12-14 12:19                   ` Jakub Jelinek
  2005-12-16  1:54                   ` Nick Piggin
                                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 249+ messages in thread
From: Jakub Jelinek @ 2005-12-14 12:19 UTC (permalink / raw)
  To: David Howells
  Cc: Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen, torvalds,
	hch, matthew, linux-kernel, linux-arch

On Wed, Dec 14, 2005 at 11:57:12AM +0000, David Howells wrote:
>  (1) Those that only have a limited exchange functionality. Several archs do
>      fall into this category: arm, frv, mn10300, 68000, i386.

sparc (32-bit CPUs) fall into this category too.  V7 CPUs have just
atomic load byte and store 0xff, later CPUs have swap insn, which is like
ia32 xchg.

>  (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64, sparc.

sparc64 here.

>  (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.

	Jakub

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:12             ` David Howells
  2005-12-14 11:18               ` Alan Cox
@ 2005-12-14 12:35               ` David Howells
  2005-12-14 13:58                 ` Thomas Gleixner
  1 sibling, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-14 12:35 UTC (permalink / raw)
  To: Alan Cox
  Cc: David Howells, Paul Jackson, mingo, hch, akpm, torvalds, arjan,
	matthew, linux-kernel, linux-arch

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Why bother. As has already been discussed up and down are the natural
> and normal names for counting semaphores. You don't need to obsolete the
> old API thats just silly, you need to add a new one and wait for people
> to use it.

The vast majority of ups and downs are actually mutex related not semaphore
related, so by majority share, up/down perhaps ought to be repurposed to
mutexes: they _are_ the preeminent uses.

>From my modified tree, I see:

	semaphore	up	down	down_in	down_try
	Counting	41	59	1	0
	Mutex		4405	2824	362	107

> The old API is still very useful for some applications that want
> counting semaphores.

Whilst that is true, they're in a small minority, and it'd be easier to change
them.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 12:35               ` David Howells
@ 2005-12-14 13:58                 ` Thomas Gleixner
  2005-12-14 23:40                   ` Mark Lord
  0 siblings, 1 reply; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-14 13:58 UTC (permalink / raw)
  To: David Howells
  Cc: Alan Cox, Paul Jackson, mingo, hch, akpm, torvalds, arjan,
	matthew, linux-kernel, linux-arch

On Wed, 2005-12-14 at 12:35 +0000, David Howells wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > Why bother. As has already been discussed up and down are the natural
> > and normal names for counting semaphores. You don't need to obsolete the
> > old API thats just silly, you need to add a new one and wait for people
> > to use it.
> 
> The vast majority of ups and downs are actually mutex related not semaphore
> related, so by majority share, up/down perhaps ought to be repurposed to
> mutexes: they _are_ the preeminent uses.
> 
> From my modified tree, I see:
> 
> 	semaphore	up	down	down_in	down_try
> 	Counting	41	59	1	0
> 	Mutex		4405	2824	362	107
> 
> > The old API is still very useful for some applications that want
> > counting semaphores.
> 
> Whilst that is true, they're in a small minority, and it'd be easier to change
> them.

You can do a full scripted rename of up/down to the mutex API and then
fix up the 100 places used by semaphores manually.

	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:46     ` David Howells
@ 2005-12-14 21:23       ` Nick Piggin
  2005-12-16 12:00       ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-14 21:23 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>> (1) If it's using spinlocks, then it's pointless to use atomic_cmpxchg.
>>>
>>
>>Why?
> 
> 
> Because you're going to end up with loops around the cmpxchg bit in certain
> places, and if you do, then you've effectively got this:
> 
> 	spin_lock_irqsave(mutexlock, flags);
> 	do {
> 		new = calc_state(orig, oldstate);
> 		spin_lock_irqsave(atomiclock, flags2);
> 		oldstate = __cmpxchg(&mutex->count, orig, new)
> 		spin_unlock_irqrestore(atomiclock, flags2);
+> 	} while (oldstate != orig);
> 	spin_unlock_irqrestore(mutexlock, flags);
> 
> which is very bad. You _should_ have:
> 
> 	spin_lock_irqsave(mutexlock, flags);
> 	oldstate = mutex->count;
> 	mutex->count = modify_state(mutex->count);
> 	spin_unlock_irqrestore(mutexlock, flags);
> 
> instead.

I was under the impression that with cmpxchg, you don't need the mutex lock.
If you do then sure, cmpxchg doesn't buy you anything (even if the arch does
natively support it).

> 
> No. If you have XCHG/TAS/BSET/SWAP, but not CMPXCHG/CAS then you can do a lot
> better by not pretending that cmpxchg exists. That way the fast paths don't
> have to take any spinlocks at all.
> 
> And if you've got LLD/SCD or LDARX/STDCX or similar then you can probably do
> better than CMPXCHG also.
> 
> If you want an illustration, then consider this:
> 
> 	#define __mutex_trylock(mutex)					\
> 	({								\
> 		int oldstate;						\
> 									\
> 		asm volatile("swap%I0 %M0,%1"				\
> 			     : "+m"(mutex->state), "=r"(oldstate)	\
> 			     : "1"(1)					\
> 			     : "memory");				\
> 									\
> 		oldstate == 0;						\
> 	})
> 
> 	static inline int down_trylock(struct mutex *mutex)
> 	{
> 		if (likely(__mutex_trylock(mutex))) {
> 			/* success */
> 			return 0;
> 		}
> 
> 		/* failure */
> 		return 1;
> 	}
> 
> 	void fastcall __sched down(struct mutex *mutex)
> 	{
> 		if (down_trylock(mutex) == 1)
> 			__down(mutex);
> 	}
> 
> 	EXPORT_SYMBOL(down);
> 
> On FRV, this can be made to map to:
> 
> 	setlos	0x1,gr4
> 	ori	gr4,0,gr5
> 	swap	@(gr8,gr0),gr5
> 	subicc	gr5,0,gr0,icc0
> 	beqlr	icc0,0x2	<-- probable-rated conditional return
> 	sethi.p	0xc01c,gr14
> 	setlo	0x9df0,gr14
> 	jmpl	@(gr14,gr0)
> 
> That's an out-of-line fast path of _5_ instructions. Attempting to emulate
> CMPXCHG requires a lot more. On FRV, the case is alleviated somewhat since it
> doesn't yet provide spinlocks and support SMP, but you'd be very hard pressed
> to squeeze it down to just five instructions.
> 

I think all of about parisc and sparc32 "emulate" cmpxchg with spinlocks.
For architectures like i386, x86_64, ppc, ia64, etc. the cmpxchg will
give good code.

Then if FRV was still unhappy, then you could override the mutex in that
architecture. This just seemed better to me than having a crappy simple
implementation that *everyone* will want to override (and I see FRV
overrides it as well, I don't see how you can complain about that).

But I guess that's moot if you can't to do a lockless version using
cmpxchg.

> 
>>> (2) atomic_t is a 32-bit type, and on a 64-bit platform I will want a
>>>     64-bit type so that I can stick the owner address in there (I've got
>>>     a second variant not yet released).
>>>
>>
>>I'm sure you could use a seperate field as it would be a debug
>>option, right?
> 
> 
> True. Ingo suggested this, and it seems reasonable. OTOH, shrinking the count
> by 4 bytes would allow the whole structure to shrink by 8 on a 64-bit platform
> with a 4-byte spinlock, which would be even better.
> 

I'm sure you'd manage. spinlocks can get pretty large with debugging on too.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 13:58                 ` Thomas Gleixner
@ 2005-12-14 23:40                   ` Mark Lord
  2005-12-14 23:54                     ` Andrew Morton
                                       ` (2 more replies)
  0 siblings, 3 replies; 249+ messages in thread
From: Mark Lord @ 2005-12-14 23:40 UTC (permalink / raw)
  To: tglx
  Cc: David Howells, Alan Cox, Paul Jackson, mingo, hch, akpm,
	torvalds, arjan, matthew, linux-kernel, linux-arch

Thomas Gleixner wrote:
>
> You can do a full scripted rename of up/down to the mutex API and then
> fix up the 100 places used by semaphores manually.

Again, folks, this only works for current in-tree kernel code.

There are huge amounts of kernel code out-of-tree that still use
up/down as (or potentially as) counting semaphores.

Yes, some of that code is closed-source, but most of it is open-source
stuff in people's "queues", such as the network patch-o-matic queue
and other stuff.  Lots of open-source out-of-tree drivers, too.

Re-using the existing up()/down() names for a new purpose is
a very very Bad Idea.  Removing up()/down() entirely is not quite so bad,
because at least then people will eventually notice the change.

Leaving up()/down() as-is is really the most sensible option.

Cheers

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:40                   ` Mark Lord
@ 2005-12-14 23:54                     ` Andrew Morton
  2005-12-15 13:41                       ` Nikita Danilov
  2005-12-15 14:41                       ` Steven Rostedt
  2005-12-14 23:57                     ` Thomas Gleixner
  2005-12-15 15:37                     ` David Howells
  2 siblings, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-14 23:54 UTC (permalink / raw)
  To: Mark Lord
  Cc: tglx, dhowells, alan, pj, mingo, hch, torvalds, arjan, matthew,
	linux-kernel, linux-arch

Mark Lord <lkml@rtr.ca> wrote:
>
> Leaving up()/down() as-is is really the most sensible option.
>

Absolutely.

I must say that my interest in this stuff is down in
needs-an-electron-microscope-to-locate territory.  down() and up() work
just fine and they're small, efficient, well-debugged and well-understood. 
We need a damn good reason for taking on tree-wide churn or incompatible
renames or addition of risk.  What's the damn good reason here?

Please.  Go fix some bugs.  We're not short of them.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:57                     ` Thomas Gleixner
@ 2005-12-14 23:57                       ` Mark Lord
  2005-12-15  0:10                         ` Thomas Gleixner
  0 siblings, 1 reply; 249+ messages in thread
From: Mark Lord @ 2005-12-14 23:57 UTC (permalink / raw)
  To: tglx
  Cc: David Howells, Alan Cox, Paul Jackson, mingo, hch, akpm,
	torvalds, arjan, matthew, linux-kernel, linux-arch

Thomas Gleixner wrote:
> On Wed, 2005-12-14 at 18:40 -0500, Mark Lord wrote:
...
>>Leaving up()/down() as-is is really the most sensible option.
> 
...
>Doing a s/down/lock_mutex/ s/up/unlock_mutex/ - or whatever naming
> convention we want to use - all over the place for mutexes while keeping
> the up/down for counting semaphores is an one time issue.
> 
> After the conversion every code breaks at compile time which tries to do
> up/down(mutex_type).
> 
> So the out of tree drivers have a clear indication what to fix. This is
> also a one time issue.
> 
> So where is the problem - except for fixing "huge" amounts of out of
> kernel code once ?

Pointless API breakage.  The same functions continue to exist,
the old names CANNOT be reused for some (longish) time,
so there's no point in renaming them.  It just breaks an API
for no good reason whatsoever.

Cheers

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:40                   ` Mark Lord
  2005-12-14 23:54                     ` Andrew Morton
@ 2005-12-14 23:57                     ` Thomas Gleixner
  2005-12-14 23:57                       ` Mark Lord
  2005-12-15 15:37                     ` David Howells
  2 siblings, 1 reply; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-14 23:57 UTC (permalink / raw)
  To: Mark Lord
  Cc: David Howells, Alan Cox, Paul Jackson, mingo, hch, akpm,
	torvalds, arjan, matthew, linux-kernel, linux-arch

On Wed, 2005-12-14 at 18:40 -0500, Mark Lord wrote:
> Thomas Gleixner wrote:
> >
> > You can do a full scripted rename of up/down to the mutex API and then
> > fix up the 100 places used by semaphores manually.
> 
> Again, folks, this only works for current in-tree kernel code.
> 
> There are huge amounts of kernel code out-of-tree that still use
> up/down as (or potentially as) counting semaphores.
> 
> Yes, some of that code is closed-source, but most of it is open-source
> stuff in people's "queues", such as the network patch-o-matic queue
> and other stuff.  Lots of open-source out-of-tree drivers, too.
> 
> Re-using the existing up()/down() names for a new purpose is
> a very very Bad Idea. 

Ack.

>  Removing up()/down() entirely is not quite so bad,
> because at least then people will eventually notice the change.
> 
> Leaving up()/down() as-is is really the most sensible option.

Not at all.

Doing a s/down/lock_mutex/ s/up/unlock_mutex/ - or whatever naming
convention we want to use - all over the place for mutexes while keeping
the up/down for counting semaphores is an one time issue.

After the conversion every code breaks at compile time which tries to do
up/down(mutex_type).

So the out of tree drivers have a clear indication what to fix. This is
also a one time issue.

So where is the problem - except for fixing "huge" amounts of out of
kernel code once ?


	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:57                       ` Mark Lord
@ 2005-12-15  0:10                         ` Thomas Gleixner
  2005-12-15  2:46                           ` Linus Torvalds
  2005-12-15 15:53                           ` David Howells
  0 siblings, 2 replies; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-15  0:10 UTC (permalink / raw)
  To: Mark Lord
  Cc: David Howells, Alan Cox, Paul Jackson, mingo, hch, akpm,
	torvalds, arjan, matthew, linux-kernel, linux-arch

On Wed, 2005-12-14 at 18:57 -0500, Mark Lord wrote:
> >>Leaving up()/down() as-is is really the most sensible option.
> > 
> ...
> >Doing a s/down/lock_mutex/ s/up/unlock_mutex/ - or whatever naming
> > convention we want to use - all over the place for mutexes while keeping
> > the up/down for counting semaphores is an one time issue.
> > 
> > After the conversion every code breaks at compile time which tries to do
> > up/down(mutex_type).
> > 
> > So the out of tree drivers have a clear indication what to fix. This is
> > also a one time issue.
> > 
> > So where is the problem - except for fixing "huge" amounts of out of
> > kernel code once ?
> 
> Pointless API breakage.  The same functions continue to exist,
> the old names CANNOT be reused for some (longish) time,
> so there's no point in renaming them.  It just breaks an API
> for no good reason whatsoever.

Well, depends on the POV. A counting sempahore is a different beast than
a mutex. At least as far as my limited knowledge of concurrency controls
goes.

The API breakage was introduced by using up/down for mutexes and not by
correcting this to a sane API.

	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15  0:10                         ` Thomas Gleixner
@ 2005-12-15  2:46                           ` Linus Torvalds
  2005-12-15 15:53                           ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-15  2:46 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Mark Lord, David Howells, Alan Cox, Paul Jackson, mingo, hch,
	akpm, arjan, matthew, linux-kernel, linux-arch



On Thu, 15 Dec 2005, Thomas Gleixner wrote:
> 
> Well, depends on the POV. A counting sempahore is a different beast than
> a mutex. At least as far as my limited knowledge of concurrency controls
> goes.

A real semaphore is counting. 

Dammit, unless the pure mutex has a _huge_ performance advantage on major 
architectures, we're not changing it. There's absolutely zero point. A 
counting semaphore is a perfectly fine mutex - the fact that it can _also_ 
be used to allow more than 1 user into a critical region and generally do 
other things is totally immaterial.

It's _extra_ stupid to re-use the names "down()" and "up()" on a 
non-counting mutex, since then the names make zero sense at all. Use 
"lock_mutex()" and "unlock_mutex()" or something, and don't break existing 
code for no measurable gain.

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 10:19               ` Christoph Hellwig
  2005-12-13 10:27                 ` Ingo Molnar
@ 2005-12-15  4:53                 ` Miles Bader
  2005-12-15  5:05                   ` Nick Piggin
  1 sibling, 1 reply; 249+ messages in thread
From: Miles Bader @ 2005-12-15  4:53 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jakub Jelinek, Andi Kleen, Andrew Morton, mingo, dhowells,
	torvalds, arjan, matthew, linux-kernel, linux-arch

Christoph Hellwig <hch@infradead.org> writes:
> But serious, having to look all over the source instead of just a block
> beginning decreases code readability a lot.

My experience is quite the opposite.

Being forced to put declarations at the beginning of the block in
practice means that people simply separate declarations from the first
assignment.  That uglifies and bloats the code, and seems to often cause
bugs as well (because people seem to often not pay attention to what
happens to a variable between the declaration and first assignment;
having it simply _not exist_ before the first assignment helps quite a
bit).

-Miles
-- 
Run away!  Run away!

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15  4:53                 ` Miles Bader
@ 2005-12-15  5:05                   ` Nick Piggin
  0 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-15  5:05 UTC (permalink / raw)
  To: Miles Bader
  Cc: Christoph Hellwig, Jakub Jelinek, Andi Kleen, Andrew Morton,
	mingo, dhowells, torvalds, arjan, matthew, linux-kernel,
	linux-arch

Miles Bader wrote:
> Christoph Hellwig <hch@infradead.org> writes:
> 
>>But serious, having to look all over the source instead of just a block
>>beginning decreases code readability a lot.
> 
> 
> My experience is quite the opposite.
> 
> Being forced to put declarations at the beginning of the block in
> practice means that people simply separate declarations from the first
> assignment.  That uglifies and bloats the code, and seems to often cause
> bugs as well (because people seem to often not pay attention to what
> happens to a variable between the declaration and first assignment;
> having it simply _not exist_ before the first assignment helps quite a
> bit).
> 

If your blocks are so big that you lose track of variables like
this... then it is too big and/or complex.

And the argument about having it simply _not exist_ before the
first assignment isn't convincing to me, because you cannot
undeclare variables after you finish with them (do you also see
code where people cause bugs by forgetting about the variable after
its last use?).

IMO, the system of declaring all variables at the top of the block
and they all disappear at the end is nice and symmetric... although
I probably agree with Linus on the 'for (int i = 0;' feature.

Nick

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-13 15:23   ` David Howells
@ 2005-12-15  5:24     ` Miles Bader
  0 siblings, 0 replies; 249+ messages in thread
From: Miles Bader @ 2005-12-15  5:24 UTC (permalink / raw)
  To: David Howells
  Cc: Alan Cox, torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells <dhowells@redhat.com> writes:
>> Is there a reason you didnt answer the comment about down/up being the
>> usual way computing refers to the operations on counting semaphores but
>> just deleted it ?
>
> up/down is also used in conjunction with mutexes and R/W semaphores, so
> counting semaphores do not have exclusive rights to the terminology.

I suspect that is only the case where the author of the mutex was
accustomed to using semaphores as mutexes before-hand; "up/down" are
rather poor names for mutex operations otherwise.  lock/unlock are much
better.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:54                     ` Andrew Morton
@ 2005-12-15 13:41                       ` Nikita Danilov
  2005-12-15 14:56                         ` Alan Cox
  2005-12-15 14:41                       ` Steven Rostedt
  1 sibling, 1 reply; 249+ messages in thread
From: Nikita Danilov @ 2005-12-15 13:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: tglx, dhowells, alan, pj, mingo, hch, torvalds, arjan, matthew,
	linux-kernel, linux-arch

Andrew Morton writes:
 > Mark Lord <lkml@rtr.ca> wrote:
 > >
 > > Leaving up()/down() as-is is really the most sensible option.
 > >
 > 
 > Absolutely.
 > 
 > I must say that my interest in this stuff is down in
 > needs-an-electron-microscope-to-locate territory.  down() and up() work
 > just fine and they're small, efficient, well-debugged and well-understood. 
 > We need a damn good reason for taking on tree-wide churn or incompatible
 > renames or addition of risk.  What's the damn good reason here?
 > 
 > Please.  Go fix some bugs.  We're not short of them.

But this change is about fixing bugs: mutex assumes that

 - only owner can unlock, and

 - owner cannot lock (immediate self-deadlock).

This can be checked by the debugging code, and yes, these kinds of
errors do happen.

Not to say that by looking at

        struct foo_bar_baz {
                struct mutex fbb_mutex;
                ...
        };

one can instantly infer that ->fbb_mutex is used to serialize something
rather than serves as some fancy signaling mechanism.

Nikita.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:54                     ` Andrew Morton
  2005-12-15 13:41                       ` Nikita Danilov
@ 2005-12-15 14:41                       ` Steven Rostedt
  1 sibling, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 14:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-arch, linux-kernel, matthew, arjan, torvalds, hch, mingo,
	pj, alan, dhowells, tglx, Mark Lord

On Wed, 2005-12-14 at 15:54 -0800, Andrew Morton wrote:
> Mark Lord <lkml@rtr.ca> wrote:
> >
> > Leaving up()/down() as-is is really the most sensible option.
> >
> 
> Absolutely.
> 
> I must say that my interest in this stuff is down in
> needs-an-electron-microscope-to-locate territory.  down() and up() work
> just fine and they're small, efficient, well-debugged and well-understood. 
> We need a damn good reason for taking on tree-wide churn or incompatible
> renames or addition of risk.  What's the damn good reason here?
> 

****
> Please.  Go fix some bugs.  We're not short of them.
****

I'd give that the quote of the day!

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 13:41                       ` Nikita Danilov
@ 2005-12-15 14:56                         ` Alan Cox
  2005-12-15 15:52                           ` Nikita Danilov
  2005-12-15 15:55                           ` David Howells
  0 siblings, 2 replies; 249+ messages in thread
From: Alan Cox @ 2005-12-15 14:56 UTC (permalink / raw)
  To: Nikita Danilov
  Cc: Andrew Morton, tglx, dhowells, pj, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

On Iau, 2005-12-15 at 16:41 +0300, Nikita Danilov wrote:
> But this change is about fixing bugs: mutex assumes that
> 
>  - only owner can unlock, and
> 
>  - owner cannot lock (immediate self-deadlock).

So add mutex_up/mutex_down that use the same semaphores but do extra
checks if lock debugging is enabled. All you need is an owner field for
debugging.

Now generate a trace dump on up when up and to check for sleeping on a
lock you already hold (for both sem and mutex).

Alan


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 23:40                   ` Mark Lord
  2005-12-14 23:54                     ` Andrew Morton
  2005-12-14 23:57                     ` Thomas Gleixner
@ 2005-12-15 15:37                     ` David Howells
  2005-12-15 19:28                       ` Andrew Morton
  2 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-15 15:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Mark Lord, tglx, dhowells, alan, pj, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

Andrew Morton <akpm@osdl.org> wrote:

> I must say that my interest in this stuff is down in
> needs-an-electron-microscope-to-locate territory.  down() and up() work
> just fine and they're small, efficient, well-debugged and well-understood. 
> We need a damn good reason for taking on tree-wide churn or incompatible
> renames or addition of risk.  What's the damn good reason here?

Well...

 (1) On some platforms counting semaphores _can't_ be implemented all that
     efficiently because the only atomic op you've got is something very
     simple that can only unconditionally exchange one state for another
     (XCHG/TAS/SWAP). In such cases counting semaphores have to be be
     implemented by disabling interrupts and taking spinlocks.

     Okay, spinlocks are null ops when CONFIG_SMP and CONFIG_DEBUG_SPINLOCK
     are both disabled, but you still have to disable interrupts, and that
     slows things down, sometimes quite appreciably. It is, for example,
     something I really want to avoid doing on FRV as it takes a *lot* of
     cycles.

 (2) I think Ingo has some RT requirements, but he's probably better to speak
     about them.

 (3) As a slight aside, in a number of cases counting semaphores and their
     operators are being misused: there are, for example, places where
     completions should be used instead and places where *_MUTEX_LOCKED are
     used to initialise counting semaphores. There are also cases in there
     that seem unsure as to whether they're using counting semaphores or
     mutexes.

     Whilst this is not an argument for a galaxy wide churn, in and of itself,
     it does show that a good review is needed and at the very least these
     cases need to be fixed.

 (4) Various people want a mutex for which the semantics are tighter: in
     particular requiring that mutexes must be released in their owner's
     context. This makes debugging easier.

 (5) Mutexes can catch a double-release, which counting semaphores by their
     very nature can't.

So... Would you then object to an implementation of a mutex appearing in the
tree which semaphores that are being used as strict mutexes can be migrated
over to as the opportunity arises?

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 14:56                         ` Alan Cox
@ 2005-12-15 15:52                           ` Nikita Danilov
  2005-12-15 16:50                             ` Christopher Friesen
  2005-12-15 15:55                           ` David Howells
  1 sibling, 1 reply; 249+ messages in thread
From: Nikita Danilov @ 2005-12-15 15:52 UTC (permalink / raw)
  To: Alan Cox
  Cc: Andrew Morton, tglx, dhowells, pj, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

Alan Cox writes:
 > On Iau, 2005-12-15 at 16:41 +0300, Nikita Danilov wrote:
 > > But this change is about fixing bugs: mutex assumes that
 > > 
 > >  - only owner can unlock, and
 > > 
 > >  - owner cannot lock (immediate self-deadlock).
 > 
 > So add mutex_up/mutex_down that use the same semaphores but do extra
 > checks if lock debugging is enabled. All you need is an owner field for
 > debugging.

And to convert almost all calls to down/up to mutex_{down,up}. At which
point, it no longer makes sense to share the same data-type for
semaphore and mutex.

Also, (as was already mentioned several times) having separate data-type
for mutex makes code easier to understand, as it specifies intended
usage.

To avoid duplicating code, mutex can be implemented on top of semaphore,
like

struct mutex {
        struct semaphore sema;
#ifdef DEBUG_MUTEX
        void *owner;
#endif
};

or something similar.

 > 
 > Now generate a trace dump on up when up and to check for sleeping on a
 > lock you already hold (for both sem and mutex).

Sleeping on a semaphore "held" by the current thread is perfectly
reasonable usage of a generic counting semaphore, as it can be upped by
another thread.

 > 
 > Alan

Nikita.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15  0:10                         ` Thomas Gleixner
  2005-12-15  2:46                           ` Linus Torvalds
@ 2005-12-15 15:53                           ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-15 15:53 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Mark Lord, David Howells, Alan Cox,
	Paul Jackson, mingo, hch, akpm, arjan, matthew, linux-kernel,
	linux-arch

Linus Torvalds <torvalds@osdl.org> wrote:

> Dammit, unless the pure mutex has a _huge_ performance advantage on major 
> architectures, we're not changing it.

Whilst it's true that the major archs are generally where the least advantage
will be seen, consider the following points:

 (1) The major archs are generally the ones where consuming a few extra bytes
     of kernel code so as to hold the slow paths for the mutexes would matter
     least.

 (2) The minor archs are where the performance gain would be most noticable
     because many of them only have unconditional state substitution
     capabilities (XCHG/TAS/SWAP/BSET), and no matter how much you may not
     care for them, they do matter.

     Having to use spinlocks and interrupt disablement in lieu of conditional
     state substitution (such as CMPXCHG) can cost quite a bit.

 (3) Mutex performance should in no way be slower on any arch than counting
     semaphores being used to do the same job. Now, admittedly, my first
     attempt was suboptimal for archs that have better-than-XCHG capabilities,
     but I've amended that with Ingo's help, just not released it yet.

> There's absolutely zero point. A counting semaphore is a perfectly fine
> mutex

But that isn't so in one particular case: debugging. A mutex would balk at a
double-release, but a counting semaphore will just silently let things go
wrong, because that's the nature of the beast.

> - the fact that it can _also_ be used to allow more than 1 user into a
> critical region and generally do other things is totally immaterial.

There are about a dozen such uses of counting semaphores in the kernel, and
they're mainly used as token/message counters.

> It's _extra_ stupid to re-use the names "down()" and "up()" on a 
> non-counting mutex, since then the names make zero sense at all. Use 
> "lock_mutex()" and "unlock_mutex()" or something, and don't break existing 
> code for no measurable gain.

Okay. Repurposing up(), down(), DECLARE_MUTEX() and init_MUTEX() had the major
benefit that the kernel required relatively few changes. The biggest problem
with doing a whole new mutex type with a new and different API is that
DECLARE_MUTEX and init_MUTEX are already taken... :-/

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 14:56                         ` Alan Cox
  2005-12-15 15:52                           ` Nikita Danilov
@ 2005-12-15 15:55                           ` David Howells
  2005-12-15 16:22                             ` linux-os (Dick Johnson)
                                               ` (4 more replies)
  1 sibling, 5 replies; 249+ messages in thread
From: David Howells @ 2005-12-15 15:55 UTC (permalink / raw)
  To: Nikita Danilov
  Cc: Alan Cox, Andrew Morton, tglx, dhowells, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch

Nikita Danilov <nikita@clusterfs.com> wrote:

> And to convert almost all calls to down/up to mutex_{down,up}. At which
> point, it no longer makes sense to share the same data-type for
> semaphore and mutex.

But what to do about DECLARE_MUTEX? :-/

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:55                           ` David Howells
@ 2005-12-15 16:22                             ` linux-os (Dick Johnson)
  2005-12-15 16:28                             ` Linus Torvalds
                                               ` (3 subsequent siblings)
  4 siblings, 0 replies; 249+ messages in thread
From: linux-os (Dick Johnson) @ 2005-12-15 16:22 UTC (permalink / raw)
  To: David Howells
  Cc: Nikita Danilov, Alan Cox, Andrew Morton, tglx, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch


On Thu, 15 Dec 2005, David Howells wrote:

> Nikita Danilov <nikita@clusterfs.com> wrote:
>
>> And to convert almost all calls to down/up to mutex_{down,up}. At which
>> point, it no longer makes sense to share the same data-type for
>> semaphore and mutex.
>
> But what to do about DECLARE_MUTEX? :-/
>
> David

Isn't "struct semaphore" already an opaque type. Nobody, except
the optimizer wizards, should even care what's in them. They are
already manipulated with init_MUTEX, up, down, etc. There shouldn't
be any code changes if the actual internal workings are changed.

If some code is peeking into the internal workings, then it's
broken. Don't break the whole kernel by a name-change. Sharing
the same data-type, as long as there are no alignment problems,
has no negative impact at all. If there is stuff inside those
structures that is not used for a particular instance, who cares?
Somebody doing debugging? If they are doing kernel debugging,
they should know what they are doing, you don't dumb-down the
kernel to the lowest common denominator because there may be
different structure members used for different purposes!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:55                           ` David Howells
  2005-12-15 16:22                             ` linux-os (Dick Johnson)
@ 2005-12-15 16:28                             ` Linus Torvalds
  2005-12-15 17:04                               ` Thomas Gleixner
                                                 ` (2 more replies)
  2005-12-15 16:51                             ` David Howells
                                               ` (2 subsequent siblings)
  4 siblings, 3 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-15 16:28 UTC (permalink / raw)
  To: David Howells
  Cc: Nikita Danilov, Alan Cox, Andrew Morton, tglx, pj, mingo, hch,
	arjan, matthew, linux-kernel, linux-arch



On Thu, 15 Dec 2005, David Howells wrote:
> 
> But what to do about DECLARE_MUTEX? :-/

It's correctly named right now (it _does_ declare a mutex, despite the 
insane noise from the sidelines).

I would suggest that if you create a new "mutex" type, you just keep the 
lower-case name. Don't re-use the DECLARE_MUTEX format, just do

	struct mutex my_mutex = UNLOCKED_MUTEX;

for new code that uses the new stuff.

Think about it a bit. We don't have DECLARE_SPINLOCK either. Why?

Hint: we have DECLARE_MUTEX exactly because it's also DOCUMENTATION that 
we use a semaphore as a pure binary mutex. Not because we need it.

If you create a real "struct mutex", then something like the current 
DECLARE_MUTEX() is simply not relevant for the new type.

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:52                           ` Nikita Danilov
@ 2005-12-15 16:50                             ` Christopher Friesen
  2005-12-15 20:53                               ` Steven Rostedt
  0 siblings, 1 reply; 249+ messages in thread
From: Christopher Friesen @ 2005-12-15 16:50 UTC (permalink / raw)
  To: Nikita Danilov
  Cc: Alan Cox, Andrew Morton, tglx, dhowells, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch

Nikita Danilov wrote:

> And to convert almost all calls to down/up to mutex_{down,up}. At which
> point, it no longer makes sense to share the same data-type for
> semaphore and mutex.

If we're going to call it a mutex, it would make sense to use familiar 
terminology and call it lock/unlock rather than down/up.

Chris


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:55                           ` David Howells
  2005-12-15 16:22                             ` linux-os (Dick Johnson)
  2005-12-15 16:28                             ` Linus Torvalds
@ 2005-12-15 16:51                             ` David Howells
  2005-12-15 16:56                             ` Paul Jackson
  2005-12-15 17:28                             ` David Howells
  4 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-15 16:51 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Howells, Nikita Danilov, Alan Cox, Andrew Morton, tglx, pj,
	mingo, hch, arjan, matthew, linux-kernel, linux-arch

Linus Torvalds <torvalds@osdl.org> wrote:

> Think about it a bit. We don't have DECLARE_SPINLOCK either. Why?

I thought it was something to do with initialising struct list_heads, which
spinlocks don't have.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:55                           ` David Howells
                                               ` (2 preceding siblings ...)
  2005-12-15 16:51                             ` David Howells
@ 2005-12-15 16:56                             ` Paul Jackson
  2005-12-15 17:28                             ` David Howells
  4 siblings, 0 replies; 249+ messages in thread
From: Paul Jackson @ 2005-12-15 16:56 UTC (permalink / raw)
  To: David Howells
  Cc: nikita, alan, akpm, tglx, dhowells, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

> But what to do about DECLARE_MUTEX? :-/

A phased change of just the renames:
	DECLARE_MUTEX ==> DECLARE_SEM
	init_MUTEX ==> init_SEM
	DECLARE_MUTEX_LOCKED ==> DECLARE_SEM_LOCKED
	init_MUTEX_LOCKED ==> init_SEM_LOCKED

seems doable.  A scripted replacement, so long as it specifies whole
word replacement only, seems to be a very robust replacement for these
four symbols, unlike "up"/"down", which are scary at best to consider
wholesale replacement.

Add the new *_SEM in one release as aliases for the current *_MUTEX,
do the wholesale replacement of the above names, leaving the old as
aliases in a second release, remove the old *_MUTEX aliases in a third
release, and them restore them as new 'real mutex' methods in a fourth
release.  Be sure that the new *_MUTEX versions will generate a compile
error if handed the old counting semaphore type.

I'm a stickler for names ... at least until Linus/Andrew show me
the foolishness of my ways, I could find such a change appealing.

Of course, they're the ones with all the sweat equity on the line,
not me.

... I'd better duck and get back to bug fixing, before I get hit ...

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:28                             ` Linus Torvalds
@ 2005-12-15 17:04                               ` Thomas Gleixner
  2005-12-15 17:09                               ` Paul Jackson
  2005-12-15 17:17                               ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-15 17:04 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Howells, Nikita Danilov, Alan Cox, Andrew Morton, pj,
	Ingo Molnar, hch, arjan, matthew, linux-kernel, linux-arch

On Thu, 2005-12-15 at 08:28 -0800, Linus Torvalds wrote:
> I would suggest that if you create a new "mutex" type, you just keep the 
> lower-case name. Don't re-use the DECLARE_MUTEX format, just do
> 
> 	struct mutex my_mutex = UNLOCKED_MUTEX;
> 
> for new code that uses the new stuff.
> 
> Think about it a bit. We don't have DECLARE_SPINLOCK either. Why?

Well, we have DEFINE_SPINLOCK() and we should have a matching one for
mutexes DEFINE_MUTEX().

The reason is that you can implement complex initialization for
debugging or extensions which can't be done by a var = INITIALZER,
because you dont have a reference to var.

	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:28                             ` Linus Torvalds
  2005-12-15 17:04                               ` Thomas Gleixner
@ 2005-12-15 17:09                               ` Paul Jackson
  2005-12-15 17:17                               ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: Paul Jackson @ 2005-12-15 17:09 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: dhowells, nikita, alan, akpm, tglx, mingo, hch, arjan, matthew,
	linux-kernel, linux-arch

Linus wrote:
> Hint: we have DECLARE_MUTEX exactly because it's also DOCUMENTATION that 
> we use a semaphore as a pure binary mutex. Not because we need it.

That's insane ... 

This is stealth documentation at its finest.  Who besides Linus even
knew that's what this spelling of the DECLARE macro was telling us?

  Paul "Hand me that chain saw, Billy Jo.  This limb is coming -down-" Jackson

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:28                             ` Linus Torvalds
  2005-12-15 17:04                               ` Thomas Gleixner
  2005-12-15 17:09                               ` Paul Jackson
@ 2005-12-15 17:17                               ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-15 17:17 UTC (permalink / raw)
  To: Paul Jackson
  Cc: Linus Torvalds, dhowells, nikita, alan, akpm, tglx, mingo, hch,
	arjan, matthew, linux-kernel, linux-arch

Paul Jackson <pj@sgi.com> wrote:

> > Hint: we have DECLARE_MUTEX exactly because it's also DOCUMENTATION that 
> > we use a semaphore as a pure binary mutex. Not because we need it.
> 
> That's insane ... 

And abused/misused...

> This is stealth documentation at its finest.  Who besides Linus even
> knew that's what this spelling of the DECLARE macro was telling us?
> 
>   Paul "Hand me that chain saw, Billy Jo.  This limb is coming -down-" Jackson

I hope you're talking about trees...

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:55                           ` David Howells
                                               ` (3 preceding siblings ...)
  2005-12-15 16:56                             ` Paul Jackson
@ 2005-12-15 17:28                             ` David Howells
  2005-12-15 17:48                               ` Linus Torvalds
  4 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-15 17:28 UTC (permalink / raw)
  To: Paul Jackson
  Cc: David Howells, nikita, alan, akpm, tglx, mingo, hch, torvalds,
	arjan, matthew, linux-kernel, linux-arch

Paul Jackson <pj@sgi.com> wrote:

> 
> A phased change of just the renames:
> 	DECLARE_MUTEX ==> DECLARE_SEM
> 	init_MUTEX ==> init_SEM
> 	DECLARE_MUTEX_LOCKED ==> DECLARE_SEM_LOCKED
> 	init_MUTEX_LOCKED ==> init_SEM_LOCKED

I'd prefer:

	FROM				TO
	==============================	=========================
	DECLARE_MUTEX			DECLARE_SEM_MUTEX
	DECLARE_MUTEX_LOCKED		DECLARE_SEM_MUTEX_LOCKED
	Proper counting semaphore	DECLARE_SEM

That way people can show their intent and can be seen more easily when
violating it.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 17:28                             ` David Howells
@ 2005-12-15 17:48                               ` Linus Torvalds
  2005-12-15 18:20                                 ` Nikita Danilov
  2005-12-15 19:21                                 ` Andrew Morton
  0 siblings, 2 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-15 17:48 UTC (permalink / raw)
  To: David Howells
  Cc: Paul Jackson, nikita, alan, akpm, tglx, mingo, hch, arjan,
	matthew, linux-kernel, linux-arch



On Thu, 15 Dec 2005, David Howells wrote:
> 
> 	FROM				TO
> 	==============================	=========================
> 	DECLARE_MUTEX			DECLARE_SEM_MUTEX
> 	DECLARE_MUTEX_LOCKED		DECLARE_SEM_MUTEX_LOCKED
> 	Proper counting semaphore	DECLARE_SEM

That sounds fine. I wouldn't be adverse to doing that - but it would have 
to be independently of any other changes, and it would need to simmer for 
a while for out-of-tree drivers etc to notice (ie you should _not_ just 
introduce a new "DECLARE_MUTEX()" immediately to confuse things).

The patch could probably be fairly trivially generated with some trivial 
sed-script. Not that I'll take it at this point, but after the next 
release..

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 17:48                               ` Linus Torvalds
@ 2005-12-15 18:20                                 ` Nikita Danilov
  2005-12-15 20:58                                   ` Steven Rostedt
  2005-12-15 19:21                                 ` Andrew Morton
  1 sibling, 1 reply; 249+ messages in thread
From: Nikita Danilov @ 2005-12-15 18:20 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Howells, Paul Jackson, alan, akpm, tglx, mingo, hch, arjan,
	matthew, linux-kernel, linux-arch

Linus Torvalds writes:
 > 
 > 
 > On Thu, 15 Dec 2005, David Howells wrote:
 > > 
 > > 	FROM				TO
 > > 	==============================	=========================
 > > 	DECLARE_MUTEX			DECLARE_SEM_MUTEX
 > > 	DECLARE_MUTEX_LOCKED		DECLARE_SEM_MUTEX_LOCKED
 > > 	Proper counting semaphore	DECLARE_SEM
 > 
 > That sounds fine. I wouldn't be adverse to doing that - but it would have 
 > to be independently of any other changes, and it would need to simmer for 
 > a while for out-of-tree drivers etc to notice (ie you should _not_ just 
 > introduce a new "DECLARE_MUTEX()" immediately to confuse things).

Going off at a tangent (or tangle, rather), why do we need DECLARE_FOO()
macros at all? They

 - do not look like C variable declarations, hide variable type, and
 hence are confusing,

 - contrary to their naming actually _define_ rather than _declare_ an
 object.

In most cases 

        type var = INIT_FOO;

is much better (more readable and easier to understand) than

        DECLARE_FOO(var); /* what is the type of var? */

In the cases where initializer needs an address of object being
initialized

        type var = INIT_FOO(var);

can be used.

Nikita.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 17:48                               ` Linus Torvalds
  2005-12-15 18:20                                 ` Nikita Danilov
@ 2005-12-15 19:21                                 ` Andrew Morton
  2005-12-15 19:38                                   ` Linus Torvalds
  2005-12-15 20:28                                   ` Steven Rostedt
  1 sibling, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-15 19:21 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: dhowells, pj, nikita, alan, tglx, mingo, hch, arjan, matthew,
	linux-kernel, linux-arch

Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Thu, 15 Dec 2005, David Howells wrote:
>  > 
>  > 	FROM				TO
>  > 	==============================	=========================
>  > 	DECLARE_MUTEX			DECLARE_SEM_MUTEX
>  > 	DECLARE_MUTEX_LOCKED		DECLARE_SEM_MUTEX_LOCKED
>  > 	Proper counting semaphore	DECLARE_SEM
> 
>  That sounds fine.

They should be renamed to DEFINE_* while we're there.  A "declaration" is
"this thing is defined somewhere else".  A "definition" is "this thing is
defined here".

> I wouldn't be adverse to doing that

argh.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 15:37                     ` David Howells
@ 2005-12-15 19:28                       ` Andrew Morton
  2005-12-15 20:18                         ` Andrew Morton
  2005-12-16 10:45                         ` David Howells
  0 siblings, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-15 19:28 UTC (permalink / raw)
  To: David Howells
  Cc: lkml, tglx, dhowells, alan, pj, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

David Howells <dhowells@redhat.com> wrote:
>
> So... Would you then object to an implementation of a mutex appearing in the
>  tree which semaphores that are being used as strict mutexes can be migrated
>  over to as the opportunity arises?

That would be sane.  The semaphore->completion migration didn't hurt.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:21                                 ` Andrew Morton
@ 2005-12-15 19:38                                   ` Linus Torvalds
  2005-12-15 20:28                                   ` Steven Rostedt
  1 sibling, 0 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-15 19:38 UTC (permalink / raw)
  To: Andrew Morton
  Cc: dhowells, pj, nikita, alan, tglx, mingo, hch, arjan, matthew,
	linux-kernel, linux-arch



On Thu, 15 Dec 2005, Andrew Morton wrote:
> 
> They should be renamed to DEFINE_* while we're there.  A "declaration" is
> "this thing is defined somewhere else".  A "definition" is "this thing is
> defined here".

Yeah, I confuse the two. Although by now I've gotten so used to DECLARE_ 
that at least me personally I like it. 

> > I wouldn't be adverse to doing that
> 
> argh.

Heh. At least there's only 310 DECLARE_MUTEX* references in the whole 
kernel. So we're not actually talking about a huge patch. 

It's also fairly simple to work with in out-of-tree drivers, since it's 
always bound to be a #define, so you can do things like

	#ifndef DECLARE_SEM_MUTEX
	#define DECLARE_SEM_MUTEX(x) DECLARE_MUTEX(x)
	#endif

or something.

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:28                       ` Andrew Morton
@ 2005-12-15 20:18                         ` Andrew Morton
  2005-12-15 21:28                           ` Steven Rostedt
  2005-12-16 22:02                           ` Thomas Gleixner
  2005-12-16 10:45                         ` David Howells
  1 sibling, 2 replies; 249+ messages in thread
From: Andrew Morton @ 2005-12-15 20:18 UTC (permalink / raw)
  To: dhowells, lkml, tglx, alan, pj, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

Andrew Morton <akpm@osdl.org> wrote:
>
> David Howells <dhowells@redhat.com> wrote:
> >
> > So... Would you then object to an implementation of a mutex appearing in the
> >  tree which semaphores that are being used as strict mutexes can be migrated
> >  over to as the opportunity arises?
> 
> That would be sane.
>

But not very.

Look at it from the POV of major architectures: there's no way the new
mutex code will be faster than down() and up(), so we're adding a bunch of
new tricky locking code which bloats the kernel and has to be understood
and debugged for no gain.

And I don't buy the debuggability argument really.  It'd be pretty simple
to add debug code to the existing semaphore code to trap non-mutex usages. 
Then go through the few valid non-mutex users and do:

#if debug
	sem->this_is_not_a_mutex = 1;
#endif

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:21                                 ` Andrew Morton
  2005-12-15 19:38                                   ` Linus Torvalds
@ 2005-12-15 20:28                                   ` Steven Rostedt
  2005-12-15 20:32                                     ` Geert Uytterhoeven
  1 sibling, 1 reply; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 20:28 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-arch, linux-kernel, matthew, arjan, hch, mingo, tglx, alan,
	nikita, pj, dhowells, Linus Torvalds

On Thu, 2005-12-15 at 11:21 -0800, Andrew Morton wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > On Thu, 15 Dec 2005, David Howells wrote:
> >  > 
> >  > 	FROM				TO
> >  > 	==============================	=========================
> >  > 	DECLARE_MUTEX			DECLARE_SEM_MUTEX
> >  > 	DECLARE_MUTEX_LOCKED		DECLARE_SEM_MUTEX_LOCKED
> >  > 	Proper counting semaphore	DECLARE_SEM
> > 
> >  That sounds fine.
> 
> They should be renamed to DEFINE_* while we're there.  A "declaration" is
> "this thing is defined somewhere else".  A "definition" is "this thing is
> defined here".

Why have the "MUTEX" part in there?  Shouldn't that just be DECLARE_SEM
(oops, I mean DEFINE_SEM).  Especially that MUTEX_LOCKED! What is that?
How does a MUTEX start off as locked.  It can't, since a mutex must
always have an owner (which, by the way, helped us in the -rt patch to
find our "compat_semaphores").  So who's the owner of a
DEFINE_SEM_MUTEX_LOCKED?

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 20:28                                   ` Steven Rostedt
@ 2005-12-15 20:32                                     ` Geert Uytterhoeven
  2005-12-16 21:41                                       ` Thomas Gleixner
  0 siblings, 1 reply; 249+ messages in thread
From: Geert Uytterhoeven @ 2005-12-15 20:32 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, mingo, tglx, Alan Cox, nikita, pj,
	dhowells, Linus Torvalds

On Thu, 15 Dec 2005, Steven Rostedt wrote:
> On Thu, 2005-12-15 at 11:21 -0800, Andrew Morton wrote:
> > Linus Torvalds <torvalds@osdl.org> wrote:
> > >
> > > On Thu, 15 Dec 2005, David Howells wrote:
> > >  > 
> > >  > 	FROM				TO
> > >  > 	==============================	=========================
> > >  > 	DECLARE_MUTEX			DECLARE_SEM_MUTEX
> > >  > 	DECLARE_MUTEX_LOCKED		DECLARE_SEM_MUTEX_LOCKED
> > >  > 	Proper counting semaphore	DECLARE_SEM
> > > 
> > >  That sounds fine.
> > 
> > They should be renamed to DEFINE_* while we're there.  A "declaration" is
> > "this thing is defined somewhere else".  A "definition" is "this thing is
> > defined here".
> 
> Why have the "MUTEX" part in there?  Shouldn't that just be DECLARE_SEM
> (oops, I mean DEFINE_SEM).  Especially that MUTEX_LOCKED! What is that?
> How does a MUTEX start off as locked.  It can't, since a mutex must
> always have an owner (which, by the way, helped us in the -rt patch to
> find our "compat_semaphores").  So who's the owner of a
> DEFINE_SEM_MUTEX_LOCKED?

No one. It's not really a mutex, but a completion.

Gr{oetje,eeting}s,

						Geert

P.S. Long live the common vocabulary ;-)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:50                             ` Christopher Friesen
@ 2005-12-15 20:53                               ` Steven Rostedt
  0 siblings, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 20:53 UTC (permalink / raw)
  To: Christopher Friesen
  Cc: linux-arch, linux-kernel, matthew, arjan, torvalds, hch, mingo,
	pj, dhowells, tglx, Andrew Morton, Alan Cox, Nikita Danilov

On Thu, 2005-12-15 at 10:50 -0600, Christopher Friesen wrote:
> Nikita Danilov wrote:
> 
> > And to convert almost all calls to down/up to mutex_{down,up}. At which
> > point, it no longer makes sense to share the same data-type for
> > semaphore and mutex.
> 
> If we're going to call it a mutex, it would make sense to use familiar 
> terminology and call it lock/unlock rather than down/up.

ACK!

-- Steve


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 18:20                                 ` Nikita Danilov
@ 2005-12-15 20:58                                   ` Steven Rostedt
  0 siblings, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 20:58 UTC (permalink / raw)
  To: Nikita Danilov
  Cc: linux-arch, linux-kernel, matthew, arjan, hch, mingo, tglx, akpm,
	alan, Paul Jackson, David Howells, Linus Torvalds

On Thu, 2005-12-15 at 21:20 +0300, Nikita Danilov wrote:

> Going off at a tangent (or tangle, rather), why do we need DECLARE_FOO()
> macros at all? They
> 
>  - do not look like C variable declarations, hide variable type, and
>  hence are confusing,
> 
>  - contrary to their naming actually _define_ rather than _declare_ an
>  object.
> 
> In most cases 
> 
>         type var = INIT_FOO;
> 
> is much better (more readable and easier to understand) than
> 
>         DECLARE_FOO(var); /* what is the type of var? */
> 
> In the cases where initializer needs an address of object being
> initialized
> 
>         type var = INIT_FOO(var);
> 
> can be used.

That's just error prone.  In the RT patch we had several bugs caused by
cut and paste errors like:

type foo = INIT_TYPE(foo);
type bar = INIT_TYPE(foo);

These are not always easy to find.

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 20:18                         ` Andrew Morton
@ 2005-12-15 21:28                           ` Steven Rostedt
  2005-12-16 22:02                           ` Thomas Gleixner
  1 sibling, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 21:28 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-arch, linux-kernel, matthew, arjan, torvalds, hch, mingo,
	pj, alan, tglx, lkml, dhowells

On Thu, 2005-12-15 at 12:18 -0800, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > David Howells <dhowells@redhat.com> wrote:
> > >
> > > So... Would you then object to an implementation of a mutex appearing in the
> > >  tree which semaphores that are being used as strict mutexes can be migrated
> > >  over to as the opportunity arises?
> > 
> > That would be sane.
> >
> 
> But not very.
> 
> Look at it from the POV of major architectures: there's no way the new
> mutex code will be faster than down() and up(), so we're adding a bunch of
> new tricky locking code which bloats the kernel and has to be understood
> and debugged for no gain.

I see it as a stepping stone for RT ;)

> 
> And I don't buy the debuggability argument really.  It'd be pretty simple
> to add debug code to the existing semaphore code to trap non-mutex usages. 
> Then go through the few valid non-mutex users and do:
> 
> #if debug
> 	sem->this_is_not_a_mutex = 1;
> #endif

That just looks plain ugly.  Still, if you want to keep the major archs
unchanged (at least until RT is in!) then just add the following:

#define mutex_lock(x) down(x)
#define mutex_unlock(x) up(x)
#define mutex_trylock(x) (!down_trylock(x))  /* see previous email! */

Then you can add your ugly patch ;) where on debug we define those
declared with DEFINE_SEM(x) add the this_is_not_a_mutex = 1

-- Steve


> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:57                 ` David Howells
  2005-12-14 12:19                   ` Jakub Jelinek
@ 2005-12-16  1:54                   ` Nick Piggin
  2005-12-16 11:02                   ` David Howells
  2005-12-16 11:30                   ` David Howells
  3 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-16  1:54 UTC (permalink / raw)
  To: David Howells
  Cc: Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen, torvalds,
	hch, matthew, linux-kernel, linux-arch

David Howells wrote:
> Arjan van de Ven <arjan@infradead.org> wrote:
> 
> 
>>> given that
>>>mutex_down() is slightly more costly than current down(), and mutex_up() is
>>>appreciably more costly than current up()?
>>
>>that's an implementation flaw in the current implementation that is not
>>needed by any means and that Ingo has fixed in his version of this
> 
> 
> As do I. I wrote it yesterday with Ingo looking over my shoulder, as it were,
> but I haven't released it yet.
> 
> What I provided was a base implementation that anything can use provided it
> has an atomic op capable of exchanging between two states, and I suspect
> everything that can do multiprocessing has - if you can do spinlocks, then you
> can do this. I ALSO provided a mechanism by which it could be overridden if
> there's something better available on that arch.
> 
> As I see it there are four classes of arch:
> 
>  (0) Those that have no atomic ops at all - in which case xchg is trivially
>      implemented by disabling interrupts, and spinlocks must be null because
>      they can't be implemented.
> 
>  (1) Those that only have a limited exchange functionality. Several archs do
>      fall into this category: arm, frv, mn10300, 68000, i386.
> 
>  (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64, sparc.
> 
>  (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.
> 

cmpxchg is basically exactly equivalent to a store-conditional, so 2 and 3
are the same level.

I don't know why you don't implement a "good" default implementation with
atomic_cmpxchg.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:28                       ` Andrew Morton
  2005-12-15 20:18                         ` Andrew Morton
@ 2005-12-16 10:45                         ` David Howells
  1 sibling, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-16 10:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: dhowells, lkml, tglx, alan, pj, mingo, hch, torvalds, arjan,
	matthew, linux-kernel, linux-arch

Andrew Morton <akpm@osdl.org> wrote:

> Look at it from the POV of major architectures: there's no way the new
> mutex code will be faster than down() and up()

I'm thinking of making the default implementation of mutexes a straight
wrapper around down() and up(). That way it'll be exactly the same as counting
semaphores, just with extra constraints when the debugging is enabled _and_
effectively extra inline documentation.

But! for archs where it does matter (and we have several - you might not care,
but others do), it can be overridden with something faster.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:57                 ` David Howells
  2005-12-14 12:19                   ` Jakub Jelinek
  2005-12-16  1:54                   ` Nick Piggin
@ 2005-12-16 11:02                   ` David Howells
  2005-12-16 13:01                     ` Nick Piggin
  2005-12-16 16:28                     ` Linus Torvalds
  2005-12-16 11:30                   ` David Howells
  3 siblings, 2 replies; 249+ messages in thread
From: David Howells @ 2005-12-16 11:02 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	cfriesen, torvalds, hch, matthew, linux-kernel, linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> >  (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64,
> > sparc.
> >  (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.
> > 
> 
> cmpxchg is basically exactly equivalent to a store-conditional, so 2 and 3
> are the same level.

No, they're not. LL/SC is more flexible than CMPXCHG because under some
circumstances, you can get away without doing the SC, and because sometimes
you can do one LL/SC in lieu of two CMPXCHG's because LL/SC allows you to
retrieve the value, consider it and then modify it if you want to. With
CMPXCHG you have to anticipate, and so you're more likely to get it wrong.

> I don't know why you don't implement a "good" default implementation with
> atomic_cmpxchg.

Because it wouldn't be a good default. I'm thinking the best default is simply
to wrap a counting semaphore. Where overriding this really matters is class 1
CPUs that don't have CMPXCHG, LL/SC, or in the x86 case, LOCK INC/DEC.

I've had a play with x86, and on there CMPXCHG, XCHG and XADD give worse
performance than INC/DEC for some reason. I assume this is something to do
with how the PPro CPU optimises itself. On PPro CPUs at least, counting
semaphores really are the most efficient way. CMPXCHG, whilst it ought to be
better, really isn't.

One thing I have noticed, though, is that the counting semaphore tends to be
quite uneven in its distribution across threads in a situation where a lot of
threads are all trying to thrash the semaphore at the same time:

	insmod /tmp/synchro-test.ko v=1 do_sched=1 sm=20 ism=1

gives:

	SEM: 2% 1% 2% 5% 4% 4% 3% 11% 2% 33% 1% 1% 5% 2% 2% 1% 2% 3% 3% 4%

on a dual 200MHz PPro.

Whereas my mutexes are much more even:

	MTX: 5% 5% 4% 4% 4% 5% 5% 5% 5% 4% 4% 4% 4% 4% 6% 5% 4% 4% 4% 6%

(See attached module).

Now, I don't think that this situation is very likely to crop up in ordinary
use, but it seems odd.

David

/* synchro-test.c: run some threads to test the synchronisation primitives
 *
 * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
 * Written by David Howells (dhowells@redhat.com)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version
 * 2 of the License, or (at your option) any later version.
 *
 * run as something like:
 *
 *	insmod synchro-test.ko rd=2 wr=2
 *	insmod synchro-test.ko mx=1
 *	insmod synchro-test.ko sm=2 ism=1
 *	insmod synchro-test.ko sm=2 ism=2
 */

#include <linux/config.h>
#include <linux/module.h>
#include <linux/poll.h>
#include <linux/moduleparam.h>
#include <linux/stat.h>
#include <linux/init.h>
#include <asm/atomic.h>
#include <linux/personality.h>
#include <linux/smp_lock.h>
#include <linux/delay.h>
#include <linux/timer.h>
#include <linux/completion.h>
#include <linux/mutex.h>

#define VALIDATE_OPERATORS 0

static int nummx = 0;
static int numsm = 0, seminit = 4;
static int numrd = 0, numwr = 0, numdg = 0;
static int elapse = 5, load = 0, do_sched = 0;
static int verbose = 0;

MODULE_AUTHOR("David Howells");
MODULE_DESCRIPTION("Synchronisation primitive test demo");
MODULE_LICENSE("GPL");

module_param_named(v, verbose, int, 0);
MODULE_PARM_DESC(verbose, "Verbosity");

module_param_named(mx, nummx, int, 0);
MODULE_PARM_DESC(nummx, "Number of mutex threads");

module_param_named(sm, numsm, int, 0);
MODULE_PARM_DESC(numsm, "Number of semaphore threads");

module_param_named(ism, seminit, int, 0);
MODULE_PARM_DESC(seminit, "Initial semaphore value");

module_param_named(rd, numrd, int, 0);
MODULE_PARM_DESC(numrd, "Number of reader threads");

module_param_named(wr, numwr, int, 0);
MODULE_PARM_DESC(numwr, "Number of writer threads");

module_param_named(dg, numdg, int, 0);
MODULE_PARM_DESC(numdg, "Number of downgrader threads");

module_param(elapse, int, 0);
MODULE_PARM_DESC(elapse, "Number of seconds to run for");

module_param(load, int, 0);
MODULE_PARM_DESC(load, "Length of load in uS");

module_param(do_sched, int, 0);
MODULE_PARM_DESC(do_sched, "True if each thread should schedule regularly");

/* the semaphores under test */
static struct mutex ____cacheline_aligned mutex;
static struct semaphore ____cacheline_aligned sem;
static struct rw_semaphore ____cacheline_aligned rwsem;

static atomic_t ____cacheline_aligned do_stuff		= ATOMIC_INIT(0);

#if VALIDATE_OPERATORS
static atomic_t ____cacheline_aligned mutexes		= ATOMIC_INIT(0);
static atomic_t ____cacheline_aligned semaphores	= ATOMIC_INIT(0);
static atomic_t ____cacheline_aligned readers		= ATOMIC_INIT(0);
static atomic_t ____cacheline_aligned writers		= ATOMIC_INIT(0);
#endif

static unsigned int ____cacheline_aligned mutexes_taken[20];
static unsigned int ____cacheline_aligned semaphores_taken[20];
static unsigned int ____cacheline_aligned reads_taken[20];
static unsigned int ____cacheline_aligned writes_taken[20];
static unsigned int ____cacheline_aligned downgrades_taken[20];

static struct completion ____cacheline_aligned mx_comp[20];
static struct completion ____cacheline_aligned sm_comp[20];
static struct completion ____cacheline_aligned rd_comp[20];
static struct completion ____cacheline_aligned wr_comp[20];
static struct completion ____cacheline_aligned dg_comp[20];

static struct timer_list ____cacheline_aligned timer;

#define ACCOUNT(var, N) var##_taken[N]++;

#if VALIDATE_OPERATORS
#define TRACK(var, dir) atomic_##dir(&(var))

#define CHECK(var, cond, val)						\
do {									\
	int x = atomic_read(&(var));					\
	if (unlikely(!(x cond (val))))					\
		printk("check [%s %s %d, == %d] failed in %s\n",	\
		       #var, #cond, (val), x, __func__);		\
} while (0)

#else
#define TRACK(var, dir)		do {} while(0)
#define CHECK(var, cond, val)	do {} while(0)
#endif

static inline void do_mutex_lock(unsigned int N)
{
	mutex_lock(&mutex);

	ACCOUNT(mutexes, N);
	TRACK(mutexes, inc);
	CHECK(mutexes, ==, 1);
}

static inline void do_mutex_unlock(unsigned int N)
{
	CHECK(mutexes, ==, 1);
	TRACK(mutexes, dec);

	mutex_unlock(&mutex);
}

static inline void do_down(unsigned int N)
{
	CHECK(mutexes, <, seminit);

	down(&sem);

	ACCOUNT(semaphores, N);
	TRACK(semaphores, inc);
}

static inline void do_up(unsigned int N)
{
	CHECK(semaphores, >, 0);
	TRACK(semaphores, dec);

	up(&sem);
}

static inline void do_down_read(unsigned int N)
{
	down_read(&rwsem);

	ACCOUNT(reads, N);
	TRACK(readers, inc);
	CHECK(readers, >, 0);
	CHECK(writers, ==, 0);
}

static inline void do_up_read(unsigned int N)
{
	CHECK(readers, >, 0);
	CHECK(writers, ==, 0);
	TRACK(readers, dec);

	up_read(&rwsem);
}

static inline void do_down_write(unsigned int N)
{
	down_write(&rwsem);

	ACCOUNT(writes, N);
	TRACK(writers, inc);
	CHECK(writers, ==, 1);
	CHECK(readers, ==, 0);
}

static inline void do_up_write(unsigned int N)
{
	CHECK(writers, ==, 1);
	CHECK(readers, ==, 0);
	TRACK(writers, dec);

	up_write(&rwsem);
}

static inline void do_downgrade_write(unsigned int N)
{
	CHECK(writers, ==, 1);
	CHECK(readers, ==, 0);
	TRACK(writers, dec);
	TRACK(readers, inc);

	downgrade_write(&rwsem);

	ACCOUNT(downgrades, N);
}

static inline void sched(void)
{
	if (do_sched)
		schedule();
}

int mutexer(void *arg)
{
	unsigned int N = (unsigned long) arg;

	daemonize("Mutex%u", N);

	while (atomic_read(&do_stuff)) {
		do_mutex_lock(N);
		if (load)
			udelay(load);
		do_mutex_unlock(N);
		sched();
	}

	if (verbose >= 2)
		printk("%s: done\n", current->comm);
	complete_and_exit(&mx_comp[N], 0);
}

int semaphorer(void *arg)
{
	unsigned int N = (unsigned long) arg;

	daemonize("Sem%u", N);

	while (atomic_read(&do_stuff)) {
		do_down(N);
		if (load)
			udelay(load);
		do_up(N);
		sched();
	}

	if (verbose >= 2)
		printk("%s: done\n", current->comm);
	complete_and_exit(&sm_comp[N], 0);
}

int reader(void *arg)
{
	unsigned int N = (unsigned long) arg;

	daemonize("Read%u", N);

	while (atomic_read(&do_stuff)) {
		do_down_read(N);
#ifdef LOAD_TEST
		if (load)
			udelay(load);
#endif
		do_up_read(N);
		sched();
	}

	if (verbose >= 2)
		printk("%s: done\n", current->comm);
	complete_and_exit(&rd_comp[N], 0);
}

int writer(void *arg)
{
	unsigned int N = (unsigned long) arg;

	daemonize("Write%u", N);

	while (atomic_read(&do_stuff)) {
		do_down_write(N);
#ifdef LOAD_TEST
		if (load)
			udelay(load);
#endif
		do_up_write(N);
		sched();
	}

	if (verbose >= 2)
		printk("%s: done\n", current->comm);
	complete_and_exit(&wr_comp[N], 0);
}

int downgrader(void *arg)
{
	unsigned int N = (unsigned long) arg;

	daemonize("Down%u", N);

	while (atomic_read(&do_stuff)) {
		do_down_write(N);
#ifdef LOAD_TEST
		if (load)
			udelay(load);
#endif
		do_downgrade_write(N);
#ifdef LOAD_TEST
		if (load)
			udelay(load);
#endif
		do_up_read(N);
		sched();
	}

	if (verbose >= 2)
		printk("%s: done\n", current->comm);
	complete_and_exit(&dg_comp[N], 0);
}

static void stop_test(unsigned long dummy)
{
	atomic_set(&do_stuff, 0);
}

static unsigned int total(const char *what, unsigned int counts[], int num)
{
	unsigned int tot = 0, max = 0, min = UINT_MAX, zeros = 0, cnt;
	int loop;

	for (loop = 0; loop < num; loop++) {
		cnt = counts[loop];

		if (cnt == 0) {
			zeros++;
			min = 0;
			continue;
		}

		tot += cnt;
		if (tot > max)
			max = tot;
		if (tot < min)
			min = tot;
	}

	if (verbose && tot > 0) {
		printk("%s:", what);

		for (loop = 0; loop < num; loop++) {
			cnt = counts[loop];

			if (cnt == 0)
				printk(" zzz");
			else
				printk(" %d%%", cnt * 100 / tot);
		}

		printk("\n");
	}

	return tot;
}

/*****************************************************************************/
/*
 *
 */
static int __init do_tests(void)
{
	unsigned long loop;
	unsigned int mutex_total, sem_total, rd_total, wr_total, dg_total;

	if (nummx < 0 || nummx > 20 ||
	    numsm < 0 || numsm > 20 ||
	    numrd < 0 || numrd > 20 ||
	    numwr < 0 || numwr > 20 ||
	    numdg < 0 || numdg > 20 ||
	    seminit < 1 ||
	    elapse < 1
	    ) {
		printk("Parameter out of range\n");
		return -ERANGE;
	}

	if ((nummx | numsm | numrd | numwr | numdg) == 0) {
		printk("Nothing to do\n");
		return -EINVAL;
	}

	if (verbose)
		printk("\nStarting synchronisation primitive tests...\n");

	mutex_init(&mutex);
	sema_init(&sem, seminit);
	init_rwsem(&rwsem);
	atomic_set(&do_stuff, 1);

	/* kick off all the children */
	for (loop = 0; loop < 20; loop++) {
		if (loop < nummx) {
			init_completion(&mx_comp[loop]);
			kernel_thread(mutexer, (void *) loop, 0);
		}

		if (loop < numsm) {
			init_completion(&sm_comp[loop]);
			kernel_thread(semaphorer, (void *) loop, 0);
		}

		if (loop < numrd) {
			init_completion(&rd_comp[loop]);
			kernel_thread(reader, (void *) loop, 0);
		}

		if (loop < numwr) {
			init_completion(&wr_comp[loop]);
			kernel_thread(writer, (void *) loop, 0);
		}

		if (loop < numdg) {
			init_completion(&dg_comp[loop]);
			kernel_thread(downgrader, (void *) loop, 0);
		}
	}

	/* set a stop timer */
	init_timer(&timer);
	timer.function = stop_test;
	timer.expires = jiffies + elapse * HZ;
	add_timer(&timer);

	/* now wait until it's all done */
	for (loop = 0; loop < nummx; loop++)
		wait_for_completion(&mx_comp[loop]);

	for (loop = 0; loop < numsm; loop++)
		wait_for_completion(&sm_comp[loop]);

	for (loop = 0; loop < numrd; loop++)
		wait_for_completion(&rd_comp[loop]);

	for (loop = 0; loop < numwr; loop++)
		wait_for_completion(&wr_comp[loop]);

	for (loop = 0; loop < numdg; loop++)
		wait_for_completion(&dg_comp[loop]);

	atomic_set(&do_stuff, 0);
	del_timer(&timer);

	if (mutex_is_locked(&mutex))
		printk(KERN_ERR "Mutex is still locked!\n");

	/* count up */
	mutex_total	= total("MTX", mutexes_taken, nummx);
	sem_total	= total("SEM", semaphores_taken, numsm);
	rd_total	= total("RD ", reads_taken, numrd);
	wr_total	= total("WR ", writes_taken, numwr);
	dg_total	= total("DG ", downgrades_taken, numdg);

	/* print the results */
	if (verbose) {
		printk("mutexes taken: %u\n", mutex_total);
		printk("semaphores taken: %u\n", sem_total);
		printk("reads taken: %u\n", rd_total);
		printk("writes taken: %u\n", wr_total);
		printk("downgrades taken: %u\n", dg_total);
	}
	else {
		printk("%3d %3d %3d %3d %3d %c %3d %9u %9u %9u %9u %9u\n",
		       nummx, numsm, numrd, numwr, numdg,
		       do_sched ? 's' : '-',
		       load,
		       mutex_total,
		       sem_total,
		       rd_total,
		       wr_total,
		       dg_total);
	}

	/* tell insmod to discard the module */
	if (verbose)
		printk("Tests complete\n");
	return -ENOANO;

} /* end do_tests() */

module_init(do_tests);

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:57                 ` David Howells
                                     ` (2 preceding siblings ...)
  2005-12-16 11:02                   ` David Howells
@ 2005-12-16 11:30                   ` David Howells
  2005-12-16 16:33                     ` Linus Torvalds
  3 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-16 11:30 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen,
	torvalds, hch, matthew, linux-kernel, linux-arch

David Howells <dhowells@redhat.com> wrote:

> No, they're not. LL/SC is more flexible than CMPXCHG because under some
> circumstances, you can get away without doing the SC,

Of course, CMPXCHG doesn't have to store either, though it still performs a
locked-write-cycle on x86 if I remember correctly.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-14 11:46     ` David Howells
  2005-12-14 21:23       ` Nick Piggin
@ 2005-12-16 12:00       ` David Howells
  2005-12-16 13:16         ` Nick Piggin
                           ` (2 more replies)
  1 sibling, 3 replies; 249+ messages in thread
From: David Howells @ 2005-12-16 12:00 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> I was under the impression that with cmpxchg, you don't need the mutex lock.
> If you do then sure, cmpxchg doesn't buy you anything (even if the arch does
> natively support it).

Consider the slow path...

Imagine the mutex has three states: 0 (unset), 1 (held), 3 (contention).

	MUTEX	PROCESS A	PROCESS B	PROCESS C
	======	==============	==============	==============
	1,B,-
	1,B,-	-->mutex_lock()
	1,B,-	cmpxchg(0,1) [failed]
	1,B,-	-->__mutex_lock()
	1,B,-			-->mutex_unlock()
	1,B,-			cmpxchg(1,0) [success]
	0,-,-			<--mutex_unlock()
	0,-,-	spin_lock
	0,-,A	cmpxchg(0,1) [success]
	1,A,A	spin_unlock
	1,A,-	<--__mutex_lock()
	1,A,-	<--mutex_lock()

Or:

	MUTEX	PROCESS A	PROCESS B	PROCESS C
	======	==============	==============	==============	
	1,B,-
	1,B,-	-->mutex_lock()
	1,B,-	cmpxchg(0,1) [failed]
	1,B,-	-->__mutex_lock()
	1,B,-	spin_lock
	1,B,A	cmpxchg(0,1) [failed]
	1,B,A			-->mutex_unlock()
	1,B,A			cmpxchg(1,0) [success]
	0,-,A			<--mutex_unlock()
	0,-,A	cmpxchg(1,3) [failed]
	0,-,A	cmpxchg(0,1) [success]
	1,A,A	spin_unlock
	1,A,-	<--__mutex_lock()
	1,A,-	<--mutex_lock()

Or:

	MUTEX	PROCESS A	PROCESS B	PROCESS C
	======	==============	==============	==============
	1,B,-
	1,B,-	-->mutex_lock()
	1,B,-	cmpxchg(0,1) [failed]
	1,B,-	-->__mutex_lock()
	1,B,-	spin_lock
	1,B,A	cmpxchg(0,1) [failed]
	1,B,A			-->mutex_unlock()
	1,B,A			cmpxchg(1,0) [success]
	0,-,A			<--mutex_unlock()
	0,-,A	cmpxchg(1,3) [failed]
	0,-,A					-->mutex_lock()
	0,-,A					cmpxchg(0,1) [success]
	1,C,A					<--mutex_lock()
	1,C,A	cmpxchg(0,1) [failed]
	1,C,A	cmpxchg(1,3) [success]
	3,A,A	spin_unlock
	3,A,-	<--__mutex_lock()
	3,A,-	<--mutex_lock()

See how many cmpxchgs you may end up doing? Now imagine that cmpxchg() is
implemented as:

	spin_lock_irqsave(&common_lock[N], flags);
	actual = *state;
	if (actual == old)
		*state = new;
	spin_unlock_irqrestore(&common_lock[N], flags);

Now my point about using LL/SC is that:

	1,C,A	cmpxchg(0,1) [failed]
	1,C,A	cmpxchg(1,3) [success]
	3,C,A	...

Can be turned into:

	1,C,A	x = LL()
	1,C,A	x |= 2;
	1,C,A	SC(3) [success]
	3,C,A	...

On x86 you could use:

	1,C,A	LOCK OR (2)
	3,C,A	...

instead.

Now, contention isn't very likely, so using CMPXCHG _may_ be good enough _if_
you have it. But if you have to emulate it by using spinlocks, you're far
better off just wrapping the entire thing in spinlocks and not pretending use
atomic ops to access the counter; unless, of course, you have somthing that
can do a 1-bit XCHG or better...

	MUTEX	PROCESS A	PROCESS B	PROCESS C
	======	==============	==============	==============
	0,-,-			-->mutex_lock()
	0,-,-			xchg(1) == 0
	1,B,-			<--mutex_lock()
	1,B,-
	1,B,-	-->mutex_lock()
	1,B,-	xchg(1) == 1
	1,B,-	-->__mutex_lock()
	1,B,-			-->mutex_unlock()
	1,B,B			spin_lock
	1,B,B			set(0)
	0,-,B			spin_unlock
	0,-,-			<--mutex_unlock()
	0,-,-	spin_lock
	0,-,A	xchg(1) == 0
	1,A,A	spin_unlock
	1,A,-	<--__mutex_lock()
	1,A,-	<--mutex_lock()

mutex_unlock() should get the spinlock here before modifying the count,
because if there's anything on the queue, it should wake up the first waiter
rather than clearing the count.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 11:02                   ` David Howells
@ 2005-12-16 13:01                     ` Nick Piggin
  2005-12-16 13:21                       ` Russell King
  2005-12-17 15:57                       ` Nikita Danilov
  2005-12-16 16:28                     ` Linus Torvalds
  1 sibling, 2 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-16 13:01 UTC (permalink / raw)
  To: David Howells
  Cc: Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen, torvalds,
	hch, matthew, linux-kernel, linux-arch

David Howells wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>> (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64,
>>>sparc.
>>> (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.
>>>
>>
>>cmpxchg is basically exactly equivalent to a store-conditional, so 2 and 3
>>are the same level.
> 
> 
> No, they're not. LL/SC is more flexible than CMPXCHG because under some
> circumstances, you can get away without doing the SC, and because sometimes
> you can do one LL/SC in lieu of two CMPXCHG's because LL/SC allows you to
> retrieve the value, consider it and then modify it if you want to. With
> CMPXCHG you have to anticipate, and so you're more likely to get it wrong.
> 

I don't think that is more flexible, just different. For example with
cmpxchg you may not have to do the explicit load if you anticipate an
unlocked mutex as the fastpath.

My point is that they are of semantically equal strength.

> 
>>I don't know why you don't implement a "good" default implementation with
>>atomic_cmpxchg.
> 
> 
> Because it wouldn't be a good default.

You were proposing a worse default, which is the reason I suggested it.

> I'm thinking the best default is simply
> to wrap a counting semaphore.

Probably.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 12:00       ` David Howells
@ 2005-12-16 13:16         ` Nick Piggin
  2005-12-16 15:53         ` David Howells
  2005-12-16 16:02         ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-16 13:16 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:

> See how many cmpxchgs you may end up doing? Now imagine that cmpxchg() is
> implemented as:
> 

Yes, 2 architectures do this and they would probably want to optimise it.

> 	spin_lock_irqsave(&common_lock[N], flags);
> 	actual = *state;
> 	if (actual == old)
> 		*state = new;
> 	spin_unlock_irqrestore(&common_lock[N], flags);
> 
> Now my point about using LL/SC is that:
> 
> 	1,C,A	cmpxchg(0,1) [failed]
> 	1,C,A	cmpxchg(1,3) [success]
> 	3,C,A	...
> 
> Can be turned into:
> 
> 	1,C,A	x = LL()
> 	1,C,A	x |= 2;
> 	1,C,A	SC(3) [success]
> 	3,C,A	...
> 
> On x86 you could use:
> 
> 	1,C,A	LOCK OR (2)
> 	3,C,A	...
> 
> instead.
> 
> Now, contention isn't very likely, so using CMPXCHG _may_ be good enough _if_
> you have it. But if you have to emulate it by using spinlocks, you're far
> better off just wrapping the entire thing in spinlocks and not pretending use
> atomic ops to access the counter; unless, of course, you have somthing that

Yes, the architecture code knows whether or not it implements atomic ops
with spinlocks, so that architecture is in the position to decide to override
the mutex implementation. *generic* code shouldn't worry about that, it should
use the interfaces available, and if that isn't optimal on some architecture
then that architecture can override it.

It is not even clear that any ll/sc based architectures would need to override
an atomic_cmpxchg variant at all because you can assume an unlocked fastpath
and not do the additional initial load to prime the cmpxchg.

So I don't know why you're so worried about sparc32 and parisc while preferring
to introduce a worse default implementation that even your frv architecture wants
to override...?

However: considering everyone and their dog has already implemented their own
semaphore, the best mutex default I guess is to probably use that as you say.
So: disregard my suggestion :P

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 13:01                     ` Nick Piggin
@ 2005-12-16 13:21                       ` Russell King
  2005-12-16 13:41                         ` Nick Piggin
  2005-12-16 13:46                         ` Linh Dang
  2005-12-17 15:57                       ` Nikita Danilov
  1 sibling, 2 replies; 249+ messages in thread
From: Russell King @ 2005-12-16 13:21 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	cfriesen, torvalds, hch, matthew, linux-kernel, linux-arch

On Sat, Dec 17, 2005 at 12:01:27AM +1100, Nick Piggin wrote:
> You were proposing a worse default, which is the reason I suggested it.

I'd like to qualify that.  "for architectures with native cmpxchg".

For general consumption (not specifically related to mutex stuff)...

For architectures with llsc, sequences stuch as:

	load
	modify
	cmpxchg

are inefficient because they have to be implemented as:

	load
	modify
	load
	compare
	store conditional

Now, if we consider using llsc as the basis of atomic operations:

	load
	modify
	store conditional

and for cmpxchg-based architectures:

	load
	modify
	cmpxchg

Notice that the cmpxchg-based case does _not_ get any worse - in fact
it's exactly identical.  Note, however, that the llsc case becomes
more efficient.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 13:21                       ` Russell King
@ 2005-12-16 13:41                         ` Nick Piggin
  2005-12-16 13:46                         ` Linh Dang
  1 sibling, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-16 13:41 UTC (permalink / raw)
  To: Russell King
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	cfriesen, torvalds, hch, matthew, linux-kernel, linux-arch

Russell King wrote:
> On Sat, Dec 17, 2005 at 12:01:27AM +1100, Nick Piggin wrote:
> 
>>You were proposing a worse default, which is the reason I suggested it.
> 
> 
> I'd like to qualify that.  "for architectures with native cmpxchg".
> 
> For general consumption (not specifically related to mutex stuff)...
> 
> For architectures with llsc, sequences stuch as:
> 
> 	load
> 	modify
> 	cmpxchg
> 
> are inefficient because they have to be implemented as:
> 
> 	load
> 	modify
> 	load
> 	compare
> 	store conditional
> 
> Now, if we consider using llsc as the basis of atomic operations:
> 
> 	load
> 	modify
> 	store conditional
> 
> and for cmpxchg-based architectures:
> 
> 	load
> 	modify
> 	cmpxchg
> 
> Notice that the cmpxchg-based case does _not_ get any worse - in fact
> it's exactly identical.  Note, however, that the llsc case becomes
> more efficient.
> 

True in many cases. However in a lock fastpath one could do the
atomic_cmpxchg without an initial load, assuming the lock is
unlocked.

atomic_cmpxchg(&lock, UNLOCKED, LOCKED)

which should basically wind up to the most optimal code on both the
cmpxchg and ll/sc platforms (aside from other quirks David pointed
out like cmpxchg being worse than lock inc on x86).

Ah - I see you pointed out "for general consumption", I missed that.
Indeed for general consumption one should still be careful using
atomic_cmpxchg.

Nick

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 13:21                       ` Russell King
  2005-12-16 13:41                         ` Nick Piggin
@ 2005-12-16 13:46                         ` Linh Dang
  2005-12-16 14:31                           ` Russell King
  2005-12-16 15:46                           ` David Howells
  1 sibling, 2 replies; 249+ messages in thread
From: Linh Dang @ 2005-12-16 13:46 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	Christopher Friesen, torvalds, hch, matthew, linux-kernel,
	linux-arch


Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Sat, Dec 17, 2005 at 12:01:27AM +1100, Nick Piggin wrote:
>> You were proposing a worse default, which is the reason I suggested
>> it.
>
> I'd like to qualify that.  "for architectures with native cmpxchg".
>
> For general consumption (not specifically related to mutex stuff)...
>
> For architectures with llsc, sequences stuch as:
>
> 	load
> 	modify
> 	cmpxchg
>
> are inefficient because they have to be implemented as:
>
> 	load
> 	modify
> 	load
> 	compare
> 	store conditional
>

I dont know what arch u have in mind but for ppc it is:

        load-reserve
        modify
        store-conditional

and NOT the sequence you show.

-- 
Linh Dang

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 13:46                         ` Linh Dang
@ 2005-12-16 14:31                           ` Russell King
  2005-12-16 15:24                             ` Linh Dang
  2005-12-16 15:49                             ` Linh Dang
  2005-12-16 15:46                           ` David Howells
  1 sibling, 2 replies; 249+ messages in thread
From: Russell King @ 2005-12-16 14:31 UTC (permalink / raw)
  To: Linh Dang
  Cc: Nick Piggin, David Howells, Arjan van de Ven, Andrew Morton,
	Alan Cox, Christopher Friesen, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Fri, Dec 16, 2005 at 08:46:44AM -0500, Linh Dang wrote:
> 
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> 
> > On Sat, Dec 17, 2005 at 12:01:27AM +1100, Nick Piggin wrote:
> >> You were proposing a worse default, which is the reason I suggested
> >> it.
> >
> > I'd like to qualify that.  "for architectures with native cmpxchg".
> >
> > For general consumption (not specifically related to mutex stuff)...
> >
> > For architectures with llsc, sequences stuch as:
> >
> > 	load
> > 	modify
> > 	cmpxchg
> >
> > are inefficient because they have to be implemented as:
> >
> > 	load
> > 	modify
> > 	load
> > 	compare
> > 	store conditional
> >
> 
> I dont know what arch u have in mind but for ppc it is:
> 
>         load-reserve
>         modify
>         store-conditional
> 
> and NOT the sequence you show.

Wrong - because you haven't understood what I'm getting at.  If you're
using "cmpxchg" as the low level generic atomic operation (as in the
atomic_cmpxchg() function) then atomic_cmpxchg _has_ to be implemented
on llsc as:

	load (reserve if you need this detail)
	compare
	store conditional

So, let's illustrate this.  Let's say you want to atomically multiply
a value by N.

	do {
		old = atomic_read(&foo);
		new = old * N;
	} while(atomic_cmpxchg(&foo, old, new) != old);

For an architecture supporting cmpxchg, this becomes:

loop:	load foo => old
	new = old * N
	cmpxchg ret, old, new, foo
	compare ret & old
	if not equal goto loop

And for architectures with llsc, this becomes:

loop:	load foo => old
	new = old * N
loop2:	load locked foo => ret
	compare ret & old
	if equal store conditional new in foo
		if store failed because we lost the lock, goto loop2
	compare ret & old
	if not equal goto loop

Do you now see what I mean?  (yup, ARM is a llsc architecture.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 14:31                           ` Russell King
@ 2005-12-16 15:24                             ` Linh Dang
  2005-12-16 15:35                               ` Nick Piggin
  2005-12-16 15:40                               ` Kyle Moffett
  2005-12-16 15:49                             ` Linh Dang
  1 sibling, 2 replies; 249+ messages in thread
From: Linh Dang @ 2005-12-16 15:24 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	Christopher Friesen, torvalds, hch, matthew, linux-kernel,
	linux-arch

Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Fri, Dec 16, 2005 at 08:46:44AM -0500, Linh Dang wrote:
>>
>> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>>
>>> On Sat, Dec 17, 2005 at 12:01:27AM +1100, Nick Piggin wrote:
>>>> You were proposing a worse default, which is the reason I
>>>> suggested it.
>>>
>>> I'd like to qualify that.  "for architectures with native
>>> cmpxchg".
>>>
>>> For general consumption (not specifically related to mutex
>>> stuff)...
>>>
>>> For architectures with llsc, sequences stuch as:
>>>
>>> 	load
>>> 	modify
>>> 	cmpxchg
>>>
>>> are inefficient because they have to be implemented as:
>>>
>>> 	load
>>> 	modify
>>> 	load
>>> 	compare
>>> 	store conditional
>>>
>>
>> I dont know what arch u have in mind but for ppc it is:
>>
>> load-reserve
>> modify
>> store-conditional
>>
>> and NOT the sequence you show.
>
> Wrong - because you haven't understood what I'm getting at.  If
> you're using "cmpxchg" as the low level generic atomic operation (as
> in the atomic_cmpxchg() function) then atomic_cmpxchg _has_ to be
> implemented on llsc as:
>
> 	load (reserve if you need this detail)
> 	compare
> 	store conditional
>
> So, let's illustrate this.  Let's say you want to atomically
> multiply a value by N.
>
> 	do {
> 		old = atomic_read(&foo);
> 		new = old * N;
> 	} while(atomic_cmpxchg(&foo, old, new) != old);
>
> For an architecture supporting cmpxchg, this becomes:
>
> loop:	load foo => old
> 	new = old * N
> 	cmpxchg ret, old, new, foo
> 	compare ret & old
> 	if not equal goto loop
>
> And for architectures with llsc, this becomes:
>
> loop:	load foo => old
> 	new = old * N
> loop2:	load locked foo => ret
> 	compare ret & old
> 	if equal store conditional new in foo
> 		if store failed because we lost the lock, goto loop2
> 	compare ret & old
> 	if not equal goto loop
>
> Do you now see what I mean?  (yup, ARM is a llsc architecture.)

Well, it may be true for ARM but for ppc (i dunno what exactly llsc
means but someone in the thread put ppc in llsc group)  it's:

   loop:
        load-reserve foo => old
        new = old * N
        store-conditional new => foo
        if failed goto loop     

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 15:24                             ` Linh Dang
@ 2005-12-16 15:35                               ` Nick Piggin
  2005-12-16 15:40                               ` Kyle Moffett
  1 sibling, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-16 15:35 UTC (permalink / raw)
  To: Linh Dang
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	Christopher Friesen, torvalds, hch, matthew, linux-kernel,
	linux-arch

Linh Dang wrote:

>>Do you now see what I mean?  (yup, ARM is a llsc architecture.)
> 
> 
> Well, it may be true for ARM but for ppc (i dunno what exactly llsc
> means but someone in the thread put ppc in llsc group)  it's:
> 

load locked or load with lock, IIRC.

>    loop:
>         load-reserve foo => old
>         new = old * N
>         store-conditional new => foo
>         if failed goto loop     
> 

The point is that the typical use case for a cmpxchg is less optimal
if cmpxchg is simulated with llsc than if the same functionality were
directly implemented with llsc instructions.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 15:24                             ` Linh Dang
  2005-12-16 15:35                               ` Nick Piggin
@ 2005-12-16 15:40                               ` Kyle Moffett
  1 sibling, 0 replies; 249+ messages in thread
From: Kyle Moffett @ 2005-12-16 15:40 UTC (permalink / raw)
  To: Linh Dang
  Cc: Nick Piggin, David Howells, Arjan van de Ven, Andrew Morton,
	Alan Cox, Christopher Friesen, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Dec 16, 2005, at 10:24, Linh Dang wrote:
> Well, it may be true for ARM but for ppc (i dunno what exactly llsc  
> means but someone in the thread put ppc in llsc group)  it's:
>
>    loop:
>         load-reserve foo => old
>         new = old * N
>         store-conditional new => foo
>         if failed goto loop

LLSC == Load-Locked/Store-Conditional.  It's a slightly different  
name for your Load-Reserve/Store-Conditional

You still miss his point.  That is _GOOD_ code.  Russell's point is  
that if somebody does this in generic code:

do {
	old = atomic_read(&foo);
	new = old * 2;
} while (atomic_cmpxchg(&foo, old, new) != old);

On PPC or ARM or another LLSC architecture it does not end up looking  
like the good code, it looks like this (which is clearly inefficient):

>> And for architectures with llsc, this becomes:
>>
>> loop:	load foo => old
>> 	new = old * N
>> loop2:	load locked foo => ret
>> 	compare ret & old
>> 	if equal store conditional new in foo
>> 		if store failed because we lost the lock, goto loop2
>> 	compare ret & old
>> 	if not equal goto loop

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/E/U d- s++: a18 C++++>$ ULBX*++++(+++)>$ P++++(+++)>$ L++++ 
(+++)>$ !E- W+++(++) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP 
+ t+(+++) 5 X R? !tv-(--) b++++(++) DI+(++) D+++ G e>++++$ h*(+)>++$ r 
%(--)  !y?-(--)
------END GEEK CODE BLOCK------




^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 13:46                         ` Linh Dang
  2005-12-16 14:31                           ` Russell King
@ 2005-12-16 15:46                           ` David Howells
  2005-12-16 15:58                             ` Russell King
  1 sibling, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-16 15:46 UTC (permalink / raw)
  To: Russell King
  Cc: Linh Dang, Nick Piggin, David Howells, Arjan van de Ven,
	Andrew Morton, Alan Cox, Christopher Friesen, torvalds, hch,
	matthew, linux-kernel, linux-arch

Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Do you now see what I mean?  (yup, ARM is a llsc architecture.)

Out of interest, at what point did ARM become so? ARM6?

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 14:31                           ` Russell King
  2005-12-16 15:24                             ` Linh Dang
@ 2005-12-16 15:49                             ` Linh Dang
  1 sibling, 0 replies; 249+ messages in thread
From: Linh Dang @ 2005-12-16 15:49 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, Arjan van de Ven, Andrew Morton, Alan Cox,
	Christopher Friesen, torvalds, hch, matthew, linux-kernel,
	linux-arch

Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> Do you now see what I mean?  (yup, ARM is a llsc architecture.)

Oh, I do see your point now! sorry for all the newbie noise!

-- 
Linh Dang

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 12:00       ` David Howells
  2005-12-16 13:16         ` Nick Piggin
@ 2005-12-16 15:53         ` David Howells
  2005-12-16 23:41           ` Nick Piggin
  2005-12-16 16:02         ` David Howells
  2 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-16 15:53 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Yes, the architecture code knows whether or not it implements atomic ops
> with spinlocks, so that architecture is in the position to decide to override
> the mutex implementation. *generic* code shouldn't worry about that, it should
> use the interfaces available, and if that isn't optimal on some architecture
> then that architecture can override it.

However, a number of generic templates can be provided if it makes things
easier for the arches because all they need to is:

	[arch/wibble/Kconfig]
	config MUTEX_TYPE_FOO
		bool
		default y

	[include/asm-wibble/system.h]
	#define __mutex_foo_this() { ... }
	#define __mutex_foo_that() { ... }

The unconditional two-state exchange I think will be a useful template for a
number of archs that don't have anything more advanced than XCHG/TAS/BSET/SWAP.

> It is not even clear that any ll/sc based architectures would need to override
> an atomic_cmpxchg variant at all because you can assume an unlocked fastpath

That's irrelevant. Any arch that has LL/SC almost certainly emulates CMPXCHG
with LL/SC.

> and not do the additional initial load to prime the cmpxchg.

Two points:

 (1) LL/SC does not require an additional initial load.

 (2) CMPXCHG does an implicit load; how else can it compare?

LL/SC can never be worse than CMPXCHG, if only because you're very unlikely to
have both, but it can be better.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 15:46                           ` David Howells
@ 2005-12-16 15:58                             ` Russell King
  0 siblings, 0 replies; 249+ messages in thread
From: Russell King @ 2005-12-16 15:58 UTC (permalink / raw)
  To: David Howells
  Cc: Linh Dang, Nick Piggin, Arjan van de Ven, Andrew Morton,
	Alan Cox, Christopher Friesen, torvalds, hch, matthew,
	linux-kernel, linux-arch

On Fri, Dec 16, 2005 at 03:46:41PM +0000, David Howells wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> 
> > Do you now see what I mean?  (yup, ARM is a llsc architecture.)
> 
> Out of interest, at what point did ARM become so? ARM6?

Yes, ARM architecture version 6.

See the ldrex (load exclusive) / strex (store exclusive) instructions.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 12:00       ` David Howells
  2005-12-16 13:16         ` Nick Piggin
  2005-12-16 15:53         ` David Howells
@ 2005-12-16 16:02         ` David Howells
  2 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-16 16:02 UTC (permalink / raw)
  To: Nick Piggin
  Cc: David Howells, torvalds, akpm, hch, arjan, matthew, linux-kernel,
	linux-arch

Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> So I don't know why you're so worried about sparc32 and parisc while
> preferring to introduce a worse default implementation that even your frv
> architecture wants to override...?

I now think the base default should be a wrapper around the counting
semaphores, because that is the easiest path (they already exist) and it's
also the fastest path on some platforms.

But I want to be able to override the implementation on such as FRV because I
can do a better mutex than a counting semaphore there as I only have SWAP
available as an atomic op.

However, I would like to make the unconditional-exchange mutex a template that
can be overridden so that other archs can use it with one Kconfig option and a
few #defines in asm/system.h.

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 11:02                   ` David Howells
  2005-12-16 13:01                     ` Nick Piggin
@ 2005-12-16 16:28                     ` Linus Torvalds
  1 sibling, 0 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-16 16:28 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen,
	hch, matthew, linux-kernel, linux-arch



On Fri, 16 Dec 2005, David Howells wrote:
> 
> No, they're not. LL/SC is more flexible than CMPXCHG because under some
> circumstances, you can get away without doing the SC, and because sometimes
> you can do one LL/SC in lieu of two CMPXCHG's because LL/SC allows you to
> retrieve the value, consider it and then modify it if you want to. With
> CMPXCHG you have to anticipate, and so you're more likely to get it wrong.

You can think of LL/SC as directly translating into LD/CMPXCHG, so in that 
sense CMPXCHG is no less flexible. LL/SC still has other advantages, 
though. See later.

> I've had a play with x86, and on there CMPXCHG, XCHG and XADD give worse
> performance than INC/DEC for some reason. I assume this is something to do
> with how the PPro CPU optimises itself. On PPro CPUs at least, counting
> semaphores really are the most efficient way. CMPXCHG, whilst it ought to be
> better, really isn't.

The notion that CMPXCHG "ought to be better" is a load of bull.

There are two advantages of "lock inc/dec" over "ld/cmpxchg": one is the 
obvious one that the CPU core just has a much easier time with the 
unconditional one, and never has to worry about things like conditional 
branches or waste cycles on multiple instructions. Just compare the 
sequences:

	lock inc mem

vs

   back:
	load mem,reg1
	reg2 = reg1+1
	cmpxchg mem,reg1,reg2
	jne forward		# get branch prediction right
	return
   forward:
	jmp back

guess which one is faster?

The other one depends on cache coherency: the "lock inc" can just get the 
cacheline for exclusive use immediately ("read with intent to write"). In 
contrast, the ld/cmpxchg first gets the cacheline for reading, and then 
has to turn it into an exclusive one. IOW, there may literally be lots of 
extra bus traffic from doing a load first.

In other words, there are several advantages to just using the simple 
instructions. 

(Of course, some CPU's have "get cacheline for write" instructions, so you 
can then make the second sequence even longer by using that).

Using "xadd" should be fine, although for all I know, even then 
microarchitectural issues may make it cheaper to use the simpler "lock 
add" whenever possible.

In LL/SC, I _think_ LL generally does its read with intent to write. 

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 11:30                   ` David Howells
@ 2005-12-16 16:33                     ` Linus Torvalds
  2005-12-16 22:23                       ` David S. Miller
  0 siblings, 1 reply; 249+ messages in thread
From: Linus Torvalds @ 2005-12-16 16:33 UTC (permalink / raw)
  To: David Howells
  Cc: Nick Piggin, Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen,
	hch, matthew, linux-kernel, linux-arch



On Fri, 16 Dec 2005, David Howells wrote:
> 
> Of course, CMPXCHG doesn't have to store either, though it still performs a
> locked-write-cycle on x86 if I remember correctly.

It does so on any sane architecture (side note: you don't do locked 
memory cycles on the bus these days. You do cache coherency protocols).

>From a bus standpoint you _have_ to do the initial read with intent to 
write, nothing else makes any sense. You'll just waste bus cycles 
otherwise. Sure, the write may never come, but it just isn't sensible to 
optimize for the case where the compare will fail. If that's the common 
case, then software is doing something wrong (it should do just a much 
cheaper "load + compare" first if it knows it's probably going to fail).

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 20:32                                     ` Geert Uytterhoeven
@ 2005-12-16 21:41                                       ` Thomas Gleixner
  2005-12-16 21:41                                         ` Linus Torvalds
  0 siblings, 1 reply; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-16 21:41 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells, Linus Torvalds

On Thu, 2005-12-15 at 21:32 +0100, Geert Uytterhoeven wrote:
> > Why have the "MUTEX" part in there?  Shouldn't that just be DECLARE_SEM
> > (oops, I mean DEFINE_SEM).  Especially that MUTEX_LOCKED! What is that?
> > How does a MUTEX start off as locked.  It can't, since a mutex must
> > always have an owner (which, by the way, helped us in the -rt patch to
> > find our "compat_semaphores").  So who's the owner of a
> > DEFINE_SEM_MUTEX_LOCKED?
> 
> No one. It's not really a mutex, but a completion.

Well, then let us use a completion and not some semantically wrong
workaround

	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 21:41                                       ` Thomas Gleixner
@ 2005-12-16 21:41                                         ` Linus Torvalds
  2005-12-16 22:06                                           ` Thomas Gleixner
  0 siblings, 1 reply; 249+ messages in thread
From: Linus Torvalds @ 2005-12-16 21:41 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Geert Uytterhoeven, Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells



On Fri, 16 Dec 2005, Thomas Gleixner wrote:

> On Thu, 2005-12-15 at 21:32 +0100, Geert Uytterhoeven wrote:
> > > Why have the "MUTEX" part in there?  Shouldn't that just be DECLARE_SEM
> > > (oops, I mean DEFINE_SEM).  Especially that MUTEX_LOCKED! What is that?
> > > How does a MUTEX start off as locked.  It can't, since a mutex must
> > > always have an owner (which, by the way, helped us in the -rt patch to
> > > find our "compat_semaphores").  So who's the owner of a
> > > DEFINE_SEM_MUTEX_LOCKED?
> > 
> > No one. It's not really a mutex, but a completion.
> 
> Well, then let us use a completion and not some semantically wrong
> workaround

It is _not_ wrong to have a semaphore start out in locked state.

For example, it makes perfect sense if the data structures that the 
semaphore needs need initialization. The way you _should_ handle that is 
to make the semaphore come up as locked, and the data structures in some 
"don't matter" state, and then the thing that initializes stuff can do so 
properly and then release the semaphore.

Yes, in some cases such a locked semaphore is only used once, and ends up 
being a "completion", but that doesn't invalidate the fact that this is 
a perfectly fine way to handle a real issue.

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 20:18                         ` Andrew Morton
  2005-12-15 21:28                           ` Steven Rostedt
@ 2005-12-16 22:02                           ` Thomas Gleixner
  1 sibling, 0 replies; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-16 22:02 UTC (permalink / raw)
  To: Andrew Morton
  Cc: dhowells, lkml, alan, pj, mingo, hch, torvalds, arjan, matthew,
	linux-kernel, linux-arch

On Thu, 2005-12-15 at 12:18 -0800, Andrew Morton wrote:

> Look at it from the POV of major architectures: there's no way the new
> mutex code will be faster than down() and up(), so we're adding a bunch of
> new tricky locking code which bloats the kernel and has to be understood
> and debugged for no gain.

Look at it from the semantical POV first, which is the most important
one.

semaphores are semantically different from mutexes, so they require
different APIs.

When you have semantically different APIs, you can still implement them
for whatever (e.g. peformance) reason on top of the same mechanism, but
you can not make this work the other way round.

	tglx
	



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 21:41                                         ` Linus Torvalds
@ 2005-12-16 22:06                                           ` Thomas Gleixner
  2005-12-16 22:19                                             ` Linus Torvalds
  0 siblings, 1 reply; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-16 22:06 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Geert Uytterhoeven, Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells

On Fri, 2005-12-16 at 13:41 -0800, Linus Torvalds wrote:
> 
> > > No one. It's not really a mutex, but a completion.
> > 
> > Well, then let us use a completion and not some semantically wrong
> > workaround
> 
> It is _not_ wrong to have a semaphore start out in locked state.
> 
> For example, it makes perfect sense if the data structures that the 
> semaphore needs need initialization. The way you _should_ handle that is 
> to make the semaphore come up as locked, and the data structures in some 
> "don't matter" state, and then the thing that initializes stuff can do so 
> properly and then release the semaphore.
> 
> Yes, in some cases such a locked semaphore is only used once, and ends up 
> being a "completion", but that doesn't invalidate the fact that this is 
> a perfectly fine way to handle a real issue.

Well, in case of a semaphore it is a semantically correct use case. In
case of of a mutex it is not.

Gerd was talking about a mutex. The fact that a mutex is implemented on
top (or on actually the same) mechanism as a semaphore - for what ever
reason - does not change the semantical difference between semaphores
and mutexes.

	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:06                                           ` Thomas Gleixner
@ 2005-12-16 22:19                                             ` Linus Torvalds
  2005-12-16 22:32                                               ` Steven Rostedt
  2005-12-16 22:42                                               ` Thomas Gleixner
  0 siblings, 2 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-16 22:19 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Geert Uytterhoeven, Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells



On Fri, 16 Dec 2005, Thomas Gleixner wrote:
> 
> Well, in case of a semaphore it is a semantically correct use case. In
> case of of a mutex it is not.

I disagree.

Think of "initialization" as a user. The system starts out initializing 
stuff, and as such the mutex should start out being held. It's that 
simple. It _is_ mutual exclusion, with one user being the early bootup 
state.

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 16:33                     ` Linus Torvalds
@ 2005-12-16 22:23                       ` David S. Miller
  2005-12-16 22:38                         ` Linus Torvalds
  0 siblings, 1 reply; 249+ messages in thread
From: David S. Miller @ 2005-12-16 22:23 UTC (permalink / raw)
  To: torvalds
  Cc: dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch, matthew,
	linux-kernel, linux-arch

From: Linus Torvalds <torvalds@osdl.org>
Date: Fri, 16 Dec 2005 08:33:10 -0800 (PST)

> From a bus standpoint you _have_ to do the initial read with intent to 
> write, nothing else makes any sense. You'll just waste bus cycles 
> otherwise. Sure, the write may never come, but it just isn't sensible to 
> optimize for the case where the compare will fail. If that's the common 
> case, then software is doing something wrong (it should do just a much 
> cheaper "load + compare" first if it knows it's probably going to fail).

Actually, this points out a problem with "compare and swap".  The
typical loop is of the form:

	LOAD [MEM], REG1
	OP   REG1, X, REG2
	CAS  [MEM], REG1, REG2

That first LOAD instruction, if it misses in the L2, causes the cache
line to be requested for sharing.  Then the CAS instruction will need
to issue another cache coherency transaction to get the cache line
into owned state.

Basically, this guarentees that you'll have 2 cache coherency
transactions, a huge waste, every time an atomic update sequence
executes for a data item not in cache already.

(Are there any CPUs that peek forward and look for the CAS
 instruction to decide to issue the more appropriate request
 for the cache line in Owned state?  That would be cool...)

At least with "load locked / store conditional" the cpu is being told
that we intend to write to that cache line, so it can request sole
ownership on the bus when the load misses.

The only workaround I can come up with is the do a prefetch for write
right before the LOAD.  I've been tempted to add this on sparc64 for a
long time.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:19                                             ` Linus Torvalds
@ 2005-12-16 22:32                                               ` Steven Rostedt
  2005-12-16 22:42                                               ` Thomas Gleixner
  1 sibling, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-16 22:32 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Geert Uytterhoeven, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells

On Fri, 2005-12-16 at 14:19 -0800, Linus Torvalds wrote:
> 
> On Fri, 16 Dec 2005, Thomas Gleixner wrote:
> > 
> > Well, in case of a semaphore it is a semantically correct use case. In
> > case of of a mutex it is not.
> 
> I disagree.
> 
> Think of "initialization" as a user. The system starts out initializing 
> stuff, and as such the mutex should start out being held. It's that 
> simple. It _is_ mutual exclusion, with one user being the early bootup 
> state.

That's stretching it quite a bit.  So you are saying that the owner is
the first swapper task, from the booting CPU?  Well, you better have
that same process unlock that mutex, since a mutex has a owner and the
owner _must_ be the one to unlock it.  And in lots of these cases, it's
some other thread that releases the lock.

With mutexs, the owner is not a state, but a task.

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:23                       ` David S. Miller
@ 2005-12-16 22:38                         ` Linus Torvalds
  2005-12-16 22:53                           ` David S. Miller
  0 siblings, 1 reply; 249+ messages in thread
From: Linus Torvalds @ 2005-12-16 22:38 UTC (permalink / raw)
  To: David S. Miller
  Cc: dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch, matthew,
	linux-kernel, linux-arch



On Fri, 16 Dec 2005, David S. Miller wrote:
> 
> Actually, this points out a problem with "compare and swap".  The
> typical loop is of the form:
> 
> 	LOAD [MEM], REG1
> 	OP   REG1, X, REG2
> 	CAS  [MEM], REG1, REG2
> 
> That first LOAD instruction, if it misses in the L2, causes the cache
> line to be requested for sharing.  Then the CAS instruction will need
> to issue another cache coherency transaction to get the cache line
> into owned state.

A number of architectures have a "prefetch for write ownership" 
instruction that you can use for this. Exactly because "ld+cas" should 
not get a shared line initially.

I though sparc had an ASI to do the same? No?

> (Are there any CPUs that peek forward and look for the CAS
>  instruction to decide to issue the more appropriate request
>  for the cache line in Owned state?  That would be cool...)

I don't think anybody does, although it wouldn't be impossible. Any OoO 
processor would _tend_ to have enough visibility that they could see any 
stores that are "close" (not just a cas) and might be clever enough to 
modify a memory read to be a read-with-intent-to-write op.

Of course, if it was in memory (as opposed to somebody elses caches), I 
think most cache protocols will start it up in exclusive state anyway. 
Same may or may not happen when you have a dirty hit on another CPU that 
requires a write-back (ie the other CPU would always invalidate on 
writeback).

It would seem to be the obvious thing to do for better lock performance, 
and I'd assume that locks are some of the most common cases of real cache 
interactions, so maybe the shared case only effectively happens if two 
CPU's are reading at the same time.

Somebody who looks at cache protocol diagrams could check. I'm too lazy.

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:42                                               ` Thomas Gleixner
@ 2005-12-16 22:41                                                 ` Linus Torvalds
  2005-12-16 22:49                                                   ` Steven Rostedt
                                                                     ` (2 more replies)
  0 siblings, 3 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-16 22:41 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Geert Uytterhoeven, Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells



On Fri, 16 Dec 2005, Thomas Gleixner wrote:
> 
> Therefor, if you want to handle that "init protection" scenario, do not
> use a mutex, because the owner can not be defined at compile -
> allocation time.

Sure it could. We certainly have "init_task", for example. It may or may 
not be the right thing to use, of course. Depends on what the situation 
is.

> You can still implement (chose a mechanism) a mutex on top - or in case
> of lack of priority inheritance or debugging with exactly the same -
> mechanism as a semaphore, but this does not change the semantical
> difference at all.

"Friends don't let friends use priority inheritance".

Just don't do it. If you really need it, your system is broken anyway.

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:19                                             ` Linus Torvalds
  2005-12-16 22:32                                               ` Steven Rostedt
@ 2005-12-16 22:42                                               ` Thomas Gleixner
  2005-12-16 22:41                                                 ` Linus Torvalds
  1 sibling, 1 reply; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-16 22:42 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Geert Uytterhoeven, Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells

On Fri, 2005-12-16 at 14:19 -0800, Linus Torvalds wrote:
> 
> On Fri, 16 Dec 2005, Thomas Gleixner wrote:
> > 
> > Well, in case of a semaphore it is a semantically correct use case. In
> > case of of a mutex it is not.
> 
> I disagree.
> 
> Think of "initialization" as a user. The system starts out initializing 
> stuff, and as such the mutex should start out being held. It's that 
> simple. It _is_ mutual exclusion, with one user being the early bootup 
> state.

Mutual exclusion is available with various semantical characteristics.
If you want to have a particular semantical functionality you have to
chose a variant which fits that need. Arguing that the underlying
mechanism (implemenation) can handle your request is broken by
definition. It can, but it still is semantically wrong.

Mutexes have a well defined semantic of lock ownership, i.e. the thread
which locked a mutex has to unlock it. Semaphores do not have this
semantical requirement.

Therefor, if you want to handle that "init protection" scenario, do not
use a mutex, because the owner can not be defined at compile -
allocation time.

You can still implement (chose a mechanism) a mutex on top - or in case
of lack of priority inheritance or debugging with exactly the same -
mechanism as a semaphore, but this does not change the semantical
difference at all.

	tglx





^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:41                                                 ` Linus Torvalds
@ 2005-12-16 22:49                                                   ` Steven Rostedt
  2005-12-16 23:29                                                   ` Thomas Gleixner
  2005-12-17  0:29                                                   ` Joe Korty
  2 siblings, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-16 22:49 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Geert Uytterhoeven, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells



On Fri, 16 Dec 2005, Linus Torvalds wrote:

>
> "Friends don't let friends use priority inheritance".
>
> Just don't do it. If you really need it, your system is broken anyway.

You've been hanging around Victor Yodaiken too much ;)

-- Steve

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:38                         ` Linus Torvalds
@ 2005-12-16 22:53                           ` David S. Miller
  2005-12-17  0:41                             ` Jesse Barnes
  2005-12-17 22:38                             ` Richard Henderson
  0 siblings, 2 replies; 249+ messages in thread
From: David S. Miller @ 2005-12-16 22:53 UTC (permalink / raw)
  To: torvalds
  Cc: dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch, matthew,
	linux-kernel, linux-arch

From: Linus Torvalds <torvalds@osdl.org>
Date: Fri, 16 Dec 2005 14:38:47 -0800 (PST)

> A number of architectures have a "prefetch for write ownership" 
> instruction that you can use for this. Exactly because "ld+cas" should 
> not get a shared line initially.
> 
> I though sparc had an ASI to do the same? No?

No, no special ASI exists to do that, although it would be nice. :-)
I'd have to use a prefetch for write.

BTW, it is interesting that you can use CAS to get a cache line into
the local processor in Owned state with %100 certainty (unlike
prefetch for write which might get cancelled) by doing something like:

	CAS	[MEM], ZERO, ZERO

and you can do this to any valid memory address without changing the
contents.  This is useful for doing things like resetting parity bits
while doing memory error recorvery.

> It would seem to be the obvious thing to do for better lock performance, 
> and I'd assume that locks are some of the most common cases of real cache 
> interactions, so maybe the shared case only effectively happens if two 
> CPU's are reading at the same time.
> 
> Somebody who looks at cache protocol diagrams could check. I'm too lazy.

For both MOESI and MOSI cache coherency protocols, misses on loads
result in a Shared state cache line when another processor has the
data in it's cache too, regardless of whether that line in the other
cpu is dirty or not.

When the write comes along, the next transaction occurs to kick it
out the other cpu(s) caches and then the local line is placed into
Owned state.

I'll have to add "put write prefetch in CAS sequences" onto my sparc64
TODO list :-)

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:41                                                 ` Linus Torvalds
  2005-12-16 22:49                                                   ` Steven Rostedt
@ 2005-12-16 23:29                                                   ` Thomas Gleixner
  2005-12-17  0:29                                                   ` Joe Korty
  2 siblings, 0 replies; 249+ messages in thread
From: Thomas Gleixner @ 2005-12-16 23:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Geert Uytterhoeven, Steven Rostedt, Andrew Morton, linux-arch,
	Linux Kernel Development, matthew, arjan, Christoph Hellwig,
	mingo, Alan Cox, nikita, pj, dhowells

On Fri, 2005-12-16 at 14:41 -0800, Linus Torvalds wrote:

> > You can still implement (chose a mechanism) a mutex on top - or in case
> > of lack of priority inheritance or debugging with exactly the same -
> > mechanism as a semaphore, but this does not change the semantical
> > difference at all.
> 
> "Friends don't let friends use priority inheritance".
> 
> Just don't do it. If you really need it, your system is broken anyway.

We are not talking about priority inheritance and its usefulness at all.

Fact is that you can implement two semanticaly different concurrency
controls with or on top of the same mechanism under given circumstances
(no debugging, no ...). But the reverse attempt is wrong by defintion.


	tglx



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 15:53         ` David Howells
@ 2005-12-16 23:41           ` Nick Piggin
  0 siblings, 0 replies; 249+ messages in thread
From: Nick Piggin @ 2005-12-16 23:41 UTC (permalink / raw)
  To: David Howells
  Cc: torvalds, akpm, hch, arjan, matthew, linux-kernel, linux-arch

David Howells wrote:

>>It is not even clear that any ll/sc based architectures would need to override
>>an atomic_cmpxchg variant at all because you can assume an unlocked fastpath
> 
> 
> That's irrelevant. Any arch that has LL/SC almost certainly emulates CMPXCHG
> with LL/SC.
> 

It is not irrelevant because many architectures that would care are ll/sc
based and many others have a native cmpxchg ie. cmpxchg wouldn't be a bad
choice for default.

> 
>>and not do the additional initial load to prime the cmpxchg.
> 
> 
> Two points:
> 
>  (1) LL/SC does not require an additional initial load.
> 

?? I was only talking about cmpxchg

>  (2) CMPXCHG does an implicit load; how else can it compare?
> 

Read Russell's posts. He points out that most usages of cmpxchg
will require an additional load compared with an llsc in order to
find the value to work on.

cmpxchg(lock, UNLOCKED, LOCKED)

does not (although it may still require an extra branch).

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:41                                                 ` Linus Torvalds
  2005-12-16 22:49                                                   ` Steven Rostedt
  2005-12-16 23:29                                                   ` Thomas Gleixner
@ 2005-12-17  0:29                                                   ` Joe Korty
  2005-12-17  1:00                                                     ` Linus Torvalds
  2 siblings, 1 reply; 249+ messages in thread
From: Joe Korty @ 2005-12-17  0:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Geert Uytterhoeven, Steven Rostedt,
	Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells

On Fri, Dec 16, 2005 at 02:41:16PM -0800, Linus Torvalds wrote:

> "Friends don't let friends use priority inheritance".
> 
> Just don't do it. If you really need it, your system is broken anyway.

The Mars Pathfinder incident is sufficient proof that some solution to
the priority inversion problem is required in real systems.

	http://www.cs.cmu.edu/afs/cs/user/raj/www/mars.html

Regards,
Joe
--
"All the revision in the world will not save a bad first draft, for the
architecture of the thing comes, or fails to come, in the first conception,
and revision only affects the detail and ornament. -- T.E. Lawrence

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:53                           ` David S. Miller
@ 2005-12-17  0:41                             ` Jesse Barnes
  2005-12-17  7:10                               ` David S. Miller
  2005-12-17 22:38                             ` Richard Henderson
  1 sibling, 1 reply; 249+ messages in thread
From: Jesse Barnes @ 2005-12-17  0:41 UTC (permalink / raw)
  To: David S. Miller
  Cc: torvalds, dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch,
	matthew, linux-kernel, linux-arch

On Friday, December 16, 2005 2:53 pm, David S. Miller wrote:
> When the write comes along, the next transaction occurs to kick it
> out the other cpu(s) caches and then the local line is placed into
> Owned state.
>
> I'll have to add "put write prefetch in CAS sequences" onto my sparc64
> TODO list :-)

Note that under contention prefetching with a write bias can cause a lot 
more cache line bouncing than a regular load into shared state (assuming 
you do a load and test before you try the CAS).  We actually saw this on 
large Altix machines, 
http://lia64.bkbits.net:8080/to-linus-2.5/cset%403f2082b3xCvMG9OSeNu3aWhoe6jnOg?nav=index.html|
src/.|src/include|src/include/asm-ia64|
related/include/asm-ia64/spinlock.h fixed things up for us.

Jesse

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  0:29                                                   ` Joe Korty
@ 2005-12-17  1:00                                                     ` Linus Torvalds
  2005-12-17  3:13                                                       ` Steven Rostedt
  2005-12-19 23:46                                                       ` Keith Owens
  0 siblings, 2 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-17  1:00 UTC (permalink / raw)
  To: Joe Korty
  Cc: Thomas Gleixner, Geert Uytterhoeven, Steven Rostedt,
	Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells



On Fri, 16 Dec 2005, Joe Korty wrote:
> 
> The Mars Pathfinder incident is sufficient proof that some solution to
> the priority inversion problem is required in real systems.

Ehh. 

The Mars Pathfinder is just about the worst case "real system", and if I 
recall correctly, the reason it was able to continue was _not_ because it 
handled priority inversion, but because it reset itself every 24 hours or 
something like that, and had debugging facilities..

The _real_ lesson you should take away from it is not that priority 
inheritance is a good solution to priority inversion, but that having a 
failsafe switch when everthing goes wrong is critical. You don't know 
_what_ bug you'll encounter.

The bug itself could have been solved without priority inheritance, 
although I think in this case enabling that in VxWorks was the particular 
solution to the problem as being the least invasive.

Personally, I don't care what user space does. If some app wants to use 
priority inheritance to solve its bugs, that's fine. But it's like 
recursive locks: it's generally a _bandaid_ for bad locking. I definitely 
don't want the kernel depending on either.

So put a watchdog on your critical systems, and make sure you can debug 
them. Especially if they're on Mars.

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  1:00                                                     ` Linus Torvalds
@ 2005-12-17  3:13                                                       ` Steven Rostedt
  2005-12-17  7:34                                                         ` Linus Torvalds
  2005-12-19 23:46                                                       ` Keith Owens
  1 sibling, 1 reply; 249+ messages in thread
From: Steven Rostedt @ 2005-12-17  3:13 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joe Korty, Thomas Gleixner, Geert Uytterhoeven, Andrew Morton,
	linux-arch, Linux Kernel Development, matthew, arjan,
	Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells


On Fri, 16 Dec 2005, Linus Torvalds wrote:
>
> On Fri, 16 Dec 2005, Joe Korty wrote:
> >
> > The Mars Pathfinder incident is sufficient proof that some solution to
> > the priority inversion problem is required in real systems.
>
> Ehh.
>
> The Mars Pathfinder is just about the worst case "real system", and if I
> recall correctly, the reason it was able to continue was _not_ because it
> handled priority inversion, but because it reset itself every 24 hours or
> something like that, and had debugging facilities..
>
> The _real_ lesson you should take away from it is not that priority
> inheritance is a good solution to priority inversion, but that having a
> failsafe switch when everthing goes wrong is critical. You don't know
> _what_ bug you'll encounter.
>
> The bug itself could have been solved without priority inheritance,
> although I think in this case enabling that in VxWorks was the particular
> solution to the problem as being the least invasive.
>
> Personally, I don't care what user space does. If some app wants to use
> priority inheritance to solve its bugs, that's fine. But it's like
> recursive locks: it's generally a _bandaid_ for bad locking. I definitely
> don't want the kernel depending on either.

So how does one handle real-time tasks that must contend with locks within
the kernel that is shared with low priority tasks?  Do you prefer the RTAI
approach?

-- Steve


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  0:41                             ` Jesse Barnes
@ 2005-12-17  7:10                               ` David S. Miller
  2005-12-17  7:40                                 ` Linus Torvalds
  2005-12-17 17:19                                 ` Jesse Barnes
  0 siblings, 2 replies; 249+ messages in thread
From: David S. Miller @ 2005-12-17  7:10 UTC (permalink / raw)
  To: jbarnes
  Cc: torvalds, dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch,
	matthew, linux-kernel, linux-arch

From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri, 16 Dec 2005 16:41:49 -0800

> Note that under contention prefetching with a write bias can cause a lot 
> more cache line bouncing than a regular load into shared state (assuming 
> you do a load and test before you try the CAS).

If there is some test guarding the CAS, yes.

But if there isn't, for things like atomic increment and
decrement, where the CAS is unconditional, you'll always
eat the two bus transactions without the prefetch for write.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  3:13                                                       ` Steven Rostedt
@ 2005-12-17  7:34                                                         ` Linus Torvalds
  2005-12-17 23:43                                                           ` Matthew Wilcox
                                                                             ` (2 more replies)
  0 siblings, 3 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-17  7:34 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Joe Korty, Thomas Gleixner, Geert Uytterhoeven, Andrew Morton,
	linux-arch, Linux Kernel Development, matthew, arjan,
	Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells



On Fri, 16 Dec 2005, Steven Rostedt wrote:
> 
> So how does one handle real-time tasks that must contend with locks within
> the kernel that is shared with low priority tasks?  Do you prefer the RTAI
> approach?

If you want hard real-time, either that, or just make sure you don't get 
locks that might be slow (for one reason or another). Finer granularities 
help there.

For example, to make things really concrete, please just name a semaphore 
that is relevant to a real-time task and that isn't fine enough grain that 
a careful and controlled environment can't avoid it being a bottle-neck 
for a real-time task.

The real problems often end up happening in things like memory management, 
and waiting for IO, where it's not about the locking at all, it's about 
event scheduling. And you just have to avoid those (through pre-allocation 
and buffering) in those kinds of real-time situations.

I really can't think of any blocking kernel lock where priority 
inheritance would make _any_ sense at all. Please give me an example. 

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  7:10                               ` David S. Miller
@ 2005-12-17  7:40                                 ` Linus Torvalds
  2005-12-17 17:22                                   ` Jesse Barnes
  2005-12-17 17:19                                 ` Jesse Barnes
  1 sibling, 1 reply; 249+ messages in thread
From: Linus Torvalds @ 2005-12-17  7:40 UTC (permalink / raw)
  To: David S. Miller
  Cc: jbarnes, dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch,
	matthew, linux-kernel, linux-arch



On Fri, 16 Dec 2005, David S. Miller wrote:
> 
> If there is some test guarding the CAS, yes.
> 
> But if there isn't, for things like atomic increment and
> decrement, where the CAS is unconditional, you'll always
> eat the two bus transactions without the prefetch for write.

Side note: there may be hardware cache protocol _scheduling_ reasons why 
some particular hw platform might prefer to go through the "Shared" state 
in their cache protocol.

For example, you might have hardware that otherwise ends up being very 
unfair, where the two-stage lock aquire might actually allow another node 
to come in at all. Fairness and balance often comes at a cost, both in hw 
and in sw.

Arguably such hardware sounds pretty broken, but the point is that these 
things can certainly depend on the platform around the CPU as well as on 
what the CPU itself does.

I'm not saying that that is necessarily what Jesse was arguing about, but 
lock contention behaviour can be "interesting".

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 13:01                     ` Nick Piggin
  2005-12-16 13:21                       ` Russell King
@ 2005-12-17 15:57                       ` Nikita Danilov
  1 sibling, 0 replies; 249+ messages in thread
From: Nikita Danilov @ 2005-12-17 15:57 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Arjan van de Ven, Andrew Morton, Alan Cox, cfriesen, torvalds,
	hch, matthew, linux-kernel, linux-arch

Nick Piggin writes:
 > David Howells wrote:
 > > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
 > > 
 > > 
 > >>> (2) Those that have CMPXCHG or equivalent: 68020, i486+, x86_64, ia64,
 > >>>sparc.
 > >>> (3) Those that have LL/SC or equivalent: mips (some), alpha, powerpc, arm6.
 > >>>
 > >>
 > >>cmpxchg is basically exactly equivalent to a store-conditional, so 2 and 3
 > >>are the same level.
 > > 
 > > 
 > > No, they're not. LL/SC is more flexible than CMPXCHG because under some
 > > circumstances, you can get away without doing the SC, and because sometimes
 > > you can do one LL/SC in lieu of two CMPXCHG's because LL/SC allows you to
 > > retrieve the value, consider it and then modify it if you want to. With
 > > CMPXCHG you have to anticipate, and so you're more likely to get it wrong.
 > > 
 > 
 > I don't think that is more flexible, just different. For example with
 > cmpxchg you may not have to do the explicit load if you anticipate an
 > unlocked mutex as the fastpath.
 > 
 > My point is that they are of semantically equal strength.

In the context of implementing mutex they most likely are. But not
generally: LL/SC fails when _any_ write was made into monitored
location, whereas CAS fails only when value stored in that location
changes. As a result, CAS has to deal with "ABA problem" when value
(e.g., first element in a queue) is changed from A to B (head of the
queue is removed) and then back to A (old head is inserted back).

Nikita.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  7:10                               ` David S. Miller
  2005-12-17  7:40                                 ` Linus Torvalds
@ 2005-12-17 17:19                                 ` Jesse Barnes
  1 sibling, 0 replies; 249+ messages in thread
From: Jesse Barnes @ 2005-12-17 17:19 UTC (permalink / raw)
  To: David S. Miller
  Cc: torvalds, dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch,
	matthew, linux-kernel, linux-arch

On Friday, December 16, 2005 11:10 pm, David S. Miller wrote:
> From: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date: Fri, 16 Dec 2005 16:41:49 -0800
>
> > Note that under contention prefetching with a write bias can cause
> > a lot more cache line bouncing than a regular load into shared
> > state (assuming you do a load and test before you try the CAS).
>
> If there is some test guarding the CAS, yes.

Yeah, I was only referring to that particular case (the ia64 code does 
test then CAS, so removing the write bias on the load avoided a lot of 
thrashing for locks under contention).

> But if there isn't, for things like atomic increment and
> decrement, where the CAS is unconditional, you'll always
> eat the two bus transactions without the prefetch for write.

Right, in that case, biasing for read might make sense, as long as some 
other CPU doesn't cause the line to go back to shared before you 
actually get to the CAS.

Jesse

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  7:40                                 ` Linus Torvalds
@ 2005-12-17 17:22                                   ` Jesse Barnes
  0 siblings, 0 replies; 249+ messages in thread
From: Jesse Barnes @ 2005-12-17 17:22 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David S. Miller, dhowells, nickpiggin, arjan, akpm, alan,
	cfriesen, hch, matthew, linux-kernel, linux-arch

On Friday, December 16, 2005 11:40 pm, Linus Torvalds wrote:
> Side note: there may be hardware cache protocol _scheduling_ reasons
> why some particular hw platform might prefer to go through the
> "Shared" state in their cache protocol.
>
> For example, you might have hardware that otherwise ends up being
> very unfair, where the two-stage lock aquire might actually allow
> another node to come in at all. Fairness and balance often comes at a
> cost, both in hw and in sw.
>
> Arguably such hardware sounds pretty broken, but the point is that
> these things can certainly depend on the platform around the CPU as
> well as on what the CPU itself does.
>
> I'm not saying that that is necessarily what Jesse was arguing about,
> but lock contention behaviour can be "interesting".

Yeah, that's a good point.  Getting lock behavior 'just right' can get 
pretty platform specific.  For instance, on a CMP type machine, 
bouncing a lock between CPUs can be nearly free, whereas on a large 
directory based machine like the Altix, pretty much any cache line 
write (or fake write like ia64's ld.bias) is an expensive operation 
since it involves lots of relatively slow network activity.

Jesse

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 22:53                           ` David S. Miller
  2005-12-17  0:41                             ` Jesse Barnes
@ 2005-12-17 22:38                             ` Richard Henderson
  2005-12-17 23:05                               ` David S. Miller
  1 sibling, 1 reply; 249+ messages in thread
From: Richard Henderson @ 2005-12-17 22:38 UTC (permalink / raw)
  To: David S. Miller
  Cc: torvalds, dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch,
	matthew, linux-kernel, linux-arch

On Fri, Dec 16, 2005 at 02:53:06PM -0800, David S. Miller wrote:
> I'll have to add "put write prefetch in CAS sequences" onto my sparc64
> TODO list :-)

You might consider just beginning your loops like

	mov	zero, old
	cas	[mem], zero, old

to do the initial read, since old will now contain the 
contents of the memory, and we havn't changed the memory.


r~

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17 22:38                             ` Richard Henderson
@ 2005-12-17 23:05                               ` David S. Miller
  0 siblings, 0 replies; 249+ messages in thread
From: David S. Miller @ 2005-12-17 23:05 UTC (permalink / raw)
  To: rth
  Cc: torvalds, dhowells, nickpiggin, arjan, akpm, alan, cfriesen, hch,
	matthew, linux-kernel, linux-arch

From: Richard Henderson <rth@twiddle.net>
Date: Sat, 17 Dec 2005 14:38:24 -0800

> You might consider just beginning your loops like
> 
> 	mov	zero, old
> 	cas	[mem], zero, old
> 
> to do the initial read, since old will now contain the 
> contents of the memory, and we havn't changed the memory.

CAS is 32 cycles minimum on sparc64 even on a cache hit, so I think
the prefetch+load will be faster :-)  But it deserves checking out,
that's for sure.

Either way, that is a clever use of CAS :)

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  7:34                                                         ` Linus Torvalds
@ 2005-12-17 23:43                                                           ` Matthew Wilcox
  2005-12-18  0:05                                                             ` Lee Revell
  2005-12-22 12:27                                                             ` Bill Huey
  2005-12-19 16:08                                                           ` Ingo Molnar
  2005-12-22 12:40                                                           ` Bill Huey
  2 siblings, 2 replies; 249+ messages in thread
From: Matthew Wilcox @ 2005-12-17 23:43 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Joe Korty, Thomas Gleixner, Geert Uytterhoeven,
	Andrew Morton, linux-arch, Linux Kernel Development, arjan,
	Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells

On Fri, Dec 16, 2005 at 11:34:03PM -0800, Linus Torvalds wrote:
> I really can't think of any blocking kernel lock where priority 
> inheritance would make _any_ sense at all. Please give me an example. 

I have a better example of something we currently get wrong that I
haven't heard any RT person worry about yet.  If two tasks are sleeping
on the same semaphore, the one to be woken up will be the first one to
wait for it, not the highest-priority task.

Obviously, this was introduced by the wake-one semantics.  But how to
fix it?  Should we scan the entire queue looking for the best task to
wake?  Should we try to maintain the wait list in priority order?  Or
should we just not care?  Should we document that we don't care?  ;-)

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17 23:43                                                           ` Matthew Wilcox
@ 2005-12-18  0:05                                                             ` Lee Revell
  2005-12-18  0:21                                                               ` Matthew Wilcox
  2005-12-22 12:27                                                             ` Bill Huey
  1 sibling, 1 reply; 249+ messages in thread
From: Lee Revell @ 2005-12-18  0:05 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Linus Torvalds, Steven Rostedt, Joe Korty, Thomas Gleixner,
	Geert Uytterhoeven, Andrew Morton, linux-arch,
	Linux Kernel Development, arjan, Christoph Hellwig, mingo,
	Alan Cox, nikita, pj, dhowells

On Sat, 2005-12-17 at 16:43 -0700, Matthew Wilcox wrote:
> On Fri, Dec 16, 2005 at 11:34:03PM -0800, Linus Torvalds wrote:
> > I really can't think of any blocking kernel lock where priority 
> > inheritance would make _any_ sense at all. Please give me an example. 
> 
> I have a better example of something we currently get wrong that I
> haven't heard any RT person worry about yet.  If two tasks are sleeping
> on the same semaphore, the one to be woken up will be the first one to
> wait for it, not the highest-priority task.
> 
> Obviously, this was introduced by the wake-one semantics.  But how to
> fix it?  Should we scan the entire queue looking for the best task to
> wake?  Should we try to maintain the wait list in priority order?  Or
> should we just not care?  Should we document that we don't care?  ;-)

It's well known that this is a problem:

http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/fusyn/fusyn-why.txt

Lee


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-18  0:05                                                             ` Lee Revell
@ 2005-12-18  0:21                                                               ` Matthew Wilcox
  2005-12-18  1:25                                                                 ` Lee Revell
  0 siblings, 1 reply; 249+ messages in thread
From: Matthew Wilcox @ 2005-12-18  0:21 UTC (permalink / raw)
  To: Lee Revell
  Cc: Linus Torvalds, Steven Rostedt, Joe Korty, Thomas Gleixner,
	Geert Uytterhoeven, Andrew Morton, linux-arch,
	Linux Kernel Development, arjan, Christoph Hellwig, mingo,
	Alan Cox, nikita, pj, dhowells

On Sat, Dec 17, 2005 at 07:05:21PM -0500, Lee Revell wrote:
> On Sat, 2005-12-17 at 16:43 -0700, Matthew Wilcox wrote:
> > I have a better example of something we currently get wrong that I
> > haven't heard any RT person worry about yet.  If two tasks are sleeping
> > on the same semaphore, the one to be woken up will be the first one to
> > wait for it, not the highest-priority task.
> > 
> > Obviously, this was introduced by the wake-one semantics.  But how to
> > fix it?  Should we scan the entire queue looking for the best task to
> > wake?  Should we try to maintain the wait list in priority order?  Or
> > should we just not care?  Should we document that we don't care?  ;-)
> 
> It's well known that this is a problem:
> 
> http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/fusyn/fusyn-why.txt

Erm.  That paper is talking about user-space semaphores based on futexes.
I'm talking about kernel semaphores.  At a first glance, fixing futexes
would be a very different job from fixing semaphores.

BTW, fuqueues?  HAHAHAHA.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-18  0:21                                                               ` Matthew Wilcox
@ 2005-12-18  1:25                                                                 ` Lee Revell
  0 siblings, 0 replies; 249+ messages in thread
From: Lee Revell @ 2005-12-18  1:25 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Linus Torvalds, Steven Rostedt, Joe Korty, Thomas Gleixner,
	Geert Uytterhoeven, Andrew Morton, linux-arch,
	Linux Kernel Development, arjan, Christoph Hellwig, mingo,
	Alan Cox, nikita, pj, dhowells

On Sat, 2005-12-17 at 17:21 -0700, Matthew Wilcox wrote:
> On Sat, Dec 17, 2005 at 07:05:21PM -0500, Lee Revell wrote:
> > On Sat, 2005-12-17 at 16:43 -0700, Matthew Wilcox wrote:
> > > I have a better example of something we currently get wrong that I
> > > haven't heard any RT person worry about yet.  If two tasks are sleeping
> > > on the same semaphore, the one to be woken up will be the first one to
> > > wait for it, not the highest-priority task.
> > > 
> > > Obviously, this was introduced by the wake-one semantics.  But how to
> > > fix it?  Should we scan the entire queue looking for the best task to
> > > wake?  Should we try to maintain the wait list in priority order?  Or
> > > should we just not care?  Should we document that we don't care?  ;-)
> > 
> > It's well known that this is a problem:
> > 
> > http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/fusyn/fusyn-why.txt
> 
> Erm.  That paper is talking about user-space semaphores based on futexes.
> I'm talking about kernel semaphores.  At a first glance, fixing futexes
> would be a very different job from fixing semaphores.
> 
> BTW, fuqueues?  HAHAHAHA.
> 

Hmm, interesting, so in fact the scheduler does not always run the
highest priority runnable process?  Do you have a test case where
userspace would experience priority inversion due to this?

Maybe it has not been a problem as all the PI cases would involve two RT
processes that make system calls which end up blocking on a semaphore in
the kernel, which is bad RT design anyway - normally you would separate
the RT parts of the app which carefully avoid possibly blocking system
calls from the non RT parts and communicate via lock free ringbuffers or
a similar mechanism.

Lee


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  7:34                                                         ` Linus Torvalds
  2005-12-17 23:43                                                           ` Matthew Wilcox
@ 2005-12-19 16:08                                                           ` Ingo Molnar
  2005-12-22 12:40                                                           ` Bill Huey
  2 siblings, 0 replies; 249+ messages in thread
From: Ingo Molnar @ 2005-12-19 16:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Joe Korty, Thomas Gleixner, Geert Uytterhoeven,
	Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, Alan Cox, nikita, pj, dhowells


* Linus Torvalds <torvalds@osdl.org> wrote:

> I really can't think of any blocking kernel lock where priority 
> inheritance would make _any_ sense at all. Please give me an example.

you are completely right, most of the blocking kernel locks we have in 
Linux are an extremely poor candidate for priority inheritance. Most of 
them are totally noncritical, or cover so long codepaths that 'latency 
guarantees' and 'priority inheritance' make little sense for them.

the reason why we still have transformed most of the stock semaphore 
users to generic mutexes in the -rt kernel is mostly because i wanted to 
have _one_ central lock implementation. Firstly, it makes alot of sense 
to consolidate code on embedded platforms anyway. Secondly, it was much 
easier to implement (and validate) one robust locking primitive, than to 
implement 5 separate primitives. The fact that this also made semaphores 
PI-able is just a side-effect, with little to no practical relevance.

maybe ->i_sem is one notable exception: it is often held in critical 
codepaths, and it's really hard for even the most-well-controlled RT app 
to achieve _total_ isolation from the 'unprivileged' filesystem space.  
So occasional 'resource sharing' in form of hitting an i_sem of another 
task may still occur, and PI can at least reduce the worst-case cost 
somehow. (even though i_sem codepaths are by no means deterministic!)

so in the -rt kernel, every semaphore, rw-semaphore, spinlock, rwlock 
and seqlock [and in the latest -rt patches, every futex too] is 
abstracted off a central generic mutex type, which mutex is blocking and 
supports priority queueing and priority inheritance. It also has an 
extensive debugging framework, which we didnt want to duplicate for 
every separate lock object.

we also have a facility in the -rt kernel that traces the worst-case 
latency path of critical applications (the 'latency tracer'), when mixed 
with non-critical workloads, so we have quite good experience about what 
kind of locks make a difference and what kind of locks make no 
difference.

we also definitely know that priority inheritance done over _all_ these 
lock objects makes a very real quality difference in practice, resulting 
in real-time apps experiencing much lower worst-case latencies than 
under the stock kernel. It is true that you could live without priority 
inheritance, in cases were the RT app can be rewritten to have totally 
separated resources, but in practice that is only possible for the 
simplest applications.

	Ingo

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  1:00                                                     ` Linus Torvalds
  2005-12-17  3:13                                                       ` Steven Rostedt
@ 2005-12-19 23:46                                                       ` Keith Owens
  1 sibling, 0 replies; 249+ messages in thread
From: Keith Owens @ 2005-12-19 23:46 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Joe Korty, Thomas Gleixner, Geert Uytterhoeven, Steven Rostedt,
	Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells

On Fri, 16 Dec 2005 17:00:09 -0800 (PST),
Linus Torvalds <torvalds@osdl.org> wrote:
>The Mars Pathfinder is just about the worst case "real system", and if I
>recall correctly, the reason it was able to continue was _not_ because it
>handled priority inversion, but because it reset itself every 24 hours or
>something like that, and had debugging facilities..
>...
>So put a watchdog on your critical systems, and make sure you can debug
>them. Especially if they're on Mars.

Who are you and what have you done with the real[1]

  Linus "I'm a sick and twisted person, and I trust people who write code
  without debuggers a lot more than I trust those who don't" Torvalds :-)

[1] http://www.ussg.iu.edu/hypermail/linux/kernel/9510/0103.html


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17 23:43                                                           ` Matthew Wilcox
  2005-12-18  0:05                                                             ` Lee Revell
@ 2005-12-22 12:27                                                             ` Bill Huey
  1 sibling, 0 replies; 249+ messages in thread
From: Bill Huey @ 2005-12-22 12:27 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Linus Torvalds, Steven Rostedt, Joe Korty, Thomas Gleixner,
	Geert Uytterhoeven, Andrew Morton, linux-arch,
	Linux Kernel Development, arjan, Christoph Hellwig, mingo,
	Alan Cox, nikita, pj, dhowells

On Sat, Dec 17, 2005 at 04:43:05PM -0700, Matthew Wilcox wrote:
> I have a better example of something we currently get wrong that I
> haven't heard any RT person worry about yet.  If two tasks are sleeping
> on the same semaphore, the one to be woken up will be the first one to
> wait for it, not the highest-priority task.
> 
> Obviously, this was introduced by the wake-one semantics.  But how to
> fix it?  Should we scan the entire queue looking for the best task to
> wake?  Should we try to maintain the wait list in priority order?  Or
> should we just not care?  Should we document that we don't care?  ;-)

-rt deals with this using priority sorted wait queue and direct ownership
hand off to the woken thread. It's working fine for now, but things like
wake-all and company should probably be explored for various uses. A
strict general purpose and RT usage of the Linux kernel have different
performance characteristic and mutex selection at compile time should
address things precisely.

bill


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17  7:34                                                         ` Linus Torvalds
  2005-12-17 23:43                                                           ` Matthew Wilcox
  2005-12-19 16:08                                                           ` Ingo Molnar
@ 2005-12-22 12:40                                                           ` Bill Huey
  2005-12-22 12:45                                                             ` Bill Huey
  2 siblings, 1 reply; 249+ messages in thread
From: Bill Huey @ 2005-12-22 12:40 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Joe Korty, Thomas Gleixner, Geert Uytterhoeven,
	Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells

On Fri, Dec 16, 2005 at 11:34:03PM -0800, Linus Torvalds wrote:
> For example, to make things really concrete, please just name a semaphore 
> that is relevant to a real-time task and that isn't fine enough grain that 
> a careful and controlled environment can't avoid it being a bottle-neck 
> for a real-time task.

Problem here is ownership tracking with a semaphore is an extremely difficult
problem to solve without serializing the entire thing with a single spinlock.
You lose parallelism here and possible create other problems since the
contention window is larger surround critical sections using it.

> The real problems often end up happening in things like memory management, 
> and waiting for IO, where it's not about the locking at all, it's about 
> event scheduling. And you just have to avoid those (through pre-allocation 
> and buffering) in those kinds of real-time situations.
> 
> I really can't think of any blocking kernel lock where priority 
> inheritance would make _any_ sense at all. Please give me an example. 

The current kernel mostly using traditional spinlocks doesn't have locking
complicated enough to warrant it. However, the -rt patch does create a
circumstance where a fully preemptible may sleep task with mutexes held create
and needs resolve priority inversions that results from it. That's of
course assuming that priority is something that needs to be strictly
obeyed in this variant of the kernel with consideration to priority
inheritance.

bill


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-22 12:40                                                           ` Bill Huey
@ 2005-12-22 12:45                                                             ` Bill Huey
  0 siblings, 0 replies; 249+ messages in thread
From: Bill Huey @ 2005-12-22 12:45 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Joe Korty, Thomas Gleixner, Geert Uytterhoeven,
	Andrew Morton, linux-arch, Linux Kernel Development, matthew,
	arjan, Christoph Hellwig, mingo, Alan Cox, nikita, pj, dhowells

On Thu, Dec 22, 2005 at 04:40:27AM -0800, Bill Huey wrote:
> The current kernel mostly using traditional spinlocks doesn't have locking
> complicated enough to warrant it. However, the -rt patch does create[s] a
> circumstance where a fully preemptible [kernel] may sleep task with mutexes held create[ing]
> [-and needs] [a need to] resolve priority inversions that results from it. That's of

With corrections...

Sorry, I meant a fully preemptive kernel has priority inversion as an
inheritant property and needs to resolved using some kind of priority
inheritance.

> course assuming that priority is something that needs to be strictly
> obeyed in this variant of the kernel with consideration to priority
> inheritance.

bill


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17 10:59       ` Sander
  2005-12-17 14:14         ` Douglas McNaught
@ 2005-12-19 10:44         ` Erik Mouw
  1 sibling, 0 replies; 249+ messages in thread
From: Erik Mouw @ 2005-12-19 10:44 UTC (permalink / raw)
  To: Sander; +Cc: Linus Torvalds, linux, linux-kernel

On Sat, Dec 17, 2005 at 11:59:14AM +0100, Sander wrote:
> Erik Mouw wrote (ao):
> > Last night I've been browsing a little more through Dijkstra's papers,
> > and in a completely unrelated paper[1] about a now obsolete computer I
> > found that "prolaag" is a neologism coming from "probeer te verlagen",
> > which means "try and decrease".
> 
> "probeer te verlagen" translates to "try to decrease".
> 
> "try and decrease" would be "probeer en verlaag".

I know, but that's how Dijkstra translates it. I guess he knew what he
meant.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17 14:14         ` Douglas McNaught
@ 2005-12-17 15:09           ` Sander
  0 siblings, 0 replies; 249+ messages in thread
From: Sander @ 2005-12-17 15:09 UTC (permalink / raw)
  To: Douglas McNaught; +Cc: sander, Erik Mouw, Linus Torvalds, linux, linux-kernel

Douglas McNaught wrote (ao):
> Sander <sander@humilis.net> writes:
> > Erik Mouw wrote (ao):
> >> Last night I've been browsing a little more through Dijkstra's papers,
> >> and in a completely unrelated paper[1] about a now obsolete computer I
> >> found that "prolaag" is a neologism coming from "probeer te verlagen",
> >> which means "try and decrease".
> >
> > "probeer te verlagen" translates to "try to decrease".
> >
> > "try and decrease" would be "probeer en verlaag".
> 
> Just in case you don't know, "try and" in English is an informal
> equivalent of "try to".  I agree your translation is probably better.  :)

I didn't, so thanks for the education :-)

I read it as two things (try something, and decrease), but I see what is
meant now. And I'm sure Erik Mouw knows his was around in both Dutch and
English :-)

-- 
Humilis IT Services and Solutions
http://www.humilis.net

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-17 10:59       ` Sander
@ 2005-12-17 14:14         ` Douglas McNaught
  2005-12-17 15:09           ` Sander
  2005-12-19 10:44         ` Erik Mouw
  1 sibling, 1 reply; 249+ messages in thread
From: Douglas McNaught @ 2005-12-17 14:14 UTC (permalink / raw)
  To: sander; +Cc: Erik Mouw, Linus Torvalds, linux, linux-kernel

Sander <sander@humilis.net> writes:

> Erik Mouw wrote (ao):

>> Last night I've been browsing a little more through Dijkstra's papers,
>> and in a completely unrelated paper[1] about a now obsolete computer I
>> found that "prolaag" is a neologism coming from "probeer te verlagen",
>> which means "try and decrease".
>
> "probeer te verlagen" translates to "try to decrease".
>
> "try and decrease" would be "probeer en verlaag".

Just in case you don't know, "try and" in English is an informal
equivalent of "try to".  I agree your translation is probably better.  :)

-Doug

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 12:17     ` Erik Mouw
@ 2005-12-17 10:59       ` Sander
  2005-12-17 14:14         ` Douglas McNaught
  2005-12-19 10:44         ` Erik Mouw
  0 siblings, 2 replies; 249+ messages in thread
From: Sander @ 2005-12-17 10:59 UTC (permalink / raw)
  To: Erik Mouw; +Cc: Linus Torvalds, linux, linux-kernel

Erik Mouw wrote (ao):
> On Thu, Dec 15, 2005 at 05:52:55PM +0100, Erik Mouw wrote:
> > Just FYI, according to Dijkstra[1] V means "verhoog" which is dutch for
> > "increase". P means "prolaag" which isn't a dutch word, just something
> > Dijkstra invented. I guess he did that because "decrease" is "verlaag"
> > in dutch and that would give you the confusing V() and V()
> > operations...
> 
> Last night I've been browsing a little more through Dijkstra's papers,
> and in a completely unrelated paper[1] about a now obsolete computer I
> found that "prolaag" is a neologism coming from "probeer te verlagen",
> which means "try and decrease".

"probeer te verlagen" translates to "try to decrease".

"try and decrease" would be "probeer en verlaag".

-- 
Humilis IT Services and Solutions
http://www.humilis.net

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 15:24 ` David Howells
@ 2005-12-16 18:03   ` linux
  0 siblings, 0 replies; 249+ messages in thread
From: linux @ 2005-12-16 18:03 UTC (permalink / raw)
  To: dhowells; +Cc: linux, linux-kernel

> Which would be totally pointless.
> 
> If you have LL/SC, then the odds are you _don't_ have CMPXCHG, and that
> CMPXCHG is implemented using LL/SC, so what you end up with is:

Ah, you're not quite understanding what I wrote, but I see the confusion.

I took "turned into" to mean "ported to an architecture with the
other primitive", and intended it that when I said "turned back".
That's obviously pointless if you're emulating one with the other.

The point I was making is that, for any LL/SC sequence, there is an
exactly analagous LD/CMPXCHG version, so you never have to have more
CMPXCHGs than SCs.

This was an attempt to disprove your claim that LL/SC was better by more
than a very small factor.

It it possible to optimize for the contention-free case and do away
with the initial load, at the expense of an additional CMPXCHG in the
failure case.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-16 12:49 linux
@ 2005-12-16 15:24 ` David Howells
  2005-12-16 18:03   ` linux
  0 siblings, 1 reply; 249+ messages in thread
From: David Howells @ 2005-12-16 15:24 UTC (permalink / raw)
  To: linux; +Cc: dhowells, linux-kernel

linux@horizon.com wrote:

> > Can be turned into:
> > 
> > 	1,C,A	x = LL()
> > 	1,C,A	x |= 2;
> > 	1,C,A	SC(3) [success]
> > 	3,C,A	...
> 
> ... which can be turned back into
> 
>  	1,C,A	x = load()
>  	1,C,A	x' = x | 2;
>  	1,C,A	cmpxchg(x,x') [success]
>  	3,C,A	...

Which would be totally pointless.

If you have LL/SC, then the odds are you _don't_ have CMPXCHG, and that
CMPXCHG is implemented using LL/SC, so what you end up with is:


 	1,C,A	x = load()
 	1,C,A	x' = x | 2;
	1,C,A	y = LL()
	1,C,A	if (y == x)
	1,X,A		SC(x');
 	3,C,A	...

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
@ 2005-12-16 12:49 linux
  2005-12-16 15:24 ` David Howells
  0 siblings, 1 reply; 249+ messages in thread
From: linux @ 2005-12-16 12:49 UTC (permalink / raw)
  To: dhowells; +Cc: linux, linux-kernel

> Now my point about using LL/SC is that:
> 
> 	1,C,A	cmpxchg(0,1) [failed]
> 	1,C,A	cmpxchg(1,3) [success]
> 	3,C,A	...
> 
> Can be turned into:
> 
> 	1,C,A	x = LL()
> 	1,C,A	x |= 2;
> 	1,C,A	SC(3) [success]
> 	3,C,A	...

... which can be turned back into

 	1,C,A	x = load()
 	1,C,A	x' = x | 2;
 	1,C,A	cmpxchg(x,x') [success]
 	3,C,A	...

which will fail and retry in exactly the same contention cases as the
LL/SC.  The only thing that LL gives you that's nice is a hint that
an SC is due very soon and so resisting a cache eviction for a couple
of cycles might be a good idea.

The reason that we tend to do the former is optimism that the lock
won't be held.  If that's a bad assumption, make it more pessimistic.

LL/SC can detect double changes during the critical section, but it's
very similar in expressive power to load + CMPXCHG.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:52   ` Erik Mouw
  2005-12-15 17:23     ` Dick Streefland
@ 2005-12-16 12:17     ` Erik Mouw
  2005-12-17 10:59       ` Sander
  1 sibling, 1 reply; 249+ messages in thread
From: Erik Mouw @ 2005-12-16 12:17 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux, linux-kernel

On Thu, Dec 15, 2005 at 05:52:55PM +0100, Erik Mouw wrote:
> Just FYI, according to Dijkstra[1] V means "verhoog" which is dutch for
> "increase". P means "prolaag" which isn't a dutch word, just something
> Dijkstra invented. I guess he did that because "decrease" is "verlaag"
> in dutch and that would give you the confusing V() and V()
> operations...

Last night I've been browsing a little more through Dijkstra's papers,
and in a completely unrelated paper[1] about a now obsolete computer I
found that "prolaag" is a neologism coming from "probeer te verlagen",
which means "try and decrease".


Erik

[1] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD00xx/EWD51.html

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:52     ` Linus Torvalds
@ 2005-12-16  1:33       ` linux
  0 siblings, 0 replies; 249+ messages in thread
From: linux @ 2005-12-16  1:33 UTC (permalink / raw)
  To: linux, torvalds; +Cc: linux-kernel

> Ahh, I thought you were considering naming unhappiness to be a reason
> _for_ the mutex change.

Good gods, no.  The best mnemonics for P() and V() I've ever seen
were in the Amiga which called them Procure() and Vacate(), but the
names still suck mightily.

> Double aquires certainly occasionally happen, but they are (assuming it's 
> a real double aquire, and not a race due to lock ordering) easy to see, 
> since it just hangs the process and you get a traceback and find it.

Ah, now we get to the valid point.

> But mutexes don't help either. A mutex will hang exactly the same way, 
> with exactly the same behaviour, and aren't any easier to debug (as 
> mentioned, a hung semaphore isn't exactly hard to debug).

Well, a mutex can detect it immediately, rather than via a timeout,
but that's a matter of a few seconds, and the vast majority of the
evidence you want is frozen by the deadlock itself.

> So yes, recursive mutexes can be easier to use, but they really do allow 
> (and thus indirectly encourage) bad locking. So I'm not convinced we want 
> one.

Agreed.  Maybe someone will someday find an application where there's
really no way around it, but avoiding the need is generally better
design.

>> But all of this requires that a lock have an identifiable owner, which
>> is something hat a mutex has and a semaphore fundamentally doesn't.

> Actually, we've certainly had semaphore debugging patches which consider 
> the last person who successfully got a semaphore to be the "owner".
> 
> Sure, it's not well-defined for the generic semaphore case, but so what? 

An excellent point.  As long as it's only used for post-mortem debugging,
and not to verify invariants at run-time, you can keep track of
"who would be the woner if this were a mutex".

>> I don't care what it's *called*.  I care that we have stronger
>> conditions that we can test for correctness.

> Hey, if so, please don't encourage the current patch. 
>
> We can certainly add a new locking mechanism, I'm just not at all 
> convinced that it's warranted. I certainly disagree with you that using 
> semaphores would somehow be less easy to test for correctness.

Let's go through what you lose if you give up a known lock owner and
just use something probabilistic....

Detecting deadlocks - can be done immediately and definitively with
a lock owner, and only via timeouts without.  Still, not a deal-breaker.

Multi-lock deadlocks - same, although the detection code is
more complex so probably shouldn't be enabled all the time.

Double-release: can be instantly detected with a known mutex, but will
produce really odd misbehaviour with a semaphore.  Still, you're quite
right that failing to release on a failure path is by far the more
common bug.

Priority inheritance.  This is the original reason that the -rt patch
implemented mutexes, and requires accurate lock owner information.
Not having it is a show-stopper here.

Source documentation.  This is more a style thing, but I really
like putting as much information into the source as possible.
(If comments worked, we wouldn't need sparse.)  

So the latter two are the only really good reasons.  Still, I think
they're persuasive.

Can anyone think of any other benefits?

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 20:38 ` Jeff Dike
@ 2005-12-15 23:45   ` Stephen Rothwell
  0 siblings, 0 replies; 249+ messages in thread
From: Stephen Rothwell @ 2005-12-15 23:45 UTC (permalink / raw)
  To: Jeff Dike
  Cc: tony.luck, dhowells, akpm, lkml, tglx, alan, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Thu, 15 Dec 2005 15:38:18 -0500 Jeff Dike <jdike@addtoit.com> wrote:
>
> On Thu, Dec 15, 2005 at 09:45:10AM -0800, Luck, Tony wrote:
> > There was a USENIX paper a couple of decades ago that described how
> > to do a fast s/w disable of interrupts on machines where really disabling
> > interrupts was expensive.  The rough gist was that the spl[1-7]()
> > functions would just set a flag in memory to hold the desired interrupt
> > mask.  If an interrupt actually occurred when it was s/w blocked, the
> > handler would set a pending flag, and just rfi with interrupts disabled.
> > Then the splx() code checked to see whether there was a pending interrupt
> > and dealt with it if there was.
> 
> ... and this is currently implemented (but not yet merged to mainline) in
> UML.

And, of course, this is the way the PowerPC iSeries has always worked because
we are not allowed to disable hardware interrupts for long periods of time or
the hypervisor will consider that our logical partition is dead.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:09   ` linux
  2005-12-15 19:52     ` Linus Torvalds
@ 2005-12-15 21:18     ` Steven Rostedt
  1 sibling, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 21:18 UTC (permalink / raw)
  To: linux; +Cc: linux-kernel, torvalds

On Thu, 2005-12-15 at 14:09 -0500, linux@horizon.com wrote:
> >
> 
> As I said, as long as the -rt patch was not in the main tree, taking
> advantage of the fact that 95% of the down() and up() callers just want
> a mutex was a sensible implementation tradeoff.  For merging it into the
> tree, it's ugly, and people don't like that.  The -rt folks have gotten
> used to their naming perversions and so don't feel as much repugnance.
> 

The naming in the -rt side is to try to keep things as much in parallel
to the mainline as possible.  I don't think Ingo would have a problem
with up / down just being used for semaphores, and having true mutex
names for just that.  In fact that would help us a lot.  A lot of bugs
fixes that I send to Ingo, is finding places that use mutex when they
are really counting semaphores, and thus cant have PI.

>

...

> 
> > So when you say "This isn't about speed, this is about bug-free code", 
> > you're just making that up.
> >
> > It's doubly silly when your "safer" 
> > implementation uses totally illogical names. THAT is what creates bugs.
> 
> If you want to argue about names, go discuss gay marriage.

Are you suggesting a "mutex union"?

> 
> I don't care what it's *called*.  I care that we have stronger
> conditions that we can test for correctness.

Well a name is helpful in understanding what's going on.  Especially if
we want new up and coming kernel programmers to help out.  Instead of
staying with what is there now.

Also, while we're at it, lets fix that damn down_trylock (or
mutex_trylock) to return 1 on success, 0 on contention, just like the
spin_trylock does!!!

Actually, that alone is a good argument to not keep the same names.  We
can keep down_trylock as the same perverted self, and have mutex_trylock
do it right.  Of course, special care is needed when doing this
conversion, but a wrong pick should show itself right away.

> 
> > So go away.
> > 
> > Come back if you have pondered, and accepted reality, and perhaps have an 
> > acceptable patch that introduces a separate data structure. 
> 
> Ha!  I still say you're wrong, and I'm not going to fold over an obvious
> technical point just because of flaming.
> 
> Are we having some communication problems?  I find it hard to believe
> that you're actually this *stupid*, but we might not be talking about
> the same thing.
> 
> I took your posting to say that
> 
> a) Using the names "struct semaphore", "up()" and "down()" for a mutex
>    is monumentally brain-dead.  I'm not arguing, although I understand
>    the pragmatic reasons for the original abuse of notation.
> 
> b) There is no need for a mutex implementation, because a semaphore can
>    do anything that a mutex can.  Here, I absolutely disagree.  There
>    are things you can do with a mutex that you CANNOT do with a
>    general semaphore, because a mutex has stronger invariants.
> 
>    A counting semaphore can do MOST of what a mutex does, and is
>    demonstrably close enough for a lot of uses.
> 
> > And no, we're not switching users over whole-sale.  First you introduce the 
> > new concept.  Only THEN can you can switch over INDIVIDUAL LOCKS with 
> > reasons for why it's worth it.
> 
> Given that 95% of callers are using it as mutex, you're making this 20
> times more work than necessary.  Convert 'em all and change the 5%
> that need the counting back.

I disagree with doing that.  Especially since I've argued that a mutex
is a semaphore, but a semaphore is not a mutex.  So I rather go slowly
changing the semaphores that are acting as mutexes, (since those that
are not changed are not broken) than doing the change all mutexes to
semaphores, where a mutex can not always act like a semaphore, and then
go and break those 5%.

In reality, this is what the RT patch did. All semaphores (up / down)
became mutexes, and then we manually found the counting semaphores and
started switching them to compat_semaphores (what semaphore is today).
I'm still sending in patches to fix these.

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:15 ` Linus Torvalds
                     ` (2 preceding siblings ...)
  2005-12-15 19:09   ` linux
@ 2005-12-15 20:52   ` Steven Rostedt
  3 siblings, 0 replies; 249+ messages in thread
From: Steven Rostedt @ 2005-12-15 20:52 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, linux

On Thu, 2005-12-15 at 08:15 -0800, Linus Torvalds wrote:
> 
> On Thu, 15 Dec 2005, linux@horizon.com wrote:
> > 
> > A counting semaphore is NOT a perfectly fine mutex, and it SHOULD be changed.
> 
> Don't be silly.
> 
> First off, the data structure is called a "semaphore", and always has 
> been. It's _never_ been called a "mutex" in the first place, and the 
> operations have been called "down()" and "up()", because I thought calling 
> them P() and V() was just too damn traditional and confusing (I don't 
> speak dutch, and even if I did, I think shortening names to that degree is 
> just evil).

Thank you for the down and up, I always had problems way back when I was
in college.  I could never remember which was which (between P and V).

> And dammit, a counting semaphore (and usually you don't even say the 
> "counting" part, since counting is really always there) is just about 
> _the_ classical mutual exclusion mechanism. If somebody doesn't know that, 
> he has absolutely _no_ place talking about mutexes etc.
> 
> And a semaphore _is_ a mutex. Anybody who disputes that is just being a 
> total troll. Even classically, the case where the semaphore was 
> initialized to 1 is very very traditional, and is very much part of the 
> whole point of a semaphore. Sometimes they are called "binary semaphores", 
> but dammit, they are just the same thing.

<Total Troll> ;)

Uh, I think that a semaphore is _not_ a mutex.  As someone early said,
that a mutex is a semaphore, but not the other way around.  I have used
counting semaphores for resource allocations, not the semaphore=1 kind.
This is not a mutual exclusion, its shared.

Also a semaphore can be declared locked, a mutex cant.

Of course, if you said "binary semaphores" is a mutex, then I would
agree with you.

</Total Troll>


> 
> A patch that
>  - creates a non-counting mutex
>  - .. that is SLOWER than the current counting one
>  - .. and keeps the old "semaphore" and "up/down" naming
> 
> is simply INCREDIBLY BROKEN. It has absolutely _zero_ redeeming features. 
> I can't understand how there are a hundred emails in my mailbox even 
> discussing it. 

ACK

But that was just somebody's (David) first crack at this patch.  But
I've been pushing that he should first submit the mutex, where everyone
else can help make it really fast, and then submit the case by case
places that the semaphores should be replaced with mutex.  That's the
most logical way I see it. And yes, even if that means lots of patches,
but it makes it easier for more than one person to submit that, and
review.

> 
> And I can't understand how somebody has the balls to even say that a 
> semaphore isn't a mutex. That's like saying that an object of type "long" 
> isn't an integer, because only "int" objects are integers. That's just 
> INSANE.

No it's like saying a integer is a long. Wait did someone else say that
already?

> 
> > People are indeed unhappy with the naming, and whether patching 95%
> > of the callers of up() and down() is a good idea is a valid and active
> > subject of debate.  (For an out-of-tree -rt patch, is was certaintly
> > an extremely practical solution.)
> 
> Whatever people you claim are unhappy with the naming are
>  - obviously totally unaware of very basic synchronization primitives
>    used in concurrent programming
>  - likely haven't spent any time at all looking at the kernel source code.
>  - haven't _ever_ complained that I've seen before this totally made-up 
>    discussion.

:( I'm unhappy with calling a mutex down and up. But lets see if I am
any of the above?

1. Being the one to remove the global PI lock in the rt patch, gives me
some credit that I understand basic synchronization primitives used in
concurrent programming.

2. Have been playing with the Linux kernel source since 1998 (just not
publicly until 2003).

3.  OK, you got me there ;)


> 
> In other words, you are
>  (a) totally making up the claim that people are really unhappy
>  (b) jerking people around who _do_ know about semaphores and _have_ 
>      worked with the kernel locking primitives and understand them well

I'm one that would like to see semaphores turn to mutex when they really
are one.  But I'd like to keep up / down for semaphores (as they are
today) and introduce a new mutex api mutex_lock / mutex_unlock, since I
think that is the best way to explain what's going on.

> 
> So tell me, what do you think about your own arguments in that light?
> 
> > But regardless of the eventual naming convention, mutexes are a good idea.
> > A mutex is *safer* than a counting semaphore.  That's the main benefit.
> > Indeed, unless there's a performance advantage to a counting semaphore,
> > you should use a mutex!
> 
> Hey, feel free to introduce a mutex, but DAMMIT, just call it that, 
> instead of switching people over. 

ACK

> 
> And even then, it should damn well also:
>  - really _be_ faster. On platforms that matter. 
>  - have enough real other advantages that it's worth introducing another 
>    abstraction, and more conceptual complexity. At least the RT patches 
>    had a reason for them.

Actually, I would like this change to make it in mainline to help with
the RT patches.

> 
> And besides, all your "safer" arguments are pretty damn pointless in the 
> face of the fact that we have basically had zero bugs with the semaphores. 
> This is not where the bugs happen. Yeah, yeah, double releases can happen, 
> but it sure as hell isn't on my radar of things I remember people doing.
> 
> So when you say "This isn't about speed, this is about bug-free code", 
> you're just making that up. It's doubly silly when your "safer" 
> implementation uses totally illogical names. THAT is what creates bugs.
> 
> So go away.
> 
> Come back if you have pondered, and accepted reality, and perhaps have an 
> acceptable patch that introduces a separate data structure. 
> 
> And no, we're not switching users over whole-sale. First you introduce the 
> new concept. Only THEN can you can switch over INDIVIDUAL LOCKS with 
> reasons for why it's worth it.
> 
> And hell yes, performance does matter.

And so do a lot of other things.

-- Steve



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 17:45 Luck, Tony
  2005-12-15 18:00 ` David Howells
  2005-12-15 18:48 ` James Bottomley
@ 2005-12-15 20:38 ` Jeff Dike
  2005-12-15 23:45   ` Stephen Rothwell
  2 siblings, 1 reply; 249+ messages in thread
From: Jeff Dike @ 2005-12-15 20:38 UTC (permalink / raw)
  To: Luck, Tony
  Cc: dhowells, Andrew Morton, Mark Lord, tglx, alan, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch

On Thu, Dec 15, 2005 at 09:45:10AM -0800, Luck, Tony wrote:
> There was a USENIX paper a couple of decades ago that described how
> to do a fast s/w disable of interrupts on machines where really disabling
> interrupts was expensive.  The rough gist was that the spl[1-7]()
> functions would just set a flag in memory to hold the desired interrupt
> mask.  If an interrupt actually occurred when it was s/w blocked, the
> handler would set a pending flag, and just rfi with interrupts disabled.
> Then the splx() code checked to see whether there was a pending interrupt
> and dealt with it if there was.

... and this is currently implemented (but not yet merged to mainline) in
UML.

				Jeff

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 19:09   ` linux
@ 2005-12-15 19:52     ` Linus Torvalds
  2005-12-16  1:33       ` linux
  2005-12-15 21:18     ` Steven Rostedt
  1 sibling, 1 reply; 249+ messages in thread
From: Linus Torvalds @ 2005-12-15 19:52 UTC (permalink / raw)
  To: linux; +Cc: linux-kernel



On Thu, 15 Dec 2005, linux@horizon.com wrote:
> 
> Huh?  I thought *you* were violently unhappy with the idea of naming
> mutex acquire and release down() and up(), and your e-mail is an example
> of this unhapiness.

Ahh, I thought you were considering naming unhappiness to be a reason
_for_ the mutex change.

down() and up() aren't the traditional names for the operations, P()/V()
are, and I thought you were arguing that some people might dislike the
_current_ naming.

> There haven't been problems with the semaphore *implementation*, but
> people screw up and deadlock themselves often enough.  I sure remember
> double-acquire lockups.  Forgive me if I don't grep the archives, but
> I remember people showing code paths that led to them.

Double aquires certainly occasionally happen, but they are (assuming it's 
a real double aquire, and not a race due to lock ordering) easy to see, 
since it just hangs the process and you get a traceback and find it.

But mutexes don't help either. A mutex will hang exactly the same way, 
with exactly the same behaviour, and aren't any easier to debug (as 
mentioned, a hung semaphore isn't exactly hard to debug).

Or maybe you're talking about a _recursive_ mutex, which is something that 
actually has totally different semantics. We've discussed adding them, but 
pretty much every time it was the result of some really really bad locking 
design, so at least so far we've instead decided to bite the bullet and 
fix the locking.

So yes, recursive mutexes can be easier to use, but they really do allow 
(and thus indirectly encourage) bad locking. So I'm not convinced we want 
one.

> But all of this requires that a lock have an identifiable owner, which
> is something hat a mutex has and a semaphore fundamentally doesn't.

Actually, we've certainly had semaphore debugging patches which consider 
the last person who successfully got a semaphore to be the "owner".

Sure, it's not well-defined for the generic semaphore case, but so what? 
In the generic case, you can't use mutexes anyway. For _debugging_ 
ownership as in "who got this lock last" is still useful. I know I've 
cooked up trivial patches to do that when I was trying to figure out a 
lock ordering bug.

Google is your friend. Just try "semaphore owner debug", and the #2 hit is 
a patch that does exactly that for Linux.

> I don't care what it's *called*.  I care that we have stronger
> conditions that we can test for correctness.

Hey, if so, please don't encourage the current patch. 

We can certainly add a new lockign mechanism, I'm just not at all 
convinced that it's warranted. I certainly disagree with you that using 
semaphores would somehow be less easy to test for correctness.

		Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:15 ` Linus Torvalds
  2005-12-15 16:52   ` Erik Mouw
  2005-12-15 19:02   ` Nikita Danilov
@ 2005-12-15 19:09   ` linux
  2005-12-15 19:52     ` Linus Torvalds
  2005-12-15 21:18     ` Steven Rostedt
  2005-12-15 20:52   ` Steven Rostedt
  3 siblings, 2 replies; 249+ messages in thread
From: linux @ 2005-12-15 19:09 UTC (permalink / raw)
  To: linux, torvalds; +Cc: linux-kernel

> And I can't understand how somebody has the balls to even say that a 
> semaphore isn't a mutex. That's like saying that an object of type "long" 
> isn't an integer, because only "int" objects are integers. That's just 
> INSANE.

I didn't say it isn't a mutex, I said it isn't a GOOD one!

The fundamental reason is that a semaphore doesn't have an owner, and
a mutex does.  And you can do a lot when you know who owns the lock.

>> People are indeed unhappy with the naming, and whether patching 95%
>> of the callers of up() and down() is a good idea is a valid and active
>> subject of debate.  (For an out-of-tree -rt patch, is was certaintly
>> an extremely practical solution.)

> In other words, you are
>  (a) totally making up the claim that people are really unhappy

Huh?  I thought *you* were violently unhappy with the idea of naming
mutex acquire and release down() and up(), and your e-mail is an example
of this unhapiness.

Am I making it up that you are unhappy with usurping the down() and up()
names for mutex use?  If this is you being happy, I'd hate to see
unhappy.

> So tell me, what do you think about your own arguments in that light?

I think they're still completely valid.  Nothing you've said even seems
to address the points I've raised.

>> But regardless of the eventual naming convention, mutexes are a good idea.
>> A mutex is *safer* than a counting semaphore.  That's the main benefit.
>> Indeed, unless there's a performance advantage to a counting semaphore,
>> you should use a mutex!

> Hey, feel free to introduce a mutex, but DAMMIT, just call it that, 
> instead of switching people over. 

As I said, as long as the -rt patch was not in the main tree, taking
advantage of the fact that 95% of the down() and up() callers just want
a mutex was a sensible implementation tradeoff.  For merging it into the
tree, it's ugly, and people don't like that.  The -rt folks have gotten
used to their naming perversions and so don't feel as much repugnance.

> And even then, it should damn well also:
>  - really _be_ faster. On platforms that matter. 
>  - have enough real other advantages that it's worth introducing another 
>    abstraction, and more conceptual complexity. At least the RT patches 
>    had a reason for them.

Agreed.  A mutex that's slower than a counting semaphore needs to be
dragged out behind the wodshed and strangled.  If you can't do
any better, it can just *be* a counting semaphore.

> And besides, all your "safer" arguments are pretty damn pointless in the 
> face of the fact that we have basically had zero bugs with the semaphores. 
> This is not where the bugs happen. Yeah, yeah, double releases can happen, 
> but it sure as hell isn't on my radar of things I remember people doing.

There haven't been problems with the semaphore *implementation*, but
people screw up and deadlock themselves often enough.  I sure remember
double-acquire lockups.  Forgive me if I don't grep the archives, but
I remember people showing code paths that led to them.

Admittedly, lock *ordering* problems are the most common deadlock
situtation but hey, guess what!  Priority inheritance code can be
extended to notice that, too.  (There's a performance hit, so it'd
be a debug option.)

But all of this requires that a lock have an identifiable owner, which
is something hat a mutex has and a semaphore fundamentally doesn't.

> So when you say "This isn't about speed, this is about bug-free code", 
> you're just making that up.
>
> It's doubly silly when your "safer" 
> implementation uses totally illogical names. THAT is what creates bugs.

If you want to argue about names, go discuss gay marriage.

I don't care what it's *called*.  I care that we have stronger
conditions that we can test for correctness.

> So go away.
> 
> Come back if you have pondered, and accepted reality, and perhaps have an 
> acceptable patch that introduces a separate data structure. 

Ha!  I still say you're wrong, and I'm not going to fold over an obvious
technical point just because of flaming.

Are we having some communication problems?  I find it hard to believe
that you're actually this *stupid*, but we might not be talking about
the same thing.

I took your posting to say that

a) Using the names "struct semaphore", "up()" and "down()" for a mutex
   is monumentally brain-dead.  I'm not arguing, although I understand
   the pragmatic reasons for the original abuse of notation.

b) There is no need for a mutex implementation, because a semaphore can
   do anything that a mutex can.  Here, I absolutely disagree.  There
   are things you can do with a mutex that you CANNOT do with a
   general semaphore, because a mutex has stronger invariants.

   A counting semaphore can do MOST of what a mutex does, and is
   demonstrably close enough for a lot of uses.

> And no, we're not switching users over whole-sale.  First you introduce the 
> new concept.  Only THEN can you can switch over INDIVIDUAL LOCKS with 
> reasons for why it's worth it.

Given that 95% of callers are using it as mutex, you're making this 20
times more work than necessary.  Convert 'em all and change the 5%
that need the counting back.

> And hell yes, performance does matter.

I'm not arguing, but this seems to be at odds with your earlier statement:
>>> Dammit, unless the pure mutex has a _huge_ performance advantage on major 
>>> architectures, we're not changing it.

There is obviously no reason to accept a performance *decrease*, but
any potential performance *increase* is unimportant and incidental.

Which is exactly what I said:
>> Indeed, unless there's a performance advantage to a counting semaphore,
>> you should use a mutex!

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:15 ` Linus Torvalds
  2005-12-15 16:52   ` Erik Mouw
@ 2005-12-15 19:02   ` Nikita Danilov
  2005-12-15 19:09   ` linux
  2005-12-15 20:52   ` Steven Rostedt
  3 siblings, 0 replies; 249+ messages in thread
From: Nikita Danilov @ 2005-12-15 19:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

Linus Torvalds writes:
 > 
 > 
 > On Thu, 15 Dec 2005, linux@horizon.com wrote:
 > > 
 > > A counting semaphore is NOT a perfectly fine mutex, and it SHOULD be changed.
 > 
 > Don't be silly.
 > 
 > First off, the data structure is called a "semaphore", and always has 
 > been. It's _never_ been called a "mutex" in the first place, and the 
 > operations have been called "down()" and "up()", because I thought calling 
 > them P() and V() was just too damn traditional and confusing (I don't 
 > speak dutch, and even if I did, I think shortening names to that degree is 
 > just evil).
 > 
 > And dammit, a counting semaphore (and usually you don't even say the 
 > "counting" part, since counting is really always there) is just about 
 > _the_ classical mutual exclusion mechanism. If somebody doesn't know that, 
 > he has absolutely _no_ place talking about mutexes etc.

Dijkstra (that cannot talk about this due to much more serious reasons)
didn't know this, because semaphores were initially used as a
wait/signal mechanism to provide concurrency control between "process
context" and "interrupts" however they were called at the time, and
calling this "just mutual exclusion" is stretching a bit far.

Mutex implies usage pattern much narrower than generic semaphore. 

 > 
 > And a semaphore _is_ a mutex. 

Nope, a mutex is a semaphore and not other way around. For one thing, a
notion of ownership is well-defined for the mutex, but it is not for a
semaphore. This is what they call "sub-type".

 >                              Anybody who disputes that is just being a 
 > total troll. 

Oh wait... what is that thing on the right of my screen? This
is... gnome task-list!

[...]

 > 
 > And I can't understand how somebody has the balls to even say that a 
 > semaphore isn't a mutex. That's like saying that an object of type "long" 
 > isn't an integer, because only "int" objects are integers. That's just 
 > INSANE.

And the person that claims that "long" is an "int" is non-portable. :-)

[...]

 > 
 > 			Linus

Nikita.

^ permalink raw reply	[flat|nested] 249+ messages in thread

* RE: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 17:45 Luck, Tony
  2005-12-15 18:00 ` David Howells
@ 2005-12-15 18:48 ` James Bottomley
  2005-12-15 20:38 ` Jeff Dike
  2 siblings, 0 replies; 249+ messages in thread
From: James Bottomley @ 2005-12-15 18:48 UTC (permalink / raw)
  To: Luck, Tony
  Cc: dhowells, Andrew Morton, Mark Lord, tglx, alan, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch

On Thu, 2005-12-15 at 09:45 -0800, Luck, Tony wrote:
> There was a USENIX paper a couple of decades ago that described how
> to do a fast s/w disable of interrupts on machines where really disabling
> interrupts was expensive.  The rough gist was that the spl[1-7]()
> functions would just set a flag in memory to hold the desired interrupt
> mask.  If an interrupt actually occurred when it was s/w blocked, the
> handler would set a pending flag, and just rfi with interrupts disabled.
> Then the splx() code checked to see whether there was a pending interrupt
> and dealt with it if there was.

Would you believe that that paper was written about the NCR Voyager
architecture (The VIC is very expensive for interrupt disables) and that
the current Linux Voyager Subarchitecture still makes partial use of the
scheme.

James



^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 17:45 Luck, Tony
@ 2005-12-15 18:00 ` David Howells
  2005-12-15 18:48 ` James Bottomley
  2005-12-15 20:38 ` Jeff Dike
  2 siblings, 0 replies; 249+ messages in thread
From: David Howells @ 2005-12-15 18:00 UTC (permalink / raw)
  To: Luck, Tony
  Cc: dhowells, Andrew Morton, Mark Lord, tglx, alan, pj, mingo, hch,
	torvalds, arjan, matthew, linux-kernel, linux-arch

Luck, Tony <tony.luck@intel.com> wrote:

> There was a USENIX paper a couple of decades ago that described how
> to do a fast s/w disable of interrupts on machines where really disabling
> interrupts was expensive.  The rough gist was that the spl[1-7]()
> functions would just set a flag in memory to hold the desired interrupt
> mask.

Cute. The slow bit on FRV is any time you access the PSR register (read or
write). It seems to be something on the order of 60 clock cycles a pop - in
which time the CPU could have executed 120 instructions under ideal
circumstances.

I do something like this to implement "atomic" operations, playing on the
FRV's ability to pack two instructions atomically together and to have
conditionally executed instructions:

	Documentation/fujitsu/frv/atomic-ops.txt.

Trading off against the memory speed might just do it - though you have to do
a write and a read (the latter of which should hopefully be cached). I could
always steal another register (I have 31-ish to play with, plus a bunch of
single-bit condition values).

It'd make the exception prologue even more "interesting" though...:-)

Hmmm...

David

^ permalink raw reply	[flat|nested] 249+ messages in thread

* RE: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
@ 2005-12-15 17:45 Luck, Tony
  2005-12-15 18:00 ` David Howells
                   ` (2 more replies)
  0 siblings, 3 replies; 249+ messages in thread
From: Luck, Tony @ 2005-12-15 17:45 UTC (permalink / raw)
  To: dhowells, Andrew Morton
  Cc: Mark Lord, tglx, alan, pj, mingo, hch, torvalds, arjan, matthew,
	linux-kernel, linux-arch

     Okay, spinlocks are null ops when CONFIG_SMP and CONFIG_DEBUG_SPINLOCK
     are both disabled, but you still have to disable interrupts, and that
     slows things down, sometimes quite appreciably. It is, for example,
     something I really want to avoid doing on FRV as it takes a *lot* of
     cycles.

There was a USENIX paper a couple of decades ago that described how
to do a fast s/w disable of interrupts on machines where really disabling
interrupts was expensive.  The rough gist was that the spl[1-7]()
functions would just set a flag in memory to hold the desired interrupt
mask.  If an interrupt actually occurred when it was s/w blocked, the
handler would set a pending flag, and just rfi with interrupts disabled.
Then the splx() code checked to see whether there was a pending interrupt
and dealt with it if there was.

-Tony

 

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:52   ` Erik Mouw
@ 2005-12-15 17:23     ` Dick Streefland
  2005-12-16 12:17     ` Erik Mouw
  1 sibling, 0 replies; 249+ messages in thread
From: Dick Streefland @ 2005-12-15 17:23 UTC (permalink / raw)
  To: linux-kernel

Erik Mouw <erik@harddisk-recovery.com> wrote:
| Just FYI, according to Dijkstra[1] V means "verhoog" which is dutch for
| "increase". P means "prolaag" which isn't a dutch word, just something
| Dijkstra invented. I guess he did that because "decrease" is "verlaag"
| in dutch and that would give you the confusing V() and V()
| operations...
| 
| Other explanations you see in dutch CS courses are "passeer" (pass),
| "probeer" (try), "vrijgave" (unlock).

As far as I can remember, P() stands for "pakken" (grab) and V()
stands for "vrijgeven" (release).

-- 
Dick Streefland                      ////                      Altium BV
dick.streefland@altium.nl           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------


^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 16:15 ` Linus Torvalds
@ 2005-12-15 16:52   ` Erik Mouw
  2005-12-15 17:23     ` Dick Streefland
  2005-12-16 12:17     ` Erik Mouw
  2005-12-15 19:02   ` Nikita Danilov
                     ` (2 subsequent siblings)
  3 siblings, 2 replies; 249+ messages in thread
From: Erik Mouw @ 2005-12-15 16:52 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux, linux-kernel

On Thu, Dec 15, 2005 at 08:15:49AM -0800, Linus Torvalds wrote:
> First off, the data structure is called a "semaphore", and always has 
> been. It's _never_ been called a "mutex" in the first place, and the 
> operations have been called "down()" and "up()", because I thought calling 
> them P() and V() was just too damn traditional and confusing (I don't 
> speak dutch, and even if I did, I think shortening names to that degree is 
> just evil).

Just FYI, according to Dijkstra[1] V means "verhoog" which is dutch for
"increase". P means "prolaag" which isn't a dutch word, just something
Dijkstra invented. I guess he did that because "decrease" is "verlaag"
in dutch and that would give you the confusing V() and V()
operations...

Other explanations you see in dutch CS courses are "passeer" (pass),
"probeer" (try), "vrijgave" (unlock).

I do agree that Dijkstra should have used Prolaag() and Verhoog(), but
I guess those operations wouldn't have sticked in the english CS
literature.


Erik

[1] http://www.cs.utexas.edu/users/EWD/ewd00xx/EWD74.PDF

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
  2005-12-15 13:58 linux
@ 2005-12-15 16:15 ` Linus Torvalds
  2005-12-15 16:52   ` Erik Mouw
                     ` (3 more replies)
  0 siblings, 4 replies; 249+ messages in thread
From: Linus Torvalds @ 2005-12-15 16:15 UTC (permalink / raw)
  To: linux; +Cc: linux-kernel



On Thu, 15 Dec 2005, linux@horizon.com wrote:
> 
> A counting semaphore is NOT a perfectly fine mutex, and it SHOULD be changed.

Don't be silly.

First off, the data structure is called a "semaphore", and always has 
been. It's _never_ been called a "mutex" in the first place, and the 
operations have been called "down()" and "up()", because I thought calling 
them P() and V() was just too damn traditional and confusing (I don't 
speak dutch, and even if I did, I think shortening names to that degree is 
just evil).

And dammit, a counting semaphore (and usually you don't even say the 
"counting" part, since counting is really always there) is just about 
_the_ classical mutual exclusion mechanism. If somebody doesn't know that, 
he has absolutely _no_ place talking about mutexes etc.

And a semaphore _is_ a mutex. Anybody who disputes that is just being a 
total troll. Even classically, the case where the semaphore was 
initialized to 1 is very very traditional, and is very much part of the 
whole point of a semaphore. Sometimes they are called "binary semaphores", 
but dammit, they are just the same thing.

A patch that
 - creates a non-counting mutex
 - .. that is SLOWER than the current counting one
 - .. and keeps the old "semaphore" and "up/down" naming

is simply INCREDIBLY BROKEN. It has absolutely _zero_ redeeming features. 
I can't understand how there are a hundred emails in my mailbox even 
discussing it. 

And I can't understand how somebody has the balls to even say that a 
semaphore isn't a mutex. That's like saying that an object of type "long" 
isn't an integer, because only "int" objects are integers. That's just 
INSANE.

> People are indeed unhappy with the naming, and whether patching 95%
> of the callers of up() and down() is a good idea is a valid and active
> subject of debate.  (For an out-of-tree -rt patch, is was certaintly
> an extremely practical solution.)

Whatever people you claim are unhappy with the naming are
 - obviously totally unaware of very basic synchronization primitives
   used in concurrent programming
 - likely haven't spent any time at all looking at the kernel source code.
 - haven't _ever_ complained that I've seen before this totally made-up 
   discussion.

In other words, you are
 (a) totally making up the claim that people are really unhappy
 (b) jerking people around who _do_ know about semaphores and _have_ 
     worked with the kernel locking primitives and understand them well

So tell me, what do you think about your own arguments in that light?

> But regardless of the eventual naming convention, mutexes are a good idea.
> A mutex is *safer* than a counting semaphore.  That's the main benefit.
> Indeed, unless there's a performance advantage to a counting semaphore,
> you should use a mutex!

Hey, feel free to introduce a mutex, but DAMMIT, just call it that, 
instead of switching people over. 

And even then, it should damn well also:
 - really _be_ faster. On platforms that matter. 
 - have enough real other advantages that it's worth introducing another 
   abstraction, and more conceptual complexity. At least the RT patches 
   had a reason for them.

And besides, all your "safer" arguments are pretty damn pointless in the 
face of the fact that we have basically had zero bugs with the semaphores. 
This is not where the bugs happen. Yeah, yeah, double releases can happen, 
but it sure as hell isn't on my radar of things I remember people doing.

So when you say "This isn't about speed, this is about bug-free code", 
you're just making that up. It's doubly silly when your "safer" 
implementation uses totally illogical names. THAT is what creates bugs.

So go away.

Come back if you have pondered, and accepted reality, and perhaps have an 
acceptable patch that introduces a separate data structure. 

And no, we're not switching users over whole-sale. First you introduce the 
new concept. Only THEN can you can switch over INDIVIDUAL LOCKS with 
reasons for why it's worth it.

And hell yes, performance does matter.

			Linus

^ permalink raw reply	[flat|nested] 249+ messages in thread

* Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
@ 2005-12-15 13:58 linux
  2005-12-15 16:15 ` Linus Torvalds
  0 siblings, 1 reply; 249+ messages in thread
From: linux @ 2005-12-15 13:58 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

Our Fearless Leader, in a fit of madness, intoned:
> A real semaphore is counting. 
> 
> Dammit, unless the pure mutex has a _huge_ performance advantage on major 
> architectures, we're not changing it. There's absolutely zero point. A 
> counting semaphore is a perfectly fine mutex - the fact that it can _also_ 
> be used to allow more than 1 user into a critical region and generally do 
> other things is totally immaterial.

You're being thick today.  Pay attention to the arguments.

A counting semaphore is NOT a perfectly fine mutex, and it SHOULD be changed.

People are indeed unhappy with the naming, and whether patching 95%
of the callers of up() and down() is a good idea is a valid and active
subject of debate.  (For an out-of-tree -rt patch, is was certaintly
an extremely practical solution.)

But regardless of the eventual naming convention, mutexes are a good idea.
A mutex is *safer* than a counting semaphore.  That's the main benefit.
Indeed, unless there's a performance advantage to a counting semaphore,
you should use a mutex!

It documents in the source what you're doing.  Using a counting semaphore
for a mutex is as silly as using a float for a loop index.  Even if
there isn't much speed penalty on modern processors.

Or perhaps I should compare it to using void * everywhere.  That's a
perfectly fine pointer; why type-check it?

A separate mutex type allows extra error-checking.  You can keep track
of the current holder (since there can be only one) and check that the
same person released it and didn't try to double-acquire it.

You can do priority inheritance, which is the main motivation for doing
this work in the -rt patches.

This isn't about speed, it's about bug-free code.  And having a mutex
abstraction distinct from a general counting semaphore is damn useful
error-checking, even if it is simply a thin wrapper over a counting
semaphore.  The only reason the code is full of counting semaphores
right now is that that's all people had.

Better to give them the right tool.

^ permalink raw reply	[flat|nested] 249+ messages in thread

end of thread, other threads:[~2005-12-22 12:48 UTC | newest]

Thread overview: 249+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-12 23:45 [PATCH 1/19] MUTEX: Introduce simple mutex implementation David Howells
2005-12-12 23:45 ` [PATCH 2/19] MUTEX: i386 arch mutex David Howells
2005-12-12 23:45 ` [PATCH 8/19] MUTEX: Drivers I-K changes David Howells
2005-12-12 23:45 ` [PATCH 7/19] MUTEX: Drivers F-H changes David Howells
2005-12-12 23:45 ` [PATCH 6/19] MUTEX: Drivers A-E changes David Howells
2005-12-12 23:45 ` [PATCH 3/19] MUTEX: x86_64 arch mutex David Howells
2005-12-12 23:45 ` [PATCH 5/19] MUTEX: Core kernel changes David Howells
2005-12-12 23:45 ` [PATCH 4/19] MUTEX: FRV arch mutex David Howells
2005-12-12 23:45 ` [PATCH 15/19] MUTEX: Second set of include changes David Howells
2005-12-12 23:45 ` [PATCH 10/19] MUTEX: Drivers N-P changes David Howells
2005-12-12 23:45 ` [PATCH 9/19] MUTEX: Drivers L-M changes David Howells
2005-12-12 23:45 ` [PATCH 13/19] MUTEX: Filesystem changes David Howells
2005-12-12 23:45 ` [PATCH 14/19] MUTEX: First set of include changes David Howells
2005-12-12 23:45 ` [PATCH 12/19] MUTEX: Drivers T-Z changes David Howells
2005-12-12 23:45 ` [PATCH 11/19] MUTEX: Drivers Q-S changes David Howells
2005-12-12 23:45 ` [PATCH 18/19] MUTEX: Security changes David Howells
2005-12-12 23:45 ` [PATCH 17/19] MUTEX: Networking changes David Howells
2005-12-12 23:45 ` [PATCH 16/19] MUTEX: IPC changes David Howells
2005-12-12 23:45 ` [PATCH 19/19] MUTEX: Sound changes David Howells
2005-12-13  0:13 ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Nick Piggin
2005-12-13  0:19 ` Nick Piggin
2005-12-13  0:19 ` Andrew Morton
2005-12-13  7:54   ` Ingo Molnar
2005-12-13  7:58     ` Andi Kleen
2005-12-13  8:42       ` Andrew Morton
2005-12-13  8:49         ` Andi Kleen
2005-12-13  9:01           ` Andrew Morton
2005-12-13  9:02             ` Andrew Morton
2005-12-13 10:07               ` Jakub Jelinek
2005-12-13 10:11                 ` Andi Kleen
2005-12-13 10:15                   ` Jakub Jelinek
2005-12-13 10:25                   ` Andrew Morton
2005-12-14 10:46               ` Russell King
2005-12-13  9:05             ` Andi Kleen
2005-12-13  9:15               ` Andrew Morton
2005-12-13  9:24                 ` Andi Kleen
2005-12-13  9:44                   ` Andrew Morton
2005-12-13  9:49                     ` Andi Kleen
2005-12-13 10:28                   ` Andreas Schwab
2005-12-13 10:30                     ` Andi Kleen
2005-12-13 12:33                   ` Matthew Wilcox
2005-12-13 22:18               ` Adrian Bunk
2005-12-13 22:25                 ` Andi Kleen
2005-12-13 22:32                   ` Adrian Bunk
2005-12-13  9:11             ` Ingo Molnar
2005-12-13  9:04           ` Christoph Hellwig
2005-12-13  9:13             ` Ingo Molnar
2005-12-13 10:11             ` Jakub Jelinek
2005-12-13 10:19               ` Christoph Hellwig
2005-12-13 10:27                 ` Ingo Molnar
2005-12-15  4:53                 ` Miles Bader
2005-12-15  5:05                   ` Nick Piggin
2005-12-13  9:09           ` Ingo Molnar
2005-12-13  9:21             ` Andi Kleen
2005-12-13 16:16           ` Linus Torvalds
2005-12-13 21:56             ` Using C99 in the kernel was " Andi Kleen
2005-12-13 23:05               ` Al Viro
2005-12-13 23:41                 ` Andi Kleen
2005-12-13  9:03         ` Christoph Hellwig
2005-12-13  9:14           ` Andrew Morton
2005-12-13  9:21             ` Christoph Hellwig
2005-12-13 10:31             ` drivers/scsi/sd.c gcc-2.95.3 Alexey Dobriyan
2005-12-13  8:00     ` [PATCH 1/19] MUTEX: Introduce simple mutex implementation Arjan van de Ven
2005-12-13  9:03       ` Ingo Molnar
2005-12-13  9:09         ` Andi Kleen
2005-12-13  9:34           ` Ingo Molnar
2005-12-13 14:33             ` Mark Lord
2005-12-13 14:45               ` Arjan van de Ven
2005-12-13  9:37           ` Ingo Molnar
2005-12-13  9:19         ` Arjan van de Ven
2005-12-13  9:02     ` Christoph Hellwig
2005-12-13  9:39       ` Ingo Molnar
2005-12-13 10:00         ` Ingo Molnar
2005-12-13 17:40           ` Paul Jackson
2005-12-13 18:34           ` David Howells
2005-12-13 22:31             ` Paul Jackson
2005-12-14 11:02             ` David Howells
2005-12-14 11:12             ` David Howells
2005-12-14 11:18               ` Alan Cox
2005-12-14 12:35               ` David Howells
2005-12-14 13:58                 ` Thomas Gleixner
2005-12-14 23:40                   ` Mark Lord
2005-12-14 23:54                     ` Andrew Morton
2005-12-15 13:41                       ` Nikita Danilov
2005-12-15 14:56                         ` Alan Cox
2005-12-15 15:52                           ` Nikita Danilov
2005-12-15 16:50                             ` Christopher Friesen
2005-12-15 20:53                               ` Steven Rostedt
2005-12-15 15:55                           ` David Howells
2005-12-15 16:22                             ` linux-os (Dick Johnson)
2005-12-15 16:28                             ` Linus Torvalds
2005-12-15 17:04                               ` Thomas Gleixner
2005-12-15 17:09                               ` Paul Jackson
2005-12-15 17:17                               ` David Howells
2005-12-15 16:51                             ` David Howells
2005-12-15 16:56                             ` Paul Jackson
2005-12-15 17:28                             ` David Howells
2005-12-15 17:48                               ` Linus Torvalds
2005-12-15 18:20                                 ` Nikita Danilov
2005-12-15 20:58                                   ` Steven Rostedt
2005-12-15 19:21                                 ` Andrew Morton
2005-12-15 19:38                                   ` Linus Torvalds
2005-12-15 20:28                                   ` Steven Rostedt
2005-12-15 20:32                                     ` Geert Uytterhoeven
2005-12-16 21:41                                       ` Thomas Gleixner
2005-12-16 21:41                                         ` Linus Torvalds
2005-12-16 22:06                                           ` Thomas Gleixner
2005-12-16 22:19                                             ` Linus Torvalds
2005-12-16 22:32                                               ` Steven Rostedt
2005-12-16 22:42                                               ` Thomas Gleixner
2005-12-16 22:41                                                 ` Linus Torvalds
2005-12-16 22:49                                                   ` Steven Rostedt
2005-12-16 23:29                                                   ` Thomas Gleixner
2005-12-17  0:29                                                   ` Joe Korty
2005-12-17  1:00                                                     ` Linus Torvalds
2005-12-17  3:13                                                       ` Steven Rostedt
2005-12-17  7:34                                                         ` Linus Torvalds
2005-12-17 23:43                                                           ` Matthew Wilcox
2005-12-18  0:05                                                             ` Lee Revell
2005-12-18  0:21                                                               ` Matthew Wilcox
2005-12-18  1:25                                                                 ` Lee Revell
2005-12-22 12:27                                                             ` Bill Huey
2005-12-19 16:08                                                           ` Ingo Molnar
2005-12-22 12:40                                                           ` Bill Huey
2005-12-22 12:45                                                             ` Bill Huey
2005-12-19 23:46                                                       ` Keith Owens
2005-12-15 14:41                       ` Steven Rostedt
2005-12-14 23:57                     ` Thomas Gleixner
2005-12-14 23:57                       ` Mark Lord
2005-12-15  0:10                         ` Thomas Gleixner
2005-12-15  2:46                           ` Linus Torvalds
2005-12-15 15:53                           ` David Howells
2005-12-15 15:37                     ` David Howells
2005-12-15 19:28                       ` Andrew Morton
2005-12-15 20:18                         ` Andrew Morton
2005-12-15 21:28                           ` Steven Rostedt
2005-12-16 22:02                           ` Thomas Gleixner
2005-12-16 10:45                         ` David Howells
2005-12-13  9:55     ` Ingo Molnar
2005-12-13  0:30 ` Arnd Bergmann
2005-12-13  0:57 ` Daniel Walker
2005-12-13  3:23   ` Steven Rostedt
2005-12-13  2:57 ` Mark Lord
2005-12-13  3:17   ` Steven Rostedt
2005-12-13  9:06   ` Christoph Hellwig
2005-12-13  9:54 ` David Howells
2005-12-13 10:13   ` Ingo Molnar
2005-12-13 10:34     ` Ingo Molnar
2005-12-13 10:37       ` Ingo Molnar
2005-12-13 12:47       ` Oliver Neukum
2005-12-13 13:09         ` Alan Cox
2005-12-13 13:13           ` Matthew Wilcox
2005-12-13 14:04             ` Alan Cox
2005-12-13 13:24           ` Oliver Neukum
2005-12-14  1:00   ` Nick Piggin
2005-12-14 10:54   ` David Howells
2005-12-14 11:17     ` Nick Piggin
2005-12-14 11:46     ` David Howells
2005-12-14 21:23       ` Nick Piggin
2005-12-16 12:00       ` David Howells
2005-12-16 13:16         ` Nick Piggin
2005-12-16 15:53         ` David Howells
2005-12-16 23:41           ` Nick Piggin
2005-12-16 16:02         ` David Howells
2005-12-13 10:48 ` David Howells
2005-12-13 12:39   ` Matthew Wilcox
2005-12-13 10:54 ` Ingo Molnar
2005-12-13 11:23 ` David Howells
2005-12-13 11:24 ` David Howells
2005-12-13 13:45   ` Ingo Molnar
2005-12-13 11:34 ` David Howells
2005-12-13 13:05 ` Alan Cox
2005-12-13 13:15   ` Alan Cox
2005-12-13 23:21     ` Nikita Danilov
2005-12-13 13:32 ` David Howells
2005-12-13 14:00   ` Alan Cox
2005-12-13 14:35   ` Christopher Friesen
2005-12-13 14:44     ` Arjan van de Ven
2005-12-13 14:59       ` Christopher Friesen
2005-12-13 15:23   ` David Howells
2005-12-15  5:24     ` Miles Bader
2005-12-13 15:39   ` David Howells
2005-12-13 16:10     ` Alan Cox
2005-12-14 10:29       ` Arjan van de Ven
2005-12-14 11:03         ` Arjan van de Ven
2005-12-14 11:03         ` Alan Cox
2005-12-14 11:08           ` Arjan van de Ven
2005-12-14 11:24             ` Alan Cox
2005-12-14 11:35               ` Andrew Morton
2005-12-14 11:44                 ` Arjan van de Ven
2005-12-14 11:52                   ` Andi Kleen
2005-12-14 11:55                     ` Arjan van de Ven
2005-12-14 11:57                 ` David Howells
2005-12-14 12:19                   ` Jakub Jelinek
2005-12-16  1:54                   ` Nick Piggin
2005-12-16 11:02                   ` David Howells
2005-12-16 13:01                     ` Nick Piggin
2005-12-16 13:21                       ` Russell King
2005-12-16 13:41                         ` Nick Piggin
2005-12-16 13:46                         ` Linh Dang
2005-12-16 14:31                           ` Russell King
2005-12-16 15:24                             ` Linh Dang
2005-12-16 15:35                               ` Nick Piggin
2005-12-16 15:40                               ` Kyle Moffett
2005-12-16 15:49                             ` Linh Dang
2005-12-16 15:46                           ` David Howells
2005-12-16 15:58                             ` Russell King
2005-12-17 15:57                       ` Nikita Danilov
2005-12-16 16:28                     ` Linus Torvalds
2005-12-16 11:30                   ` David Howells
2005-12-16 16:33                     ` Linus Torvalds
2005-12-16 22:23                       ` David S. Miller
2005-12-16 22:38                         ` Linus Torvalds
2005-12-16 22:53                           ` David S. Miller
2005-12-17  0:41                             ` Jesse Barnes
2005-12-17  7:10                               ` David S. Miller
2005-12-17  7:40                                 ` Linus Torvalds
2005-12-17 17:22                                   ` Jesse Barnes
2005-12-17 17:19                                 ` Jesse Barnes
2005-12-17 22:38                             ` Richard Henderson
2005-12-17 23:05                               ` David S. Miller
2005-12-14 12:17                 ` Christoph Hellwig
2005-12-14 11:42               ` Arjan van de Ven
2005-12-14  8:31     ` Ingo Molnar
2005-12-13 20:04   ` Steven Rostedt
2005-12-13 21:03 ` David Howells
2005-12-15 13:58 linux
2005-12-15 16:15 ` Linus Torvalds
2005-12-15 16:52   ` Erik Mouw
2005-12-15 17:23     ` Dick Streefland
2005-12-16 12:17     ` Erik Mouw
2005-12-17 10:59       ` Sander
2005-12-17 14:14         ` Douglas McNaught
2005-12-17 15:09           ` Sander
2005-12-19 10:44         ` Erik Mouw
2005-12-15 19:02   ` Nikita Danilov
2005-12-15 19:09   ` linux
2005-12-15 19:52     ` Linus Torvalds
2005-12-16  1:33       ` linux
2005-12-15 21:18     ` Steven Rostedt
2005-12-15 20:52   ` Steven Rostedt
2005-12-15 17:45 Luck, Tony
2005-12-15 18:00 ` David Howells
2005-12-15 18:48 ` James Bottomley
2005-12-15 20:38 ` Jeff Dike
2005-12-15 23:45   ` Stephen Rothwell
2005-12-16 12:49 linux
2005-12-16 15:24 ` David Howells
2005-12-16 18:03   ` linux

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).