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]

Message-Id: <20090204150507.665b5b7c.akpm@linux-foundation.org>
Date:	Wed, 4 Feb 2009 15:05:07 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	mtk.manpages@...il.com, linux-api@...r.kernel.org
Subject: Re: [patch/rfc] eventfd semaphore-like behavior

On Wed, 4 Feb 2009 14:58:39 -0800 (PST)
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.

Would be nice to spell out what "a sempahore-like way" is.

> Simple test here:
> 
> http://www.xmailserver.org/eventfd-sem.c
> 
> 
> Signed-off-by: Davide Libenzi <davidel@...ilserver.org>
> 
> +/*
> + * CAREFUL: Check include/asm-generic/fcntl.h when defining
> + * new flags, since they might collide with O_* ones. We want
> + * to re-use O_* flags that couldn't possibly have a meaning
> + * from eventfd, in order to leave a free define-space for
> + * shared O_* flags.
> + */
> +#define EFD_SEMAPHORE (1 << 0)
>  #define EFD_CLOEXEC O_CLOEXEC
>  #define EFD_NONBLOCK O_NONBLOCK
>  
> +#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
> +#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE)

How would you recommend that userspace determine whether its kernel
supports this feature, bearing in mind that someone might backport this
patch into arbitrarily earlier kernel versions?

What should be userspace's fallback strategy if that support is not
present?
--
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/