All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Eric Paris <eparis@redhat.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/4] fsnotify: pass single mark to handle_event()
Date: Wed, 4 Jan 2017 09:28:44 +0100	[thread overview]
Message-ID: <20170104082844.GH3780@quack2.suse.cz> (raw)
In-Reply-To: <1482867148-31497-1-git-send-email-amir73il@gmail.com>

Hi,

On Tue 27-12-16 21:32:24, Amir Goldstein wrote:
> I thought this would turn out simpler, so you may be able to use it
> for your work, but I'm afraid that's not the case.
> 
> Anyway, since I am leaving for new year's vacation, I am posting
> what I have in case you want to use any of it.
> 
> It passed some initial tests I ran, but when I wanted to test the
> corner case referred to in patch 1, I found that my test program
> hangs open() syscalls with kernel 4.10-rc1 before any of my changes.
> 
> This is the mark setup I was testing [1]:
>   fanotify_mark(fd, FAN_MARK_ADD,
>                 FAN_OPEN_PERM | FAN_EVENT_ON_CHILD, AT_FDCWD,
>                 path);
>   fanotify_mark(fd, FAN_MARK_ADD | \
>                 FAN_MARK_IGNORED_SURV_MODIFY | FAN_MARK_IGNORED_MASK
>                 FAN_OPEN_PERM | FAN_EVENT_ON_CHILD, AT_FDCWD,
>                 FAN_CLOSE_WRITE, AT_FDCWD,
>                 path);
>   fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
>                 FAN_OPEN_PERM | FAN_CLOSE_WRITE, AT_FDCWD,
>                 path);
> 
> Without FAN_EVENT_ON_CHILD it works fine, but with FAN_EVENT_ON_CHILD,
> something bad is going on and I did not have time to look into it.

I had a look at the patches and the result does not look simpler than what
we had before AFAICT. Sure we don't have to pass both marks into
->handle_event but is that really such a big win? And actually my patches
for dropping SRCU lock when waiting for userspace response to fanotify
permission event need both marks in ->handle_event because they both need
to be protected against freeing when SRCU lock is dropped... So I don't
think this is really viable path.

However one thing that may be worth cleaning up is that
fanotify_should_send_event() needlessly checks the masks - send to group
already did this. So I'd move the check for FS_EVENT_ON_CHILD from
fanotify_should_send_event() to send_to_group() - arguably it belongs there
- and then just completely drop checking of the masks from
fanotify_should_send_event(). What do you think?

> In general, I would like to start working on an fsnotify testsuite,
> so if you have any plans wrt writing extra tests or ideas about specific
> missing tests, please let me know about them.

That would be certainly worthwhile. Actually when I find some useful
testcase I add it to LTP under the
testcases/kernel/syscalls/{fanotify|inotify}. So please extend that if you
have some more ideas for testcases.

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

  parent reply	other threads:[~2017-01-04  8:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-27 19:32 [RFC][PATCH 0/4] fsnotify: pass single mark to handle_event() Amir Goldstein
2016-12-27 19:32 ` [RFC][PATCH 1/4] fsnotify: process inode/vfsmount marks independently Amir Goldstein
2016-12-27 19:32 ` [RFC][PATCH 2/4] fsnotify: helper to update marks ignored_mask Amir Goldstein
2016-12-27 19:32 ` [RFC][PATCH 3/4] fsnotify: return FSNOTIFY_DROPPED when handle_event() dropped event Amir Goldstein
2016-12-27 19:32 ` [RFC][PATCH 4/4] fsnotify: pass single mark to handle_event() Amir Goldstein
2017-01-04  8:28 ` Jan Kara [this message]
2017-01-04  9:57   ` [RFC][PATCH 0/4] " Amir Goldstein
2017-01-04 10:39     ` Jan Kara
2017-01-04 10:45       ` Amir Goldstein
2017-01-04 11:47         ` 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=20170104082844.GH3780@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=eparis@redhat.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 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.