fanotify super block mark and ignore mask

fanotify super block mark and ignore mask

[Amir Goldstein]

Hi Jan,

It's been over a year since I posted my last patch revision [1].
IIRC, one of your comments during LSF was to attach
marks to a super block instead of the root inode.

The patch series on my fanotify_sb branch [2] implements super
block marks after a lot of cleanup and re-factoring patches.
The patches pass all the fsnotify LTP tests and some very basic
sb mark tests, but before I post the series, I would like to write
some more tests.

While this patch series stands for itself and adds a feature,
that Marko requested, for me this is only a convenient checkpoint
before adding fanotify support for more events, because the super
block is always available from fsnotify hooks, whereas the mount is not.

The main issue I have right now is with the ignore masks logic.
The logic in send_to_group() doesn't match the logic in
fanotify_should_send_event(), which in turn, does not match the man
page documentation.

I was thinking:
- ignore mask on inode negates inode and mount and sb mark mask
- ignore mask on mount negates mount and sb mark masks, but not inode mark mask
- ignore mask on sb negates only sb mark mask

The reasoning is that is makes sense to include a super set and exclude
a subset. The problem is that inode is not really a subset of a mount, but
mount and inode are really a subset of a super block.

Current fanotify code seems to allow including an inode, but excluding
a mount, which will result (I think) in getting events on the inode unless
it was accessed from a specific mount. The examples of ignore mask in the
fanotify(7) man page do not imply that this use case was intended and I
really doubt if anybody is using ignore mask this way.

I wonder if we should change the behavior of fanotify to only allow
excluding an inode from a mount mark and not vice versa, as suggested
by man page and by the logic in fsnotify() and send_to_group() and wait
to see if anybody shouts.

Thoughts?

Amir.

[1] https://lwn.net/Articles/716973/
[2] https://github.com/amir73il/linux/commits/fanotify_sb

Re: fanotify super block mark and ignore mask

[Marko Rauhamaa]

Amir Goldstein <amir73il@gmail.com>:
> The main issue I have right now is with the ignore masks logic.
> The logic in send_to_group() doesn't match the logic in
> fanotify_should_send_event(), which in turn, does not match the man
> page documentation.
>
> I was thinking:
> - ignore mask on inode negates inode and mount and sb mark mask
> - ignore mask on mount negates mount and sb mark masks, but not inode
>   mark mask
> - ignore mask on sb negates only sb mark mask
>
> The reasoning is that is makes sense to include a super set and
> exclude a subset. The problem is that inode is not really a subset of
> a mount, but mount and inode are really a subset of a super block.
>
> Current fanotify code seems to allow including an inode, but excluding
> a mount, which will result (I think) in getting events on the inode
> unless it was accessed from a specific mount. The examples of ignore
> mask in the fanotify(7) man page do not imply that this use case was
> intended and I really doubt if anybody is using ignore mask this way.
>
> I wonder if we should change the behavior of fanotify to only allow
> excluding an inode from a mount mark and not vice versa, as suggested
> by man page and by the logic in fsnotify() and send_to_group() and
> wait to see if anybody shouts.
>
> Thoughts?

First off, adjusting the semantics this way would not affect my
application code in any way.

However, ...

 1. What you are proposing is going from include-then-exclude semantics
    to big-to-small semantics. Big-to-small semantics are well defined
    as long as two entities never partially overlap. That may well be
    guaranteed in Linux file systems today, but I wonder if that
    assumption can be cast in stone.

 2. Include-then-exclude semantics is easy to state and understand. It
    is also commonplace. Furthermore, I wonder if there was a real need
    for reversed, exclude-then-include semantics. You can always set up
    a second fanotify fd to monitor the exceptional includes.

 3. This change potentially breaks some user-space applications out
    there.


Marko

Re: fanotify super block mark and ignore mask

[Amir Goldstein]

