From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 6/7] fanotify: mix event info into merge key hash
Date: Tue, 16 Feb 2021 16:39:44 +0100 [thread overview]
Message-ID: <20210216153943.GD21108@quack2.suse.cz> (raw)
In-Reply-To: <20210202162010.305971-7-amir73il@gmail.com>
On Tue 02-02-21 18:20:09, Amir Goldstein wrote:
> Improve the balance of hashed queue lists by mixing more event info
> relevant for merge.
>
> For example, all FAN_CREATE name events in the same dir used to have the
> same merge key based on the dir inode. With this change the created
> file name is mixed into the merge key.
>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
> fs/notify/fanotify/fanotify.c | 33 +++++++++++++++++++++++++++------
> fs/notify/fanotify/fanotify.h | 20 +++++++++++++++++---
> 2 files changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 6d3807012851..b19fef1c6f64 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
...
> @@ -476,8 +485,11 @@ static struct fanotify_event *fanotify_alloc_fid_event(struct inode *id,
>
> ffe->fae.type = FANOTIFY_EVENT_TYPE_FID;
> ffe->fsid = *fsid;
> - fanotify_encode_fh(&ffe->object_fh, id, fanotify_encode_fh_len(id),
> - gfp);
> + fh = &ffe->object_fh;
> + fanotify_encode_fh(fh, id, fanotify_encode_fh_len(id), gfp);
> +
> + /* Mix fsid+fid info into event merge key */
> + ffe->fae.info_hash = full_name_hash(ffe->fskey, fanotify_fh_buf(fh), fh->len);
Is it really sensible to hash FID with full_name_hash()? It would make more
sense to treat it as binary data, not strings...
> return &ffe->fae;
> }
> @@ -517,6 +529,9 @@ static struct fanotify_event *fanotify_alloc_name_event(struct inode *id,
> if (file_name)
> fanotify_info_copy_name(info, file_name);
>
> + /* Mix fsid+dfid+name+fid info into event merge key */
> + fne->fae.info_hash = full_name_hash(fne->fskey, info->buf, fanotify_info_len(info));
> +
Similarly here...
> pr_debug("%s: ino=%lu size=%u dir_fh_len=%u child_fh_len=%u name_len=%u name='%.*s'\n",
> __func__, id->i_ino, size, dir_fh_len, child_fh_len,
> info->name_len, info->name_len, fanotify_info_name(info));
> @@ -539,6 +554,8 @@ static struct fanotify_event *fanotify_alloc_event(struct fsnotify_group *group,
> struct mem_cgroup *old_memcg;
> struct inode *child = NULL;
> bool name_event = false;
> + unsigned int hash = 0;
> + struct pid *pid;
>
> if ((fid_mode & FAN_REPORT_DIR_FID) && dirid) {
> /*
> @@ -606,13 +623,17 @@ static struct fanotify_event *fanotify_alloc_event(struct fsnotify_group *group,
> * Use the victim inode instead of the watching inode as the id for
> * event queue, so event reported on parent is merged with event
> * reported on child when both directory and child watches exist.
> - * Reduce object id to 32bit hash for hashed queue merge.
> + * Reduce object id and event info to 32bit hash for hashed queue merge.
> */
> - fanotify_init_event(event, hash_ptr(id, 32), mask);
> + hash = event->info_hash ^ hash_ptr(id, 32);
> if (FAN_GROUP_FLAG(group, FAN_REPORT_TID))
> - event->pid = get_pid(task_pid(current));
> + pid = get_pid(task_pid(current));
> else
> - event->pid = get_pid(task_tgid(current));
> + pid = get_pid(task_tgid(current));
> + /* Mix pid info into event merge key */
> + hash ^= hash_ptr(pid, 32);
hash_32() here?
> + fanotify_init_event(event, hash, mask);
> + event->pid = pid;
>
> out:
> set_active_memcg(old_memcg);
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index 2e856372ffc8..522fb1a68b30 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -115,6 +115,11 @@ static inline void fanotify_info_init(struct fanotify_info *info)
> info->name_len = 0;
> }
>
> +static inline unsigned int fanotify_info_len(struct fanotify_info *info)
> +{
> + return info->dir_fh_totlen + info->file_fh_totlen + info->name_len;
> +}
> +
> static inline void fanotify_info_copy_name(struct fanotify_info *info,
> const struct qstr *name)
> {
> @@ -138,7 +143,10 @@ enum fanotify_event_type {
> };
>
> struct fanotify_event {
> - struct fsnotify_event fse;
> + union {
> + struct fsnotify_event fse;
> + unsigned int info_hash;
> + };
> u32 mask;
> enum fanotify_event_type type;
> struct pid *pid;
How is this ever safe? info_hash will likely overlay with 'list' in
fsnotify_event.
> @@ -154,7 +162,10 @@ static inline void fanotify_init_event(struct fanotify_event *event,
>
> struct fanotify_fid_event {
> struct fanotify_event fae;
> - __kernel_fsid_t fsid;
> + union {
> + __kernel_fsid_t fsid;
> + void *fskey; /* 64 or 32 bits of fsid used for salt */
> + };
> struct fanotify_fh object_fh;
> /* Reserve space in object_fh.buf[] - access with fanotify_fh_buf() */
> unsigned char _inline_fh_buf[FANOTIFY_INLINE_FH_LEN];
> @@ -168,7 +179,10 @@ FANOTIFY_FE(struct fanotify_event *event)
>
> struct fanotify_name_event {
> struct fanotify_event fae;
> - __kernel_fsid_t fsid;
> + union {
> + __kernel_fsid_t fsid;
> + void *fskey; /* 64 or 32 bits of fsid used for salt */
> + };
> struct fanotify_info info;
> };
What games are you playing here with the unions? I presume you can remove
these 'fskey' unions and just use (void *)(event->fsid) at appropriate
places? IMO much more comprehensible...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-02-16 15:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 16:20 [PATCH 0/7] Performance improvement for fanotify merge Amir Goldstein
2021-02-02 16:20 ` [PATCH 1/7] fsnotify: allow fsnotify_{peek,remove}_first_event with empty queue Amir Goldstein
2021-02-02 16:20 ` [PATCH 2/7] fsnotify: support hashed notification queue Amir Goldstein
2021-02-16 15:02 ` Jan Kara
2021-02-17 12:33 ` Amir Goldstein
2021-02-17 13:48 ` Jan Kara
2021-02-17 15:42 ` Amir Goldstein
2021-02-17 16:49 ` Jan Kara
2021-02-18 10:52 ` Amir Goldstein
2021-02-02 16:20 ` [PATCH 3/7] fsnotify: read events from hashed notification queue by order of insertion Amir Goldstein
2021-02-16 15:10 ` Jan Kara
2021-02-02 16:20 ` [PATCH 4/7] fanotify: enable hashed notification queue for FAN_CLASS_NOTIF groups Amir Goldstein
2021-02-02 16:20 ` [PATCH 5/7] fanotify: limit number of event merge attempts Amir Goldstein
2021-02-27 8:31 ` Amir Goldstein
2021-03-01 13:08 ` Jan Kara
2021-03-01 13:58 ` Amir Goldstein
2021-09-15 12:39 ` Amir Goldstein
2021-09-15 16:33 ` Jan Kara
2021-02-02 16:20 ` [PATCH 6/7] fanotify: mix event info into merge key hash Amir Goldstein
2021-02-16 15:39 ` Jan Kara [this message]
2021-02-17 10:13 ` Amir Goldstein
2021-02-18 10:46 ` Amir Goldstein
2021-02-18 11:11 ` Jan Kara
2021-02-18 12:17 ` Amir Goldstein
2021-02-02 16:20 ` [PATCH 7/7] fsnotify: print some debug stats on hashed queue overflow Amir Goldstein
2021-02-16 16:02 ` [PATCH 0/7] Performance improvement for fanotify merge Jan Kara
2021-02-17 10:52 ` Amir Goldstein
2021-02-17 11:25 ` Jan Kara
2021-02-18 10:56 ` Amir Goldstein
2021-02-18 11:15 ` Jan Kara
2021-02-18 12:35 ` Amir Goldstein
2021-02-19 10:15 ` Jan Kara
2021-02-19 10:21 ` Jan Kara
2021-02-19 13:38 ` Amir Goldstein
2021-02-21 12:53 ` Amir Goldstein
2021-02-22 9:29 ` Jan Kara
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=20210216153943.GD21108@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).