From: David Howells <dhowells@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: dhowells@redhat.com, Jan Kara <jack@suse.cz>,
Al Viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-api@vger.kernel.org,
linux-block <linux-block@vger.kernel.org>,
keyrings@vger.kernel.org,
LSM List <linux-security-module@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications
Date: Tue, 04 Jun 2019 13:33:01 +0100 [thread overview]
Message-ID: <16167.1559651581@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAOQ4uxjLzURf8c1UH_xCJKkuD2es8i-=P-ZNM=t3aFcZLMwXEg@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: dhowells@redhat.com, Jan Kara <jack@suse.cz>,
Al Viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-api@vger.kernel.org,
linux-block <linux-block@vger.kernel.org>,
keyrings@vger.kernel.org,
LSM List <linux-security-module@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications
Date: Tue, 04 Jun 2019 12:33:01 +0000 [thread overview]
Message-ID: <16167.1559651581@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAOQ4uxjLzURf8c1UH_xCJKkuD2es8i-=P-ZNM=t3aFcZLMwXEg@mail.gmail.com>
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
next prev parent reply other threads:[~2019-06-04 12:33 UTC|newest]
Thread overview: 131+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-28 16:01 [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications David Howells
2019-05-28 16:01 ` David Howells
2019-05-28 16:01 ` [PATCH 1/7] General notification queue with user mmap()'able ring buffer David Howells
2019-05-28 16:01 ` David Howells
2019-05-28 16:26 ` Greg KH
2019-05-28 16:26 ` Greg KH
2019-05-28 17:30 ` David Howells
2019-05-28 17:30 ` David Howells
2019-05-28 23:12 ` Greg KH
2019-05-28 23:12 ` Greg KH
2019-05-29 16:06 ` David Howells
2019-05-29 16:06 ` David Howells
2019-05-29 17:46 ` Jann Horn
2019-05-29 17:46 ` Jann Horn
2019-05-29 21:02 ` David Howells
2019-05-29 21:02 ` David Howells
2019-05-31 11:14 ` Peter Zijlstra
2019-05-31 11:14 ` Peter Zijlstra
2019-05-31 12:02 ` David Howells
2019-05-31 12:02 ` David Howells
2019-05-31 13:26 ` Peter Zijlstra
2019-05-31 13:26 ` Peter Zijlstra
2019-05-31 14:20 ` David Howells
2019-05-31 14:20 ` David Howells
2019-05-31 16:44 ` Peter Zijlstra
2019-05-31 16:44 ` Peter Zijlstra
2019-05-31 17:12 ` David Howells
2019-05-31 17:12 ` David Howells
2019-06-17 16:24 ` Peter Zijlstra
2019-06-17 16:24 ` Peter Zijlstra
2019-05-29 23:09 ` Greg KH
2019-05-29 23:09 ` Greg KH
2019-05-29 23:11 ` Greg KH
2019-05-29 23:11 ` Greg KH
2019-05-30 9:50 ` Andrea Parri
2019-05-30 9:50 ` Andrea Parri
2019-05-31 8:35 ` Peter Zijlstra
2019-05-31 8:35 ` Peter Zijlstra
2019-05-31 8:47 ` Peter Zijlstra
2019-05-31 8:47 ` Peter Zijlstra
2019-05-31 12:42 ` David Howells
2019-05-31 12:42 ` David Howells
2019-05-31 14:55 ` David Howells
2019-05-31 14:55 ` David Howells
2019-05-28 19:14 ` Jann Horn
2019-05-28 19:14 ` Jann Horn
2019-05-28 22:28 ` David Howells
2019-05-28 22:28 ` David Howells
2019-05-28 23:16 ` Jann Horn
2019-05-28 23:16 ` Jann Horn
2019-05-28 16:02 ` [PATCH 2/7] keys: Add a notification facility David Howells
2019-05-28 16:02 ` David Howells
2019-05-28 16:02 ` [PATCH 3/7] vfs: Add a mount-notification facility David Howells
2019-05-28 16:02 ` David Howells
2019-05-28 20:06 ` Jann Horn
2019-05-28 20:06 ` Jann Horn
2019-05-28 23:04 ` David Howells
2019-05-28 23:04 ` David Howells
2019-05-28 23:23 ` Jann Horn
2019-05-28 23:23 ` Jann Horn
2019-05-29 11:16 ` David Howells
2019-05-29 11:16 ` David Howells
2019-05-28 23:08 ` David Howells
2019-05-28 23:08 ` David Howells
2019-05-29 10:55 ` David Howells
2019-05-29 10:55 ` David Howells
2019-05-29 11:00 ` David Howells
2019-05-29 11:00 ` David Howells
2019-05-29 15:53 ` Casey Schaufler
2019-05-29 15:53 ` Casey Schaufler
2019-05-29 16:12 ` Jann Horn
2019-05-29 16:12 ` Jann Horn
2019-05-29 17:04 ` Casey Schaufler
2019-05-29 17:04 ` Casey Schaufler
2019-06-03 16:30 ` David Howells
2019-06-03 16:30 ` David Howells
2019-05-29 17:13 ` Andy Lutomirski
2019-05-29 17:13 ` Andy Lutomirski
2019-05-29 17:46 ` Casey Schaufler
2019-05-29 17:46 ` Casey Schaufler
2019-05-29 18:11 ` Jann Horn
2019-05-29 18:11 ` Jann Horn
2019-05-29 19:28 ` Casey Schaufler
2019-05-29 19:28 ` Casey Schaufler
2019-05-29 19:47 ` Jann Horn
2019-05-29 19:47 ` Jann Horn
2019-05-29 20:50 ` Casey Schaufler
2019-05-29 20:50 ` Casey Schaufler
2019-05-29 23:12 ` Andy Lutomirski
2019-05-29 23:12 ` Andy Lutomirski
2019-05-29 23:56 ` Casey Schaufler
2019-05-29 23:56 ` Casey Schaufler
2019-05-28 16:02 ` [PATCH 4/7] vfs: Add superblock notifications David Howells
2019-05-28 16:02 ` David Howells
2019-05-28 20:27 ` Jann Horn
2019-05-28 20:27 ` Jann Horn
2019-05-29 12:58 ` David Howells
2019-05-29 12:58 ` David Howells
2019-05-29 14:16 ` Jann Horn
2019-05-29 14:16 ` Jann Horn
2019-05-28 16:02 ` [PATCH 5/7] fsinfo: Export superblock notification counter David Howells
2019-05-28 16:02 ` David Howells
2019-05-28 16:02 ` [PATCH 6/7] block: Add block layer notifications David Howells
2019-05-28 16:02 ` David Howells
2019-05-28 20:37 ` Jann Horn
2019-05-28 20:37 ` Jann Horn
2019-05-28 16:02 ` [PATCH 7/7] Add sample notification program David Howells
2019-05-28 16:02 ` David Howells
2019-05-28 23:58 ` [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications Greg KH
2019-05-28 23:58 ` Greg KH
2019-05-29 6:33 ` Amir Goldstein
2019-05-29 6:33 ` Amir Goldstein
2019-05-29 6:33 ` Amir Goldstein
2019-05-29 14:25 ` Jan Kara
2019-05-29 14:25 ` Jan Kara
2019-05-29 15:10 ` Greg KH
2019-05-29 15:10 ` Greg KH
2019-05-29 15:53 ` Amir Goldstein
2019-05-29 15:53 ` Amir Goldstein
2019-05-30 11:00 ` Jan Kara
2019-05-30 11:00 ` Jan Kara
2019-06-04 12:33 ` David Howells [this message]
2019-06-04 12:33 ` David Howells
2019-05-29 6:45 ` David Howells
2019-05-29 6:45 ` David Howells
2019-05-29 7:40 ` Amir Goldstein
2019-05-29 7:40 ` Amir Goldstein
2019-05-29 9:09 ` David Howells
2019-05-29 9:09 ` David Howells
2019-05-29 15:41 ` Casey Schaufler
2019-05-29 15:41 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16167.1559651581@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=raven@themaw.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.