Re: [Patch RFC 14/37] scsi: aacraid semaphore cleanup

Re: [Patch RFC 14/37] scsi: aacraid semaphore cleanup

[James Bottomley]

cc linux-scsi added

On Sun, 2009-07-26 at 08:18 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (driver-scsi-aacraid-sema-cleanup.patch)
> The usage of these "mutex"es is non obvious and probably completions
> in some places. Make it them semaphores.

-ENOCONTEXT on this ... I assume this is just a global
s/init_MUTEX/semaphore_init/?

I think both are really just mutexes; no need for a counting semaphore.
There's no stack declaration issues (the fibs are long lived entities)
that would necessitate a completion.

James


> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>  drivers/scsi/aacraid/commctrl.c |    2 +-
>  drivers/scsi/aacraid/commsup.c  |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6-tip/drivers/scsi/aacraid/commctrl.c
> ===================================================================
> --- linux-2.6-tip.orig/drivers/scsi/aacraid/commctrl.c
> +++ linux-2.6-tip/drivers/scsi/aacraid/commctrl.c
> @@ -190,7 +190,7 @@ static int open_getadapter_fib(struct aa
>  		/*
>  		 *	Initialize the mutex used to wait for the next AIF.
>  		 */
> -		init_MUTEX_LOCKED(&fibctx->wait_sem);
> +		semaphore_init_locked(&fibctx->wait_sem);
>  		fibctx->wait = 0;
>  		/*
>  		 *	Initialize the fibs and set the count of fibs on
> Index: linux-2.6-tip/drivers/scsi/aacraid/commsup.c
> ===================================================================
> --- linux-2.6-tip.orig/drivers/scsi/aacraid/commsup.c
> +++ linux-2.6-tip/drivers/scsi/aacraid/commsup.c
> @@ -124,7 +124,7 @@ int aac_fib_setup(struct aac_dev * dev)
>  		fibptr->hw_fib_va = hw_fib;
>  		fibptr->data = (void *) fibptr->hw_fib_va->data;
>  		fibptr->next = fibptr+1;	/* Forward chain the fibs */
> -		init_MUTEX_LOCKED(&fibptr->event_wait);
> +		semaphore_init_locked(&fibptr->event_wait);
>  		spin_lock_init(&fibptr->event_lock);
>  		hw_fib->header.XferState = cpu_to_le32(0xffffffff);
>  		hw_fib->header.SenderSize = cpu_to_le16(dev->max_fib_size);
> 

Re: [Patch RFC 14/37] scsi: aacraid semaphore cleanup

[Thomas Gleixner]

On Sun, 26 Jul 2009, James Bottomley wrote:

> cc linux-scsi added
> 
> On Sun, 2009-07-26 at 08:18 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (driver-scsi-aacraid-sema-cleanup.patch)
> > The usage of these "mutex"es is non obvious and probably completions
> > in some places. Make it them semaphores.
> 
> -ENOCONTEXT on this ... I assume this is just a global
> s/init_MUTEX/semaphore_init/?

Well, in cases where the mutex use case is obvious it's a semaphore to
mutex conversion. But this one is definitly not.

> I think both are really just mutexes; no need for a counting semaphore.
> There's no stack declaration issues (the fibs are long lived entities)
> that would necessitate a completion.

It's not about stack declaration. These semaphores can not be
converted to mutexes for following reasons:

1) there is no mutex_init_locked() and there never will be one

2) the sem is taken from context A and released from context B. That
violates the mutex semantics where the lock/unlock has to happen in
the same thread context.

i.e. wait_sem is taken from

     aac_do_ioctl()
	next_getadapter_fib()

but release from

    aac_check_health() or aac_command_thread()

I have no idea how that hell of code works, but wait_sem is definitely
not a mutex and neither is event_wait. The beasts might serialize
stuff as well, but they are also (ab)used as a completion to wait for
whatever.

Thanks,

	tglx