All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Matthew Bobrowski <repnop@google.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] New fanotify API for ignoring events
Date: Sun, 26 Jun 2022 18:57:01 +0300	[thread overview]
Message-ID: <CAOQ4uxj8CLbiOjwxZOK9jGM69suakdJtNp9=0b7W=ie4jGp3Sg@mail.gmail.com> (raw)
In-Reply-To: <20220624143538.2500990-1-amir73il@gmail.com>

On Fri, Jun 24, 2022 at 5:35 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> Hi Jan,
>
> As we discussed [1], here is the implementation of the new
> FAN_MARK_IGNORE API, to try and sort the historic mess of
> FAN_MARK_IGNORED_MASK.
>

Jan,

When we started talking about adding FAN_MARK_IGNORE
it was to address one specific flaw of FAN_MARK_IGNORED_MASK,
but after staring at the API for some time, I realized there are other
wrinkles with FAN_MARK_IGNORED_MASK that could be addressed
by a fresh new API.

I added more input validations following the EEXIST that you requested.
The new errors can be seen in the ERRORS section of the man page [3].
The new restrictions will reduce the size of the test matrix, but I did not
update the LTP tests [2] to check the new restrictions yet.

I do not plan to post v3 patches before improving the LTP tests,
but I wanted to send this heads up as an API proposal review.
The kernel commit that adds FAN_MARK_IGNORE [1] summarize the
new API restrictions as follows:

    The new behavior is non-downgradable.  After calling fanotify_mark() with
    FAN_MARK_IGNORE once, calling fanotify_mark() with FAN_MARK_IGNORED_MASK
    on the same object will return EEXIST error.

    Setting the event flags with FAN_MARK_IGNORE on a non-dir inode mark
    has no meaning and will return ENOTDIR error.

    The meaning of FAN_MARK_IGNORED_SURV_MODIFY is preserved with the new
    FAN_MARK_IGNORE flag, but with a few semantic differences:

    1. FAN_MARK_IGNORED_SURV_MODIFY is required for filesystem and mount
       marks and on an inode mark on a directory. Omitting this flag
       will return EINVAL or EISDIR error.

    2. An ignore mask on a non-directory inode that survives modify could
       never be downgraded to an ignore mask that does not survive modify.
       With new FAN_MARK_IGNORE semantics we make that rule explicit -
       trying to update a surviving ignore mask without the flag
       FAN_MARK_IGNORED_SURV_MODIFY will return EEXIST error.

    The conveniene macro FAN_MARK_IGNORE_SURV is added for
    (FAN_MARK_IGNORE | FAN_MARK_IGNORED_SURV_MODIFY), because the
    common case should use short constant names.

Comments and questions on the API changes are most welcome.
Suggestion for more restrictions as well.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fan_mark_ignore
[2] https://github.com/amir73il/ltp/commits/fan_mark_ignore
[3] https://github.com/amir73il/man-pages/commits/fan_mark_ignore

  parent reply	other threads:[~2022-06-26 15:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24 14:35 [PATCH v2 0/2] New fanotify API for ignoring events Amir Goldstein
2022-06-24 14:35 ` [PATCH v2 1/2] fanotify: prepare for setting event flags in ignore mask Amir Goldstein
2022-06-26  7:57   ` Amir Goldstein
2022-06-27 11:32     ` Jan Kara
2022-06-27 12:14       ` Amir Goldstein
2022-06-24 14:35 ` [PATCH v2 2/2] fanotify: introduce FAN_MARK_IGNORE Amir Goldstein
2022-06-26 15:57 ` Amir Goldstein [this message]
2022-06-27 11:24   ` [PATCH v2 0/2] New fanotify API for ignoring events 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='CAOQ4uxj8CLbiOjwxZOK9jGM69suakdJtNp9=0b7W=ie4jGp3Sg@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=repnop@google.com \
    /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.