| Message ID | 20190320092929.14628-1-yamato@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RESEND] eventfd: prepare id to userspace via fdinfo | expand |
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?
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
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
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(+)