Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 19/20] fanotify: move event name into fanotify_fh
Date: Mon, 6 Jul 2020 11:21:24 +0300	[thread overview]
Message-ID: <CAOQ4uxjG6pd2_Rd1ssh__0f7=HVc0iOjAkQwaLsD+BOFPz2F=A@mail.gmail.com> (raw)
In-Reply-To: <20200703160229.GF21364@quack2.suse.cz>

On Fri, Jul 3, 2020 at 7:02 PM Jan Kara <jack@suse.cz> wrote:
>
> On Fri 12-06-20 12:33:42, Amir Goldstein wrote:
> > An fanotify event name is always recorded relative to a dir fh.
> > Move the name_len members of fanotify_name_event into unused space
> > in struct fanotify_fh.
> >
> > We add a name_offset member to allow packing a binary blob before
> > the name string in the variable size buffer. We are going to use
> > that space to store the child fid.
>
> So how much is this packing going to save us? Currently it is 1 byte for
> name events (modulo that fanotify_alloc_name_event_bug() you mention
> below). With the additional fanotify_fh in the event, we'll save two more
> bytes by the packing. So that doesn't really seem to be worth it to me.
> Am I missing some other benefit?
>
> Maybe your main motivation (which is not mentioned in the changelog at all
> BTW) is that the whole game of inline vs out of line file handles is
> pointless when we kmalloc() the event anyway because of the name?

The only motivation, which is written in the commit message is to make
space to store the child file handle. Saving space is just a by product.
In fact, the new parceling code looses this space back to alignment
and I am perfectly fine with that.

> And it's
> actively wasteful in case handles don't fit in the inline space. I agree
> with that and it's good observation. But I'd rather leave fanotify_fh
> struct alone for the cases where we want to bother with inline vs out of line
> file handles and define new way of partitioning space at the end of the
> event among one or two file handles and name. Something like:
>
> struct fanotify_dynamic_info {

I called this fanotify_info. There is no ambiguity that justifies _dynamic_.
The encapsulations are:

fanotify_fid_event { ..., fanotify_fid { ..,buf[INLINE_BUF] } }
fanotify_name_event { ..., fanotify_info { fanotify_fid { ..,buf[..]
}+, name[..] }


>         u8 dirfh_len;
>         u8 filefh_len;

I called these {dir,file}_fh_totlen to distinguish from fh->len, which does not
include the size of the fanotify_fh header fields.

>         u8 name_len;
>         unsigned char buf[];

This had to be 4 bytes aligned to contain fanotify_fh.

> };
>
> And at appropriate offsets (0, dirfh_len, dirfh_len + filefh_len) there
> would be additional info (e.g. type + fh for file handles). Maybe this
> format will require some tweaking so that processing of both storage types
> of file handles can be reasonably uniform but at this point it seems
> cleaner than what you try to do fanotify_fh with combining lenghts and
> offsets and some blobs in the middle...
>

I tried your suggestion (with the minor modifications above) and I
like the result.
Pushed prep series with 2 last patches changed to branch fanotify_prep.
Old prep series is at fanotify_prep-v2.
Pushed tested full series adapted to this change to fanotify_name_fid.
Old full series is at fanotify_name_fid-v4.

There was almost no changes to the fanotify_name_fid patches besides
adapting the accessors, e.g.:
-               fanotify_fh_blob(&FANOTIFY_NE(event)->dir_fh);
+              fanotify_info_file_fh(&FANOTIFY_NE(event)->info);

Please let me know if you want me to post fanotify_name_fid-v5 with these
changes.

Thanks,
Amir.

  reply	other threads:[~2020-07-06  8:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12  9:33 [PATCH 00/20] Prep work for fanotify named events Amir Goldstein
2020-06-12  9:33 ` [PATCH 01/20] fsnotify: Rearrange fast path to minimise overhead when there is no watcher Amir Goldstein
2020-07-03 14:03   ` Jan Kara
2020-07-04  9:30     ` Amir Goldstein
2020-07-06 11:05       ` Jan Kara
2020-07-09 17:56         ` fsnotify: minimise overhead when there are no marks with ignore mask Amir Goldstein
2020-07-26 15:20           ` fsnotify: minimise overhead when there are no marks related to sb Amir Goldstein
2020-07-27  7:44             ` Jan Kara
2020-07-27 10:02               ` Amir Goldstein
2020-06-12  9:33 ` [PATCH 02/20] fsnotify: fold fsnotify() call into fsnotify_parent() Amir Goldstein
2020-06-12  9:33 ` [PATCH 03/20] fsnotify: return non const from fsnotify_data_inode() Amir Goldstein
2020-06-12  9:33 ` [PATCH 04/20] nfsd: use fsnotify_data_inode() to get the unlinked inode Amir Goldstein
2020-06-12 10:25   ` Amir Goldstein
2020-06-12  9:33 ` [PATCH 05/20] kernfs: do not call fsnotify() with name without a parent Amir Goldstein
2020-06-29 13:27   ` Tejun Heo
2020-06-29 16:11   ` Greg Kroah-Hartman
2020-06-12  9:33 ` [PATCH 06/20] inotify: do not use objectid when comparing events Amir Goldstein
2020-06-12  9:33 ` [PATCH 07/20] fanotify: create overflow event type Amir Goldstein
2020-06-12  9:33 ` [PATCH 08/20] fanotify: break up fanotify_alloc_event() Amir Goldstein
2020-06-12  9:33 ` [PATCH 09/20] fsnotify: pass dir argument to handle_event() callback Amir Goldstein
2020-07-03 14:49   ` Jan Kara
2020-06-12  9:33 ` [PATCH 10/20] fanotify: generalize the handling of extra event flags Amir Goldstein
2020-06-12  9:33 ` [PATCH 11/20] fanotify: generalize merge logic of events on dir Amir Goldstein
2020-06-12  9:33 ` [PATCH 12/20] fanotify: distinguish between fid encode error and null fid Amir Goldstein
2020-06-12  9:33 ` [PATCH 13/20] fanotify: generalize test for FAN_REPORT_FID Amir Goldstein
2020-06-12  9:33 ` [PATCH 14/20] fanotify: mask out special event flags from ignored mask Amir Goldstein
2020-06-12  9:33 ` [PATCH 15/20] fanotify: prepare for implicit event flags in mark mask Amir Goldstein
2020-06-12  9:33 ` [PATCH 16/20] fanotify: use FAN_EVENT_ON_CHILD as implicit flag on sb/mount/non-dir marks Amir Goldstein
2020-06-12  9:33 ` [PATCH 17/20] fanotify: remove event FAN_DIR_MODIFY Amir Goldstein
2020-06-12  9:33 ` [PATCH 18/20] fsnotify: add object type "child" to object type iterator Amir Goldstein
2020-06-12  9:33 ` [PATCH 19/20] fanotify: move event name into fanotify_fh Amir Goldstein
2020-07-03 16:02   ` Jan Kara
2020-07-06  8:21     ` Amir Goldstein [this message]
2020-07-06 15:24       ` Jan Kara
2020-06-12  9:33 ` [PATCH 20/20] fanotify: no external fh buffer in fanotify_name_event 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='CAOQ4uxjG6pd2_Rd1ssh__0f7=HVc0iOjAkQwaLsD+BOFPz2F=A@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --subject='Re: [PATCH 19/20] fanotify: move event name into fanotify_fh' \
    /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

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).