All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>,
	Jan Kara <jack@suse.com>, "Darrick J. Wong" <djwong@kernel.org>,
	Theodore Tso <tytso@mit.edu>, David Howells <dhowells@redhat.com>,
	Khazhismel Kumykov <khazhy@google.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Ext4 <linux-ext4@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Matthew Bobrowski <repnop@google.com>,
	kernel@collabora.com
Subject: Re: [PATCH v7 23/28] fanotify: Report fid info for file related file system errors
Date: Fri, 15 Oct 2021 15:38:11 +0200	[thread overview]
Message-ID: <20211015133811.GO23102@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxgR9jGSyGoHvDEPpSpMVHGssnkXJJ5a8HRKD6nxMyMLmA@mail.gmail.com>

On Fri 15-10-21 10:56:38, Amir Goldstein wrote:
> On Fri, Oct 15, 2021 at 12:39 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
> >
> > Plumb the pieces to add a FID report to error records.  Since all error
> > event memory must be pre-allocated, we pre-allocate the maximum file
> > handle size possible, such that it should always fit.
> >
> > For errors that don't expose a file handle report it with an invalid
> > FID.
> >
> > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
> >
> > ---
> > Changes since v6:
> >   - pass fsid from handle_events
> > Changes since v5:
> >   - Use preallocated MAX_HANDLE_SZ FH buffer
> >   - Report superblock errors with a zerolength INVALID FID (jan, amir)
> > ---
> >  fs/notify/fanotify/fanotify.c | 15 +++++++++++++++
> >  fs/notify/fanotify/fanotify.h |  8 ++++++++
> >  2 files changed, 23 insertions(+)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 7032083df62a..8a60c96f5fb2 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -611,7 +611,9 @@ static struct fanotify_event *fanotify_alloc_error_event(
> >  {
> >         struct fs_error_report *report =
> >                         fsnotify_data_error_report(data, data_type);
> > +       struct inode *inode = report->inode;
> >         struct fanotify_error_event *fee;
> > +       int fh_len;
> >
> >         if (WARN_ON(!report))
> >                 return NULL;
> > @@ -622,6 +624,19 @@ static struct fanotify_event *fanotify_alloc_error_event(
> >
> >         fee->fae.type = FANOTIFY_EVENT_TYPE_FS_ERROR;
> >         fee->err_count = 1;
> > +       fee->fsid = *fsid;
> > +
> > +       fh_len = fanotify_encode_fh_len(inode);
> > +       if (WARN_ON(fh_len > MAX_HANDLE_SZ)) {
> 
> WARN_ON_ONCE please and I rather that this sanity check is moved inside
> fanotify_encode_fh_len() where it will return 0 for encoding failure.

Yeah, that's better.

> > diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> > index 2b032b79d5b0..b58400926f92 100644
> > --- a/fs/notify/fanotify/fanotify.h
> > +++ b/fs/notify/fanotify/fanotify.h
> > @@ -202,6 +202,10 @@ struct fanotify_error_event {
> >         u32 err_count; /* Suppressed errors count */
> >
> >         __kernel_fsid_t fsid; /* FSID this error refers to. */
> > +       /* object_fh must be followed by the inline handle buffer. */
> > +       struct fanotify_fh object_fh;
> > +       /* Reserve space in object_fh.buf[] - access with fanotify_fh_buf() */
> > +       unsigned char _inline_fh_buf[MAX_HANDLE_SZ];
> >  };
> 
> This struct duplicates most of struct fanotify_fid_event.
> How about:
> 
> #define FANOTIFY_ERROR_FH_LEN \
>              (MAX_HANDLE_SZ - FANOTIFY_INLINE_FH_LEN)
> 
> struct fanotify_error_event {
>          u32 err_count; /* Suppressed errors count */
>          struct fanotify_event ffe;
>          /* Reserve space in ffe.object_fh.buf[] - access with
> fanotify_fh_buf() */
>          unsigned char _fh_buf[FANOTIFY_ERROR_FH_LEN];
> }
> 
> Or leaving out the struct padding and passing
> FANOTIFY_ERROR_EVENT_SIZE as mempool object size?
> 
> #define FANOTIFY_ERROR_EVENT_SIZE \
>             (sizeof(struct fanotify_error_event) + FANOTIFY_ERROR_FH_LEN)

Hrm, I don't like either of these two options too much as IMHO it's rather
hard to understand what's going on. If we want to avoid the duplication,
then I see two relatively clean ways to do it:

a) Remove _inline_fh_buf from fanotify_fid_event (probably just leave a
comment there explaining how space is preallocated) and make sure kmem
cache for fanotify_fid_event has FANOTIFY_INLINE_FH_LEN in each object for
the fh, similarly error event would have MAX_HANDLE_SZ in the object.

b) Define a macro that expands to a struct definition with appropriate
buffer length.

I guess a) seems a bit more obvious to me but I can live with both...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2021-10-15 13:38 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 21:36 [PATCH v7 00/28] file system-wide error monitoring Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 01/28] fsnotify: pass data_type to fsnotify_name() Gabriel Krisman Bertazi
2021-10-15  9:18   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 02/28] fsnotify: pass dentry instead of inode data Gabriel Krisman Bertazi
2021-10-15 13:39   ` Jan Kara
2021-10-18  9:11   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 03/28] fsnotify: clarify contract for create event hooks Gabriel Krisman Bertazi
2021-10-15  9:21   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 04/28] fsnotify: Don't insert unmergeable events in hashtable Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 05/28] fanotify: Fold event size calculation to its own function Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 06/28] fanotify: Split fsid check from other fid mode checks Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 07/28] inotify: Don't force FS_IN_IGNORED Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 08/28] fsnotify: Add helper to detect overflow_event Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 09/28] fsnotify: Add wrapper around fsnotify_add_event Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 10/28] fsnotify: Retrieve super block from the data field Gabriel Krisman Bertazi
2021-10-15  5:39   ` Amir Goldstein
2021-10-15  9:26   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 11/28] fsnotify: Pass group argument to free_event Gabriel Krisman Bertazi
2021-10-15  5:40   ` Amir Goldstein
2021-10-15  9:26   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 12/28] fanotify: Support null inode event in fanotify_dfid_inode Gabriel Krisman Bertazi
2021-10-15  5:49   ` Amir Goldstein
2021-10-15  9:30   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 13/28] fanotify: Allow file handle encoding for unhashed events Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 14/28] fanotify: Encode empty file handle when no inode is provided Gabriel Krisman Bertazi
2021-10-15  6:02   ` Amir Goldstein
2021-10-15  9:32   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 15/28] fanotify: Require fid_mode for any non-fd event Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 16/28] fsnotify: Support FS_ERROR event type Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 17/28] fanotify: Reserve UAPI bits for FAN_FS_ERROR Gabriel Krisman Bertazi
2021-10-15  9:37   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 18/28] fanotify: Pre-allocate pool of error events Gabriel Krisman Bertazi
2021-10-15  6:19   ` Amir Goldstein
2021-10-15  7:33     ` Amir Goldstein
2021-10-15  9:46   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 19/28] fanotify: Limit number of marks with FAN_FS_ERROR per group Gabriel Krisman Bertazi
2021-10-15  6:15   ` Amir Goldstein
2021-10-15 16:53     ` Gabriel Krisman Bertazi
2021-10-15 17:49       ` Amir Goldstein
2021-10-14 21:36 ` [PATCH v7 20/28] fanotify: Support enqueueing of error events Gabriel Krisman Bertazi
2021-10-15  7:04   ` Amir Goldstein
2021-10-15 16:50     ` Gabriel Krisman Bertazi
2021-10-15 12:34   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 21/28] fanotify: Support merging " Gabriel Krisman Bertazi
2021-10-15  7:09   ` Amir Goldstein
2021-10-15 16:54     ` Gabriel Krisman Bertazi
2021-10-15 17:52       ` Amir Goldstein
2021-10-18 13:55         ` Gabriel Krisman Bertazi
2021-10-15 12:43   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 22/28] fanotify: Report FID entry even for zero-length file_handle Gabriel Krisman Bertazi
2021-10-15  8:10   ` Amir Goldstein
2021-10-15 13:13     ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 23/28] fanotify: Report fid info for file related file system errors Gabriel Krisman Bertazi
2021-10-15  7:56   ` Amir Goldstein
2021-10-15 13:38     ` Jan Kara [this message]
2021-10-14 21:36 ` [PATCH v7 24/28] fanotify: Emit generic error info for error event Gabriel Krisman Bertazi
2021-10-15  8:13   ` Amir Goldstein
2021-10-15 12:47   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 25/28] fanotify: Allow users to request FAN_FS_ERROR events Gabriel Krisman Bertazi
2021-10-15  8:27   ` Amir Goldstein
2021-10-15 12:49   ` Jan Kara
2021-10-14 21:36 ` [PATCH v7 26/28] ext4: Send notifications on error Gabriel Krisman Bertazi
2021-10-14 21:59   ` Theodore Ts'o
2021-10-14 21:36 ` [PATCH v7 27/28] samples: Add fs error monitoring example Gabriel Krisman Bertazi
2021-10-14 21:36 ` [PATCH v7 28/28] docs: Document the FAN_FS_ERROR event Gabriel Krisman Bertazi
2021-10-15  8:38 ` [PATCH v7 00/28] file system-wide error monitoring Amir Goldstein
2021-10-15  9:16 ` 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=20211015133811.GO23102@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.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-api@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=repnop@google.com \
    --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 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.