linux-kernel - Re: [patch/rfc] eventfd semaphore-like behavior

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, 9 Feb 2009 09:39:52 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	mtk.manpages@...il.com
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch/rfc] eventfd semaphore-like behavior

On Mon, 9 Feb 2009, Michael Kerrisk wrote:

> On Thu, Feb 5, 2009 at 11:58 AM, Davide Libenzi <davidel@...ilserver.org> wrote:
> > People started using eventfd in scnarios where before where using pipes.
> > Many of them use eventfds in a semaphore-like way, like they were before
> > with pipes. The problem with eventfd is that a read() on the fd returns
> > and wipes the whole counter, making the use of it as semaphore a little
> > bit more cumbersome. You can do a read() followed by a write() of
> > COUNTER-1, but IMO it's pretty easy and cheap to make this work w/out
> > extra steps. This patch introduces a new eventfd flag that tells eventfd
> > to only dequeue 1 from the counter, allowing simple read/write to make it
> > behave like a semaphore.
> > Simple test here:
> >
> > http://www.xmailserver.org/eventfd-sem.c
> >
> >
> > Signed-off-by: Davide Libenzi <davidel@...ilserver.org>
> 
> Tested-by: Michael Kerrisk <mtk.manpages@...il.com>
> 
> Applied this patch against 2.6.29-rc3, and it works as I would expect.
> 
> 
> A question or two.... This change is rather specific to a single use
> case, so I wonder
> 
> a) Are there use cases that require the ability to read an arbitrary
> number of units off the eventfd -- i.e., read N units off the eventfd,
> rather than just 1?

Not that I can think of.


> b) Is it desirable to be able to toggle the EFD_SEMAPHORE behavior on
> and off for an eventfd?

This I'd say no. A synchronization entity in all decently sane sw design 
I've ever seen, remains the same in behaviour and it is never changed 
runtime to behave in different ways.


> It's difficult to see how these use cases could be accommodated in the
> current API, but I just thought it worth raising the ideas.

Since read/write semantics cannot be changed (besides, like the semaphore 
change, for the amount of "data" dequeued), deeper changes to the 
interface will have to go via ioctl(). But I don't see any reason to go 
that way ATM.



- Davide


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