linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 v5 10/22] fanotify: no external fh buffer in fanotify_name_event
Date: Thu, 16 Jul 2020 14:44:12 +0200	[thread overview]
Message-ID: <20200716124412.GA5022@quack2.suse.cz> (raw)
In-Reply-To: <20200716084230.30611-11-amir73il@gmail.com>

On Thu 16-07-20 11:42:18, Amir Goldstein wrote:
> The fanotify_fh struct has an inline buffer of size 12 which is enough
> to store the most common local filesystem file handles (e.g. ext4, xfs).
> For file handles that do not fit in the inline buffer (e.g. btrfs), an
> external buffer is allocated to store the file handle.
> 
> When allocating a variable size fanotify_name_event, there is no point
> in allocating also an external fh buffer when file handle does not fit
> in the inline buffer.
> 
> Check required size for encoding fh, preallocate an event buffer
> sufficient to contain both file handle and name and store the name after
> the file handle.
> 
> At this time, when not reporting name in event, we still allocate
> the fixed size fanotify_fid_event and an external buffer for large
> file handles, but fanotify_alloc_name_event() has already been prepared
> to accept a NULL file_name.
> 
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>

When reading this, I've got one cleanup idea for later: For FID events, we
could now easily check fh len in fanotify_alloc_fid_event(). If it fits in
inline size, allocate the event from kmem cache, if it does not, allocate
appropriately sized event from kmalloc(). Similarly when freeing event we
could check fh len to determine how to free the event. This way we can
completely get rid of the external buffer code, somewhat simplify all
the fh handling, remove the alignment restrictions on fanotify_fh and
fanotify_info...

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

  reply	other threads:[~2020-07-16 12:44 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16  8:42 [PATCH v5 00/22] fanotify events with name info Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 01/22] fanotify: generalize the handling of extra event flags Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 02/22] fanotify: generalize merge logic of events on dir Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 03/22] fanotify: distinguish between fid encode error and null fid Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 04/22] fanotify: generalize test for FAN_REPORT_FID Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 05/22] fanotify: mask out special event flags from ignored mask Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 06/22] fanotify: prepare for implicit event flags in mark mask Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 07/22] fanotify: use FAN_EVENT_ON_CHILD as implicit flag on sb/mount/non-dir marks Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 08/22] fsnotify: add object type "child" to object type iterator Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 09/22] fanotify: use struct fanotify_info to parcel the variable size buffer Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 10/22] fanotify: no external fh buffer in fanotify_name_event Amir Goldstein
2020-07-16 12:44   ` Jan Kara [this message]
2020-07-16 13:30     ` Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 11/22] dnotify: report both events on parent and child with single callback Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 12/22] inotify: " Amir Goldstein
2020-07-16 12:52   ` Jan Kara
2020-07-16 14:25     ` Amir Goldstein
2020-07-16 15:17       ` Jan Kara
2020-07-16  8:42 ` [PATCH v5 13/22] fanotify: " Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 14/22] fsnotify: send event to " Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 15/22] fsnotify: send event with parent/name info to sb/mount/non-dir marks Amir Goldstein
2020-07-16 17:01   ` Jan Kara
2020-07-16 17:20     ` Amir Goldstein
2020-07-16 17:57       ` Jan Kara
2020-07-16 18:42         ` Amir Goldstein
2020-07-16 22:34           ` Jan Kara
2020-07-17  3:49             ` Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 16/22] fsnotify: remove check that source dentry is positive Amir Goldstein
2020-07-16 13:13   ` Jan Kara
2020-07-16 13:29     ` Jan Kara
2020-07-16 13:54       ` Amir Goldstein
2020-07-16 14:06         ` Jan Kara
2020-07-16  8:42 ` [PATCH v5 17/22] fsnotify: send MOVE_SELF event with parent/name info Amir Goldstein
2020-07-16 13:45   ` Jan Kara
2020-07-16 13:59     ` Amir Goldstein
2020-07-16 14:10       ` Amir Goldstein
2020-07-16 15:57         ` Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 18/22] fanotify: add basic support for FAN_REPORT_DIR_FID Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 19/22] fanotify: report events with parent dir fid to sb/mount/non-dir marks Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 20/22] fanotify: add support for FAN_REPORT_NAME Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 21/22] fanotify: report parent fid + name + child fid Amir Goldstein
2020-07-16 15:59   ` Jan Kara
2020-07-16 16:08     ` Amir Goldstein
2020-07-16  8:42 ` [PATCH v5 22/22] fanotify: report parent fid " Amir Goldstein
2020-07-16 17:13 ` [PATCH v5 00/22] fanotify events with name info 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=20200716124412.GA5022@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).