From: Jan Kara <jack@suse.cz>
To: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: amir73il@gmail.com, djwong@kernel.org, tytso@mit.edu,
david@fromorbit.com, jack@suse.com, dhowells@redhat.com,
khazhy@google.com, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH v3 07/15] fsnotify: pass arguments of fsnotify() in struct fsnotify_event_info
Date: Thu, 8 Jul 2021 12:43:07 +0200 [thread overview]
Message-ID: <20210708104307.GA1656@quack2.suse.cz> (raw)
In-Reply-To: <20210629191035.681913-8-krisman@collabora.com>
On Tue 29-06-21 15:10:27, Gabriel Krisman Bertazi wrote:
> From: Amir Goldstein <amir73il@gmail.com>
>
> There are a lot of arguments to fsnotify() and the handle_event() method.
> Pass them in a const struct instead of on the argument list.
>
> Apart from being more tidy, this helps with passing error reports to the
> backend. __fsnotify_parent() argument list was intentionally left
> untouched, because its argument list is still short enough and because
> most of the event info arguments are initialized inside
> __fsnotify_parent().
>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
> ---
> fs/notify/fanotify/fanotify.c | 59 +++++++++++------------
> fs/notify/fsnotify.c | 83 +++++++++++++++++---------------
> include/linux/fsnotify.h | 15 ++++--
> include/linux/fsnotify_backend.h | 73 +++++++++++++++++++++-------
> 4 files changed, 140 insertions(+), 90 deletions(-)
Besides the noop function issue Amir has already pointed out I have just a
few nits:
> @@ -229,7 +229,11 @@ int __fsnotify_parent(struct dentry *dentry, __u32 mask, const void *data,
> }
>
> notify:
> - ret = fsnotify(mask, data, data_type, p_inode, file_name, inode, 0);
> + ret = __fsnotify(mask, &(struct fsnotify_event_info) {
> + .data = data, .data_type = data_type,
> + .dir = p_inode, .name = file_name,
> + .inode = inode,
> + });
What's the advantage of using __fsnotify() here instead of fsnotify()? In
terms of readability the fewer places with these initializers the better
I'd say...
> static int fsnotify_handle_event(struct fsnotify_group *group, __u32 mask,
> - const void *data, int data_type,
> - struct inode *dir, const struct qstr *name,
> - u32 cookie, struct fsnotify_iter_info *iter_info)
> + const struct fsnotify_event_info *event_info,
> + struct fsnotify_iter_info *iter_info)
> {
> struct fsnotify_mark *inode_mark = fsnotify_iter_inode_mark(iter_info);
> struct fsnotify_mark *parent_mark = fsnotify_iter_parent_mark(iter_info);
> + struct fsnotify_event_info child_event_info = { };
> int ret;
No need to init child_event_info. It is fully rewritten if it gets used...
> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> index f8acddcf54fb..8c2c681b4495 100644
> --- a/include/linux/fsnotify.h
> +++ b/include/linux/fsnotify.h
> @@ -30,7 +30,10 @@ static inline void fsnotify_name(struct inode *dir, __u32 mask,
> struct inode *child,
> const struct qstr *name, u32 cookie)
> {
> - fsnotify(mask, child, FSNOTIFY_EVENT_INODE, dir, name, NULL, cookie);
> + __fsnotify(mask, &(struct fsnotify_event_info) {
> + .data = child, .data_type = FSNOTIFY_EVENT_INODE,
> + .dir = dir, .name = name, .cookie = cookie,
> + });
> }
Hmm, maybe we could have a macro initializer like:
#define FSNOTIFY_EVENT_INFO(data, data_type, dir, name, inode, cookie) \
(struct fsnotify_event_info) { \
.data = (data), .data_type = (data_type), .dir = (dir), \
.name = (name), .inode = (inode), .cookie = (cookie)}
Then we'd have:
__fsnotify(mask, &FSNOTIFY_EVENT_INFO(child, FSNOTIFY_EVENT_INODE,
dir, name, NULL, cookie));
Which looks a bit nicer to me. What do you think guys?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-07-08 10:43 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 19:10 [PATCH v3 00/15] File system wide monitoring Gabriel Krisman Bertazi
2021-06-29 19:10 ` [PATCH v3 01/15] fsnotify: Don't insert unmergeable events in hashtable Gabriel Krisman Bertazi
2021-06-30 3:12 ` Amir Goldstein
2021-07-07 19:21 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 02/15] fanotify: Fold event size calculation to its own function Gabriel Krisman Bertazi
2021-07-07 19:22 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 03/15] fanotify: Split fsid check from other fid mode checks Gabriel Krisman Bertazi
2021-06-30 3:14 ` Amir Goldstein
2021-07-07 19:24 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 04/15] fanotify: Split superblock marks out to a new cache Gabriel Krisman Bertazi
2021-06-30 3:17 ` Amir Goldstein
2021-07-07 20:13 ` Jan Kara
2021-07-08 6:16 ` Amir Goldstein
2021-06-29 19:10 ` [PATCH v3 05/15] inotify: Don't force FS_IN_IGNORED Gabriel Krisman Bertazi
2021-07-07 19:37 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 06/15] fsnotify: Add helper to detect overflow_event Gabriel Krisman Bertazi
2021-07-07 20:14 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 07/15] fsnotify: pass arguments of fsnotify() in struct fsnotify_event_info Gabriel Krisman Bertazi
2021-06-29 20:39 ` kernel test robot
2021-06-30 0:10 ` kernel test robot
2021-06-30 3:29 ` Amir Goldstein
2021-06-30 8:11 ` Dan Carpenter
2021-06-30 8:35 ` Amir Goldstein
2021-06-30 8:45 ` Dan Carpenter
2021-06-30 9:32 ` Amir Goldstein
2021-06-30 9:34 ` Amir Goldstein
2021-06-30 10:49 ` Dan Carpenter
2021-06-30 12:51 ` Amir Goldstein
2021-07-08 10:43 ` Jan Kara [this message]
2021-07-08 11:09 ` Amir Goldstein
2021-07-08 11:37 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 08/15] fsnotify: Support passing argument to insert callback on add_event Gabriel Krisman Bertazi
2021-06-30 3:40 ` Amir Goldstein
2021-07-08 10:48 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 09/15] fsnotify: Always run the merge hook Gabriel Krisman Bertazi
2021-06-30 3:42 ` Amir Goldstein
2021-06-29 19:10 ` [PATCH v3 10/15] fsnotify: Support FS_ERROR event type Gabriel Krisman Bertazi
2021-07-08 10:53 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 11/15] fsnotify: Introduce helpers to send error_events Gabriel Krisman Bertazi
2021-06-30 3:44 ` Amir Goldstein
2021-07-08 11:02 ` Jan Kara
2021-06-29 19:10 ` [PATCH v3 12/15] fanotify: Introduce FAN_FS_ERROR event Gabriel Krisman Bertazi
2021-06-30 10:26 ` Amir Goldstein
2021-06-30 17:43 ` Gabriel Krisman Bertazi
2021-07-01 6:37 ` Amir Goldstein
2021-06-30 14:03 ` Amir Goldstein
2021-06-29 19:10 ` [PATCH v3 13/15] ext4: Send notifications on error Gabriel Krisman Bertazi
2021-06-29 19:10 ` [PATCH v3 14/15] samples: Add fs error monitoring example Gabriel Krisman Bertazi
2021-06-30 2:42 ` kernel test robot
2021-07-19 14:36 ` Gabriel Krisman Bertazi
2021-07-20 19:49 ` Dan Carpenter
2021-07-22 12:54 ` Chen, Rong A
2021-07-22 16:15 ` Gabriel Krisman Bertazi
2021-07-23 1:35 ` Chen, Rong A
2021-06-30 3:46 ` kernel test robot
2021-06-30 3:58 ` Amir Goldstein
2021-06-29 19:10 ` [PATCH v3 15/15] docs: Document the FAN_FS_ERROR event Gabriel Krisman Bertazi
2021-06-30 4:18 ` Amir Goldstein
2021-06-30 5:10 ` [PATCH v3 00/15] File system wide monitoring Amir Goldstein
2021-07-08 11:32 ` Jan Kara
2021-07-08 12:25 ` Amir Goldstein
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=20210708104307.GA1656@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=jack@suse.com \
--cc=kernel@collabora.com \
--cc=khazhy@google.com \
--cc=krisman@collabora.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/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).