[PATCH RESEND] eventfd: prepare id to userspace via fdinfo

[PATCH RESEND] eventfd: prepare id to userspace via fdinfo

[Masatake 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

[PATCH RESEND] eventfd: prepare id to userspace via fdinfo

[Masatake 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

[PATCH RESEND] eventfd: prepare id to userspace via fdinfo

[Masatake 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

Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo

[Andrew Morton]

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?

Re: [PATCH RESEND] eventfd: prepare id to userspace via fdinfo

[Masatake YAMATO]

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