On Wed, 20 Mar 2019 18:29:29 +0900 Masatake YAMATO <yam...@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?
