netdev - Re: epoll, missed opportunity?

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: <CACKT+Ap2n7d0C06=1bq=qvJ9o-6X+-EUNcGdLreszL=fABTguQ@mail.gmail.com>
Date:	Sat, 19 Sep 2015 09:30:47 -0600
From:	Jonathan Marler <johnnymarler@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: epoll, missed opportunity?

The data field holds the file descriptor you are waiting on, it has to
be the file descriptor, otherwise, how would the kernel know which
file descriptor you are trying to wait on?

On Sat, Sep 19, 2015 at 9:21 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Fri, 2015-09-18 at 22:51 -0600, Jonathan Marler wrote:
>> I'm curious why there wasn't another field added to the epoll_event
>> struct for the application to store the descriptor's context. Any
>> useful multi-plexing application will have a context that will need to
>> be retrieved every time a descriptor needs to be serviced. Since the
>> epoll api has no way of storing this context, it has to be looked up
>> using the descriptor, which will take more time/memory as the number
>> of descriptors increase. The memory saved from omitting this context
>> can't be worth it since you'll have to allocate the memory in the
>> application anyway, plus you're now adding the extra lookup.
>>
>> This "lookup" problem has always existed in multi-plexed applications.
>> It was impossible to fix with older polling interfaces, however, since
>> epoll is stateful, it provides an opportunity to fix this problem by
>> storing the descriptor context in epoll's "state". What was the reason
>> for not doing this?  Was it an oversight or am I missing something?
>
>
> typedef union epoll_data
> {
>   void *ptr;
>   int fd;
>   uint32_t u32;
>   uint64_t u64;
> } epoll_data_t;
>
> struct epoll_event
> {
>   uint32_t events;      /* Epoll events */
>   epoll_data_t data;    /* User data variable */
> } __EPOLL_PACKED;
>
>
>
> Application is free to use whatever is needed in poll_data_t
>
> You can store a pointer to your own data (ptr)
> Or a 32 bit cookie (u32)
> Or a 64 bit cookie (u64)
>
> (But is an union, you have to pick one of them)
>
> Nothing forces you to use 'fd', kernel does not care.
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html