From patchwork Tue Feb 21 16:59:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cyrill Gorcunov X-Patchwork-Id: 9585205 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1B35C600CA for ; Tue, 21 Feb 2017 17:13:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 07F502851A for ; Tue, 21 Feb 2017 17:13:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F0AB928619; Tue, 21 Feb 2017 17:13:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9A8C32851A for ; Tue, 21 Feb 2017 17:13:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753916AbdBURNT (ORCPT ); Tue, 21 Feb 2017 12:13:19 -0500 Received: from mail-lf0-f68.google.com ([209.85.215.68]:36859 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753514AbdBURNR (ORCPT ); Tue, 21 Feb 2017 12:13:17 -0500 Received: by mail-lf0-f68.google.com with SMTP id 90so4147500lfr.3; Tue, 21 Feb 2017 09:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:message-id:user-agent:date:from:to:cc:subject:mime-version :content-disposition; bh=tgnGQslCTZ5xTI5fA0kUfXWYD7pgXrnHViHhK+jKcXc=; b=HJJGIUCuGzwpoYQbGWMWv1Gdt0KqbIRGUck0KX3Ptk/6M9nF6QThcohPecUU+2yShZ U7ick2VDAsn5uN9LQ/XAjQGY8O4NZKeHztqSU48sfEx+mtbJyjPTmbfXnf3TpiDwmcEQ x3EtWqGT+PMIwzy3XnKAqOcub8oXXY+JfoZyQJJg7I3tjpI0lqaFlreAN30v3oDQwFwY LonTQZl9j0iecteOgKxQOaGbfNSQs+1rtto8F+3xiaWWBAwFzYALuTX0nyzsXiwvhYaP zfLsepglAdVwFCVxnd3kcHNW/e4nd9pSGvn95mdh9xshWcLtGvco3/987eHUDhW6bjVR 74kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:message-id:user-agent:date:from:to:cc :subject:mime-version:content-disposition; bh=tgnGQslCTZ5xTI5fA0kUfXWYD7pgXrnHViHhK+jKcXc=; b=hRbk2vpSgW2lE/BfxCdCJds3xYLEd/L/iarIgY2UgLyrxNQHwx9jnZikwdOL3W7rmx 4QFwyU1d+GUdThbV0v2nsefhBVjqoGLZoC9YQJFxk8jJJRPI59YlokRSwbSoc1eyKPER fWM/2Bxsid9R3dUP9ie8LIXh42/tXNPXO3AE+/T+e3+7w1B6TBt6a7pBWcQcnNUun7rU nDAOJuEbBhHYqWTPM4tebzO1JklDc04kltBXHTnltjqWMRP0lIWAxQPFjQYcHa/JW7/C hUz9OELlUDHN1nMm5Jff9wYzOiiDGdw/lz8MsA2UMkTIsDTtUp6jYtHuAwtD48d2D9zN DNjw== X-Gm-Message-State: AMke39lvDkfunJ96f9+3B27IxeQv9ghlNIzD/L4LdTbFEiUHfLqHTahvyGgUVDUMCOG1TA== X-Received: by 10.25.102.10 with SMTP id a10mr8073683lfc.159.1487697195464; Tue, 21 Feb 2017 09:13:15 -0800 (PST) Received: from uranus.localdomain ([5.19.3.67]) by smtp.gmail.com with ESMTPSA id s10sm6270568lja.18.2017.02.21.09.13.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 09:13:14 -0800 (PST) Received: by uranus.localdomain (Postfix, from userid 1000) id 92AFC2486E; Tue, 21 Feb 2017 20:12:55 +0300 (MSK) Message-Id: <20170221171254.954209904@openvz.org> User-Agent: quilt/0.64 Date: Tue, 21 Feb 2017 19:59:45 +0300 From: Cyrill Gorcunov To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Cc: viro@zeniv.linux.org.uk, akpm@linuxfoundation.org, avagin@virtuozzo.com, xemul@virtuozzo.com, mtk.manpages@gmail.com, kir@openvz.org, gorcunov@openvz.org, luto@amacapital.net, jbaron@akamai.com, Andrey Vagin Subject: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files MIME-Version: 1.0 Content-Disposition: inline; filename=epoll-fdinfo-2 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 in 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 CC: Al Viro CC: Andrew Morton CC: Andrey Vagin CC: Pavel Emelyanov CC: Michael Kerrisk CC: Kir Kolyshkin 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; }