Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1585545 > unrolled thread

[RFC 0/3] fs,epoll: Add ability to call kcmp to find target files

Back to article view | Back to linux.kernel

Contents

  [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files Cyrill Gorcunov <gorcunov@openvz.org> - 2017-02-21 18:20 +0100
    Re: [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files Jason Baron <jbaron@akamai.com> - 2017-02-21 21:40 +0100
      Re: [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files Cyrill Gorcunov <gorcunov@gmail.com> - 2017-02-21 22:00 +0100
        Re: [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files Cyrill Gorcunov <gorcunov@gmail.com> - 2017-02-28 18:20 +0100

#1585545 — [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files

Hi! In previous series EPOLL_CTL_DUP operation has been discussed
but considered as potentially scary. So here is an another approach:

 - extend fdinfo of epoll files with inode, device and file position
   for every target, which allow the reader to gather targets with
   this bundle as a key for primary sorting

 - extent kcmp to check if some particular file is matching one
   sitting inside epoll queue (duplicate numbers are resolved with
   offset parameter)

Please take a look once time permit. Note that I did only basic
testing (without CRIU) but it should fit our needs because we
sort and lookup regualr files by same scheme. So I'm about to
implemet full criu support for this new kernel features in
a couple of days thus any comments are *higly* appreciated.

NB: Initially I added

	if (file_ns_capable(epi->ffd.file, ns, CAP_SYS_ADMIN))

into fdinfo output to check if caller is allowed to see
target ino/dev/pos but dropped it later because if process
is added file descriptor into epoll queue it mean fdstat
and such already can be called and this information is
already obtained, so I don't this it's information
disclosure.

	Cyrill

[toc] | [next] | [standalone]

#1585721

On 02/21/2017 11:59 AM, Cyrill Gorcunov wrote:
> Hi! In previous series EPOLL_CTL_DUP operation has been discussed
> but considered as potentially scary. So here is an another approach:
>
>  - extend fdinfo of epoll files with inode, device and file position
>    for every target, which allow the reader to gather targets with
>    this bundle as a key for primary sorting
>
>  - extent kcmp to check if some particular file is matching one
>    sitting inside epoll queue (duplicate numbers are resolved with
>    offset parameter)
>

Hi,

Since an epoll fd can be added to another epoll fd, I'm wondering if you 
have enough data here to figure that out. The inode is the 
'anon_inode_inode', so I'm wondering if that is sufficient to 
distinguish it from other anonymous inodes, or if an extra bit is 
required to indicate if the target file is in fact and epoll fd.

Thanks,

-Jason

> Please take a look once time permit. Note that I did only basic
> testing (without CRIU) but it should fit our needs because we
> sort and lookup regualr files by same scheme. So I'm about to
> implemet full criu support for this new kernel features in
> a couple of days thus any comments are *higly* appreciated.
>
> NB: Initially I added
>
> 	if (file_ns_capable(epi->ffd.file, ns, CAP_SYS_ADMIN))
>
> into fdinfo output to check if caller is allowed to see
> target ino/dev/pos but dropped it later because if process
> is added file descriptor into epoll queue it mean fdstat
> and such already can be called and this information is
> already obtained, so I don't this it's information
> disclosure.
>
> 	Cyrill
>

[toc] | [prev] | [next] | [standalone]

#1585730

On Tue, Feb 21, 2017 at 03:32:21PM -0500, Jason Baron wrote:
> Hi,
> 
> Since an epoll fd can be added to another epoll fd, I'm wondering if you
> have enough data here to figure that out. The inode is the
> 'anon_inode_inode', so I'm wondering if that is sufficient to distinguish it
> from other anonymous inodes, or if an extra bit is required to indicate if
> the target file is in fact and epoll fd.

I think it should be ebough (together with sdev and pos). But will
look more closely tomorrow once I sit implementing criu support :)
(that's why it is early rfc, to gather comments)

[toc] | [prev] | [next] | [standalone]

#1589637

On Tue, Feb 21, 2017 at 11:54:34PM +0300, Cyrill Gorcunov wrote:
> 
> I think it should be ebough (together with sdev and pos). But will
> look more closely tomorrow once I sit implementing criu support :)
> (that's why it is early rfc, to gather comments)

FWIW, yes, it is enough for primary sorting key. Once it matches
the key from other anon block we use kcmp call to find exact
match (kid_epoll_lookup lookups over primary keys generated by
inode/sdev/pos, and then using kcmp we walk over files)

https://github.com/cyrillos/criu/blob/epoll-tgt-3/criu/kcmp-ids.c#L158

	Cyrill

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web