Messages in this thread | | | From | David Howells <> | Subject | Re: [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications | Date | Tue, 04 Jun 2019 13:33:01 +0100 |
| |
Amir Goldstein <amir73il@gmail.com> wrote:
> Well I am sure that ring buffer for fanotify events would be useful, so > seeing that David is proposing a generic notification mechanism, I wanted > to know how that mechanism could best share infrastructure with fsnotify. > > But apart from that I foresee the questions from users about why the > mount notification API and filesystem events API do not have better > integration. > > The way I see it, the notification queue can serve several classes > of notifications and fsnotify could be one of those classes > (at least FAN_CLASS_NOTIF fits nicely to the model).
It could be done; the main thing that concerns me is that the buffer is of limited capacity.
However, I could take this:
struct fanotify_event_metadata { __u32 event_len; __u8 vers; __u8 reserved; __u16 metadata_len; __aligned_u64 mask; __s32 fd; __s32 pid; };
and map it to:
struct fanotify_notification { struct watch_notification watch; /* WATCH_TYPE_FANOTIFY */ __aligned_u64 mask; __u16 metadata_len; __u8 vers; __u8 reserved; __u32 reserved2; __s32 fd; __s32 pid; };
and some of the watch::info bit could be used:
n->watch.info & WATCH_INFO_OVERRUN watch queue overran n->watch.info & WATCH_INFO_LENGTH event_len n->watch.info & WATCH_INFO_RECURSIVE FAN_EVENT_ON_CHILD n->watch.info & WATCH_INFO_FLAG_0 FAN_*_PERM n->watch.info & WATCH_INFO_FLAG_1 FAN_Q_OVERFLOW n->watch.info & WATCH_INFO_FLAG_2 FAN_ON_DIR n->subtype ffs(n->mask)
Ideally, I'd dispense with metadata_len, vers, reserved* and set the version when setting the watch.
fanotify_watch(int watchfd, unsigned int flags, u64 *mask, int dirfd, const char *pathname, unsigned int at_flags);
We might also want to extend the watch_filter to allow you to, say, filter on the first __u64 after the watch member so that you could filter on specific events:
struct watch_notification_type_filter { __u32 type; __u32 info_filter; __u32 info_mask; __u32 subtype_filter[8]; __u64 payload_mask[1]; __u64 payload_set[1]; };
So, in this case, it would require:
n->mask & wf->payload_mask[0] == wf->payload_set[0]
to be true to record the message.
David
| |