linux-kernel - Re: "upping" a semaphore from interrupt context?

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]

Message-ID: <Pine.LNX.4.64.0706241123130.7006@localhost.localdomain>
Date:	Sun, 24 Jun 2007 11:25:46 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Satyam Sharma <satyam.sharma@...il.com>
cc:	Arnd Bergmann <arnd@...db.de>, Florin Iucha <florin@...ha.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: "upping" a semaphore from interrupt context?

On Sat, 23 Jun 2007, Satyam Sharma wrote:

> On 6/23/07, Robert P. J. Day <rpjday@...dspring.com> wrote:

> > hang on, how is that true?  as i read it, mutexes are more than
> > just binary semaphores -- they have additional restrictions that
> > regular semaphores don't.
>
> Yes, they do have additional restrictions (mutex_trylock() illegal
> from contexts that cannot sleep, mutexes may only be unlocked by
> tasks that took them in the first place). But note that these are
> _implementation_ sanity checks that were introduced to catch
> nonsensical usage, which was possible (and not explicitly being
> guarded against, because of the generic-ness that was needed to be
> maintained for the counted case too) with the "semaphore"s.
>
> > so i'm not convinced that binary semaphores can simply be replaced
> > by mutexes, unless that's not what you meant here.
>
> I do mean precisely that. I really cannot think of any sensible /
> normal usage case of binary semaphores that cannot be replaced with
> either mutexes (if that's the kind of locking you actually want) or
> completion handlers (if that's the kind of synchronization you
> actually want).

ok, i can see what you're getting at now.  i'm just going to have to
convince myself that, once you have mutexes and completions, you have
no further need for even general counting semaphores.

rday
-
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/