Re: [PATCH v3 4.17] inotify: Add flag IN_EXCL_ADD for inotify_add_watch()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 30, 2018 at 7:04 PM, Jan Kara <jack@xxxxxxx> wrote:
> On Wed 30-05-18 18:40:27, Amir Goldstein wrote:
>> On Wed, May 30, 2018 at 4:35 PM, Henry Wilson <henry.wilson@xxxxxxxxxxx> wrote:
>> > On 30/05/18 14:01, Jan Kara wrote:
>> >>
>> >> Thanks. The patch looks good. I've added it to my tree. BTW, do you plan
>> >> on
>> >> working on a similar addition to fanotify?
>> >>
>> >>                                                                 Honza
>> >>
>> >
>> > Ah that's grand, I'm glad to have helped to improve things.
>> > I'm not familiar with fanotify, however a quick look at fanotify_user.c
>> > suggests that a similar approach may be taken by modifying:
>> >
>> > if(!fsn_mark) {
>> >         ...
>> > }
>> > else if (create) {
>> >         return -EEXIST;
>> > }
>> >
>> > in both fanotify_add_vfsmount_mark() and fanotify_add_inode_mark()
>> >
>>
>> I think that was a yes/no question and I interpret your answer as no??
>>
>> Anyway, another yes/no question:
>> Can you write a simple LTP test to verify the new API?
>>
>> I reccon Jan was also expecting an actual patch posted to man pages
>> maintainer (and linux-api, which was not cc'ed on the latest patch).
>
> Yes, and I think Henry is about to post it, just didn't get to it yet.
>
>> About the fanotify change, since fanotify API does have 'flags' separate
>> from 'mask', I am not sure if FAN_MARK_EXCL_ADD would be the
>> best flag name?? Perhaps FAN_MARK_CREATE? FAN_MARK_NEW?
>> not sure.
>
> Yes, for fanotify we could choose a different name.
>
>> But also, I did not get a chance to comment about the chosen inotify
>> flag name that the lexical proximity to IN_EXCL_UNLINK is a bit odd
>> considering that _EXCL_ mean two completely different things.
>>
>> Should we maybe re-consider the chosen flag name?
>
> I'm open to that, I have the patch just sitting in an internal branch for
> now. Do you have a better suggestion? Maybe since we already have
> IN_MASK_ADD, we could call it IN_MASK_CREATE? And then FAN_MARK_CREATE for
> fanotify_mark(2)?
>

I like that naming.

Thinking forward, since we don't have many reserved bits left in inotify mask,
we should return -EINVAL for both IN_MASK_ADD and IN_MASK_CREATE
(they don't make sense together anyway), so we may re purpose the flag
combination in the future for something else.

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux