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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Jul 2009 00:21:06 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [Patch RFC 14/37] scsi: aacraid semaphore cleanup

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/