From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrei Vagin Subject: Re: [patch v4 resend 1/2] procfs: fdinfo -- Extend information about epoll target files Date: Tue, 9 May 2017 10:48:11 -0700 Message-ID: <20170509174810.GB23798@outlook.office365.com> References: <20170424154423.436491881@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Return-path: Content-Disposition: inline In-Reply-To: <20170424154423.436491881@gmail.com> Sender: linux-kernel-owner@vger.kernel.org To: Cyrill Gorcunov Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, viro@zeniv.linux.org.uk, akpm@linuxfoundation.org, xemul@virtuozzo.com, mtk.manpages@gmail.com, gorcunov@openvz.org, avagin@openvz.org, jbaron@akamai.com, luto@amacapital.net List-Id: linux-api@vger.kernel.org On Mon, Apr 24, 2017 at 06:39:27PM +0300, Cyrill Gorcunov wrote: > Since it is possbile to have same number in tfd field (say > file added, closed, then nother file dup'ed to same number > and added back) it is imposible to distinguish such target > files solely by their numbers. > > Strictly speaking regular applications don't need to recognize > these targets at all but for checkpoint/restore sake we need > to collect targets to be able to push them back on restore > stage in a proper order. > > Thus lets add file position, inode and device number where > this target lays. This three fields can be used as a primary > key for sorting, and together with kcmp help CRIU can find > out an exact file target (from the whole set of processes > being checkpointed). > > Signed-off-by: Cyrill Gorcunov Acked-by: Andrei Vagin > CC: Al Viro > CC: Andrew Morton > CC: Andrey Vagin > CC: Pavel Emelyanov > CC: Michael Kerrisk > CC: Jason Baron > CC: Andy Lutomirski > --- > Documentation/filesystems/proc.txt | 6 +++++- > fs/eventpoll.c | 8 ++++++-- > 2 files changed, 11 insertions(+), 3 deletions(-) > > Index: linux-ml.git/Documentation/filesystems/proc.txt > =================================================================== > --- linux-ml.git.orig/Documentation/filesystems/proc.txt > +++ linux-ml.git/Documentation/filesystems/proc.txt > @@ -1779,12 +1779,16 @@ pair provide additional information part > pos: 0 > flags: 02 > mnt_id: 9 > - tfd: 5 events: 1d data: ffffffffffffffff > + tfd: 5 events: 1d data: ffffffffffffffff pos:0 ino:61af sdev:7 > > where 'tfd' is a target file descriptor number in decimal form, > 'events' is events mask being watched and the 'data' is data > associated with a target [see epoll(7) for more details]. > > + The 'pos' is current offset of the target file in decimal form > + [see lseek(2)], 'ino' and 'sdev' are inode and device numbers > + where target file resides, all in hex format. > + > Fsnotify files > ~~~~~~~~~~~~~~ > For inotify files the format is the following > Index: linux-ml.git/fs/eventpoll.c > =================================================================== > --- linux-ml.git.orig/fs/eventpoll.c > +++ linux-ml.git/fs/eventpoll.c > @@ -883,10 +883,14 @@ static void ep_show_fdinfo(struct seq_fi > mutex_lock(&ep->mtx); > for (rbp = rb_first(&ep->rbr); rbp; rbp = rb_next(rbp)) { > struct epitem *epi = rb_entry(rbp, struct epitem, rbn); > + struct inode *inode = file_inode(epi->ffd.file); > > - seq_printf(m, "tfd: %8d events: %8x data: %16llx\n", > + seq_printf(m, "tfd: %8d events: %8x data: %16llx " > + " pos:%lli ino:%lx sdev:%x\n", > epi->ffd.fd, epi->event.events, > - (long long)epi->event.data); > + (long long)epi->event.data, > + (long long)epi->ffd.file->f_pos, > + inode->i_ino, inode->i_sb->s_dev); > if (seq_has_overflowed(m)) > break; > } >