linux-kernel - Re: [PATCH-RFC 2/2] eventfd: EFD

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: <4A77FE9D.3020505@redhat.com>
Date:	Tue, 04 Aug 2009 12:25:49 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gleb Natapov <gleb@...hat.com>
CC:	"Michael S. Tsirkin" <mst@...hat.com>, davidel@...ilserver.org,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH-RFC 2/2] eventfd: EFD_STATE flag

On 08/04/2009 12:17 PM, Gleb Natapov wrote:
>> If a different read comes after the write but after our read, it will
>> have transferred the value, resulting in the same situation.
>>
>> I think reads should never block with a state based mechanism.
>>
>>      
> Reader may want to poll for the status change.
>    

Without epoll(), it's inherently racy since reads from other processes 
can clear the status.

The "last read value" needs to be maintained for each reader, which is 
not possible with read().

-- 
error compiling committee.c: too many arguments to function

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