On Wed, Apr 4, 2018 at 10:48 AM, Marko Rauhamaa
<marko.rauhamaa@f-secure.com> wrote:
> Amir Goldstein <amir73il@gmail.com>:
>> The main issue I have right now is with the ignore masks logic.
>> The logic in send_to_group() doesn't match the logic in
>> fanotify_should_send_event(), which in turn, does not match the man
>> page documentation.
>>
>> I was thinking:
>> - ignore mask on inode negates inode and mount and sb mark mask
>> - ignore mask on mount negates mount and sb mark masks, but not inode
>>   mark mask
>> - ignore mask on sb negates only sb mark mask
>>
>> The reasoning is that is makes sense to include a super set and
>> exclude a subset. The problem is that inode is not really a subset of
>> a mount, but mount and inode are really a subset of a super block.
>>
>> Current fanotify code seems to allow including an inode, but excluding
>> a mount, which will result (I think) in getting events on the inode
>> unless it was accessed from a specific mount. The examples of ignore
>> mask in the fanotify(7) man page do not imply that this use case was
>> intended and I really doubt if anybody is using ignore mask this way.
>>
>> I wonder if we should change the behavior of fanotify to only allow
>> excluding an inode from a mount mark and not vice versa, as suggested
>> by man page and by the logic in fsnotify() and send_to_group() and
>> wait to see if anybody shouts.
>>
>> Thoughts?
>
> First off, adjusting the semantics this way would not affect my
> application code in any way.
>
> However, ...
>
>  1. What you are proposing is going from include-then-exclude semantics
>     to big-to-small semantics. Big-to-small semantics are well defined
>     as long as two entities never partially overlap. That may well be
>     guaranteed in Linux file systems today, but I wonder if that
>     assumption can be cast in stone.
>
>  2. Include-then-exclude semantics is easy to state and understand. It
>     is also commonplace. Furthermore, I wonder if there was a real need
>     for reversed, exclude-then-include semantics. You can always set up
>     a second fanotify fd to monitor the exceptional includes.
>
>  3. This change potentially breaks some user-space applications out
>     there.
>
>

Hi Marko,

When you put it like that, include-then-exclude does make more sense.
It should also be simpler to implement, so I will send a patch to change
logic of send_to_group() to match that of fanotify_should_send_event().

BTW, for your use case, do you still need the functionality of
FAN_MARK_FILESYSTEM? Will you be able to test the patch set?
It is currently functional expect for combining ignore mask and
super block mark and I will get to that soon, after sorting out the ignore
logic.

Thanks!
Amir.

Re: fanotify super block mark and ignore mask

[Marko Rauhamaa]

Amir Goldstein <amir73il@gmail.com>:
> On Wed, Apr 4, 2018 at 10:48 AM, Marko Rauhamaa
> BTW, for your use case, do you still need the functionality of
> FAN_MARK_FILESYSTEM?

Yes, very much so.

> Will you be able to test the patch set?

I will arrange time for trying it out.


Marko

Re: fanotify super block mark and ignore mask

[Jan Kara]

On Wed 04-04-18 10:48:15, Marko Rauhamaa wrote:
> Amir Goldstein <amir73il@gmail.com>:
> > The main issue I have right now is with the ignore masks logic.
> > The logic in send_to_group() doesn't match the logic in
> > fanotify_should_send_event(), which in turn, does not match the man
> > page documentation.
> >
> > I was thinking:
> > - ignore mask on inode negates inode and mount and sb mark mask
> > - ignore mask on mount negates mount and sb mark masks, but not inode
> >   mark mask
> > - ignore mask on sb negates only sb mark mask
> >
> > The reasoning is that is makes sense to include a super set and
> > exclude a subset. The problem is that inode is not really a subset of
> > a mount, but mount and inode are really a subset of a super block.
> >
> > Current fanotify code seems to allow including an inode, but excluding
> > a mount, which will result (I think) in getting events on the inode
> > unless it was accessed from a specific mount. The examples of ignore
> > mask in the fanotify(7) man page do not imply that this use case was
> > intended and I really doubt if anybody is using ignore mask this way.
> >
> > I wonder if we should change the behavior of fanotify to only allow
> > excluding an inode from a mount mark and not vice versa, as suggested
> > by man page and by the logic in fsnotify() and send_to_group() and
> > wait to see if anybody shouts.
> >
> > Thoughts?
> 
> First off, adjusting the semantics this way would not affect my
> application code in any way.
> 
> However, ...
> 
>  1. What you are proposing is going from include-then-exclude semantics
>     to big-to-small semantics. Big-to-small semantics are well defined
>     as long as two entities never partially overlap. That may well be
>     guaranteed in Linux file systems today, but I wonder if that
>     assumption can be cast in stone.
> 
>  2. Include-then-exclude semantics is easy to state and understand. It
>     is also commonplace. Furthermore, I wonder if there was a real need
>     for reversed, exclude-then-include semantics. You can always set up
>     a second fanotify fd to monitor the exceptional includes.
> 
>  3. This change potentially breaks some user-space applications out
>     there.

Yeah, include-then-exclude semantics looks like a better option to me as
well.

								Honza

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