Feature request: reads from inotify file descriptors should decode the struct

[ericonr]

I'm not sure if this is possible with the current infrastructure, and I only looked through the strace code base briefly... But the idea would be to somehow register a file descriptor as having been created by inotify_init/inotify_init1, and then reads from this file descriptor would show the decoded struct inotify_event instead of interpreting it as a string.

[ldv-alt]

On Wed, Oct 06, 2021 at 05:20:37PM -0700, Érico Nogueira Rolim wrote: I'm not sure if this is possible with the current infrastructure, and I only looked through the strace code base briefly... But the idea would be to somehow register a file descriptor as having been created by `inotify_init/inotify_init1`, and then reads from this file descriptor would show the decoded `struct inotify_event` instead of interpreting it as a string.

These descriptors could be identified using readlink of /proc/$pid/fd/$fd, strace already employs this method for other purposes, so yes, this should be technically possible.

[ericonr]

Oh, that sounds great! I will try my hand at implementing it, then. Thanks for the quick answer.

[masatake]

Interesting.

I studied how to store information in /proc/$pid/fdinfo/$fd to the private fields of tcb for decoding ioctl about vfio. My code requires a change to the Linux kernel. So I didn't submit the result of the study to the strace mailing list.
But I wonder my study can help you implement what you want.

When decoding the buffer filled by read(2), you may want to know whether the fd
passed to read(2) is returned from inotify_init or not.
The hint is in the implementation of -y option.
If strace is run with -y option, the information of file descriptor is printed like:

read(3<inotify>, ...

At a quick glance, you can use the information <inotfy>.
However, the current implementation is the information is just printed.
The information is not recorded for the successive decoding processes.

masatake@19bbc9d
This change hooks printfd(), the core of -y option, for recording the information to struct tcb.

struct tcb has a field called priv to store such decoder-specific information.
However, if multiple decoders are involved in decoding one system call, the decoders may conflicts.
So I introduced priv field multiplexer.
masatake@d564e4c

Even if a user doesn't use -y option, you may want to decode the buffer.
So recording fd information and printing fd information should be able to be enabled independently.
For this purpose, I defined enable_tprint/disable_tprint.
masatake@bf6f39c
masatake@19bbc9d

You can find all my changes in "Aug 27, 2021" in https://github.com/masatake/strace/commits/vfio-draft

I hope my study helps you.
NOTE: my changes are not approved by @ldv-alt yet. As I wrote, I didn't submit the changes to the mailing list.

[esyr]

There was some PoC some time ago: 4f72de6 78fd3aa 8015a74