Linux-Fsdevel Archive on lore.kernel.org
 help / Atom feed
* [PATCH RESEND] eventfd: prepare id to userspace via fdinfo
@ 2019-02-05 11:46 Masatake YAMATO
  0 siblings, 0 replies; 5+ messages in thread
From: Masatake YAMATO @ 2019-02-05 11:46 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-fsdevel, yamato

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 <yamato@redhat.com>
---
 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo
  2019-03-20 19:05 ` Andrew Morton
@ 2019-03-21  3:37   ` Masatake YAMATO
  0 siblings, 0 replies; 5+ messages in thread
From: Masatake YAMATO @ 2019-03-21  3:37 UTC (permalink / raw)
  To: akpm; +Cc: linux-kernel, viro, linux-fsdevel, keescook

Thank you for the comment.

On Wed, 20 Mar 2019 12:05:25 -0700, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 20 Mar 2019 18:29:29 +0900 Masatake YAMATO <yamato@redhat.com> wrote:
> 
>> 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 /proc/PID/fdinfo of eventfd as identifier.
>> Address for eventfd context is used as id.
>> 
>> A tool like lsof can utilize the information to print endpoints.
>> 
>> ...
>>
>> --- 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
> 
> Is it a good idea to use a bare kernel address for this?  How does this
> interact with printk pointer randomization and hashing?
> 

My understanding is that an address printed with %p for a bare kernel
address is stable after ptr_key in vsprintf.c is filled, and ptr_key
is filled enough early stage. so, for my usecase, resolving IPC endpoints,
printing a bare kernel address with %p may be enough. Am I missing something?

For the same purpose, I submitted a ida based patch a year ago.
(https://patchwork.kernel.org/patch/10413589/)
I quote it here for getting comments:

This one doesn't use any bare kernel addresses. I implemented new one (%p version)
bacause is is much shorter.

Do you think ida based one is better than %p based one?

Masatake YAMATO

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo
  2019-03-20  9:29 Masatake YAMATO
@ 2019-03-20 19:05 ` Andrew Morton
  2019-03-21  3:37   ` Masatake YAMATO
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2019-03-20 19:05 UTC (permalink / raw)
  To: Masatake YAMATO; +Cc: linux-kernel, viro, linux-fsdevel, Kees Cook

On Wed, 20 Mar 2019 18:29:29 +0900 Masatake YAMATO <yamato@redhat.com> wrote:

> 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 /proc/PID/fdinfo of eventfd as identifier.
> Address for eventfd context is used as id.
> 
> A tool like lsof can utilize the information to print endpoints.
> 
> ...
>
> --- 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

Is it a good idea to use a bare kernel address for this?  How does this
interact with printk pointer randomization and hashing?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH RESEND] eventfd: prepare id to userspace via fdinfo
@ 2019-03-20  9:29 Masatake YAMATO
  2019-03-20 19:05 ` Andrew Morton
  0 siblings, 1 reply; 5+ messages in thread
From: Masatake YAMATO @ 2019-03-20  9:29 UTC (permalink / raw)
  To: linux-kernel, viro, akpm; +Cc: linux-fsdevel, yamato

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 /proc/PID/fdinfo of eventfd as identifier.
Address for eventfd context is used as id.

A tool like lsof can utilize the information to print endpoints.

Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH RESEND] eventfd: prepare id to userspace via fdinfo
@ 2019-03-06  7:08 Masatake YAMATO
  0 siblings, 0 replies; 5+ messages in thread
From: Masatake YAMATO @ 2019-03-06  7:08 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-fsdevel, yamato

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 <yamato@redhat.com>
---
 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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-05 11:46 [PATCH RESEND] eventfd: prepare id to userspace via fdinfo Masatake YAMATO
2019-03-06  7:08 Masatake YAMATO
2019-03-20  9:29 Masatake YAMATO
2019-03-20 19:05 ` Andrew Morton
2019-03-21  3:37   ` Masatake YAMATO

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org linux-fsdevel@archiver.kernel.org
	public-inbox-index linux-fsdevel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox