linux-kernel - Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

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:   Wed, 22 Feb 2017 11:18:33 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Pavel Emelyanov <xemul@...tuozzo.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Andrew Vagin <avagin@...tuozzo.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Kirill Kolyshkin <kir@...nvz.org>,
        Jason Baron <jbaron@...mai.com>,
        Andrey Vagin <avagin@...nvz.org>
Subject: Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll
 target files

On Wed, Feb 22, 2017 at 11:09:23AM +0300, Pavel Emelyanov wrote:
> >>
> >> Actually it shouldn't. If you extend the kcmp argument to accept the
> >> epollfd:epollslot pair, this would be effectively the same as if you
> >> had all your epoll-ed files injected into your fdtable with "strange"
> >> fd numbers. We already have two-level rbtree for this in criu, adding
> >> extended ("strange") fd to it should be OK.
> > 
> > Nope. Pavel, I guess you forget how we handle file tree in criu currently.
> > We call for kcmp only if we have to -- when primary key for two entries
> > is the same.
> 
> True, but the latter is an optimization to reduce the number of syscalls.

Exactly. While syscalls are quite effective, they are still not coming
for free, so I'm trying to reduce their number as much as possible.

> Look, in order to have a primary key you need to do some system call for the
> fd you check (read from proc or stat the descriptor). But for target files in
> e-polls you don't make this per-fd syscall to get primary key, just call the
> kcmp instead.

I have to parse fdinfo anyway, because I need to fetch queued events and mask.
So I'll _have_ to make this per-fd syscall for parsing. And this opens
a way to optimize overall picture -- we can immediately read primary
key and reduce kcmp calls.