Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3883077imb; Tue, 5 Mar 2019 23:15:19 -0800 (PST) X-Google-Smtp-Source: APXvYqxhD7+HIuGsVYa255OzfsY6zaj4v/VUkwqIyZbg+5DX+nPc6qh7tgB3c9WhrhhS7ym0ohYg X-Received: by 2002:a62:f51d:: with SMTP id n29mr5824341pfh.21.1551856519241; Tue, 05 Mar 2019 23:15:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551856519; cv=none; d=google.com; s=arc-20160816; b=rLPiJ4RIrjnMWdeL5sc7qJsoL/BSSB5Kip+J5PH/lzvfWpPOp4uwzC2VmNRrzdh3Bt GgvQqB+CF94n70OZnBa02TTsV2EkaESQeVXPgJR9rseoEhk7HTav6XHNGeeM34jV4+rX 1B+ordMUmR+4dGxMnUk/iaS+TNDmc+8KDNzeMcnrVPC1Yx7FPYC2svalGy4mJKPswm8g ox9pr2tMhGqQxn1ARCWb8fIHGGogn4U+/PxtzDpPuTjdi8POf41TjxWp9+tL7BjiWfz5 rI7GyYSpNH4/zuIjR9lhI7oYzM55qkHiUkKIV5nyUZKDPBjj2jFOX0VjOQWnG2U0wgPI 6flA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=Hx7e9Om6KWir2y5Jll5K15qRwbmzzWisINZ45fm1GnE=; b=WgpolR1NRtlUe4ETjdo9TBs+PckcG6z6DLg4sQp/1jJhFP0OuSt0OV8aEWHia7736s yK7cgEEiTFmDyaynLjjOMOZfGGI6E71H7cp1b9rT65C0ts2HfISxvwI5iDQl2jyK/6FJ Snma0gJG0V3/OgUMw2HssU+BcZePZF+wazdQ9vRhrjv0995AVheaIG76U7NaoW3w4+Be 2WSnbzJcnNDiyCIJGXQEFA76LHOpWLsQbwjwAxBzl1DBKWvoeSGnQZYUvQ0IV45UkNAA VwGizJYMKMRxhqttqQaO2un84fjvEj9Wty3mt39LRvp1r5yR5wPTW5SFllzZTzrYn5h/ jUWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p2si976573pfi.103.2019.03.05.23.15.04; Tue, 05 Mar 2019 23:15:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729122AbfCFHIK (ORCPT + 99 others); Wed, 6 Mar 2019 02:08:10 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:56696 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726145AbfCFHIK (ORCPT ); Wed, 6 Mar 2019 02:08:10 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 79AF04025FE8; Wed, 6 Mar 2019 07:08:09 +0000 (UTC) Received: from slave.localdomain.com (unknown [10.64.242.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6F6AE111DD03; Wed, 6 Mar 2019 07:08:08 +0000 (UTC) From: Masatake YAMATO To: linux-kernel@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, yamato@redhat.com Subject: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo Date: Wed, 6 Mar 2019 16:08:04 +0900 Message-Id: <20190306070804.31191-1-yamato@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 06 Mar 2019 07:08:09 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 06 Mar 2019 07:08:09 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'yamato@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Finding endpoints of an IPC channel is one of essential task to understand how a user program works. Procfs and netlink socket provide enough hints to find endpoints for IPC channels like pipes, unix sockets, and pseudo terminals. However, there is no simple way to find endpoints for an eventfd file from userland. An inode number doesn't hint. Unlike pipe, all eventfd files share the same inode object. To provide the way to find endpoints of an eventfd file, this patch adds "eventfd-id" field to fdinfo of eventfd as identifier. Address for eventfd context is used as id. Typical applicaiton utilizing the information is lsof. Signed-off-by: Masatake YAMATO --- fs/eventfd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/eventfd.c b/fs/eventfd.c index 08d3bd602f73..fc63ad43d962 100644 --- a/fs/eventfd.c +++ b/fs/eventfd.c @@ -297,6 +297,7 @@ static void eventfd_show_fdinfo(struct seq_file *m, struct file *f) seq_printf(m, "eventfd-count: %16llx\n", (unsigned long long)ctx->count); spin_unlock_irq(&ctx->wqh.lock); + seq_printf(m, "eventfd-id: %p\n", ctx); } #endif -- 2.17.2