lkml.org 
[lkml]   [2019]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications
    Date
    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

    \
     
     \ /
      Last update: 2019-06-04 14:34    [W:2.106 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site