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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 17 Feb 2017 22:45:02 +0300
From:   Cyrill Gorcunov <>
To:     Jason Baron <>
Cc:     Andy Lutomirski <>,
        Linux FS Devel <>,
        "" <>,
        Linux API <>,
        Al Viro <>,
        Andrew Morton <>,
        Andrew Vagin <>,
        Pavel Emelyanov <>,
        Michael Kerrisk <>,
        Kirill Kolyshkin <>,
        Andrey Vagin <>
Subject: Re: [RFC 1/2] fs,eventpoll: Add ability to install target file by
 its number

On Fri, Feb 17, 2017 at 01:34:04PM -0500, Jason Baron wrote:
> > 
> > kcmp over target set seems to be preferred since it gonna be a way
> > faster. But I think about fd-ref idea too. Thanks a huge!
> > 
> I sort of like kcmp() for this as well maybe the epoll fd argument can be a
> pointer to something like:
> struct epoll_slot {
> 	int epfd;
> 	int slot;
> };
> Where 'epfd' is the epoll fd, and slot is just an index into the target fds
> associated with the epoll fd. That is, you would start from 0 and go up to
> n. When you reach the last one you get in -EBADSLT or something.

Yes, I think we can even extend the slot and pass it as a pointer to
target fd set which are to be tested.

> Regarding Andy's point of of not having a reference by some other means, I
> think you have to have it basically otherwise it would be removed from the
> epfd. I guess it could be being passed via a unix socket? But there must be
> a way to get at those anyways, in order to restore them.

Yes. But the file may be obtained from unix sock, then dup'ed and installed
and then this dup'ed file get closed but unix instance is still alive. And
then we need to figure out that it's unix socket from where original target
file came from.

> Also, in the initial patch this function can not restore all target epoll
> files:
> 'ep_find_tfd(struct eventpoll *ep, int tfd)'
> Because the 'target' file for an epfd is the pair: {fd, file}. Thus, you
> could have say two different 'target' files with the same fd number.

Yes, but if we would have _DUP'ed them (ie installed into caller context)
we can find out their order and restore properly I think.

Thanks for comments, I'll think about all them at the weekend or early
next week.


Powered by blists - more mailing lists