lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Oct 2017 16:19:07 +0200
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Jan Kara <jack@...e.cz>, Xiong Zhou <xzhou@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 7/7] fanotify: clean up CONFIG_FANOTIFY_ACCESS_PERMISSIONS
 ifdefs

On Wed, Oct 25, 2017 at 1:44 PM, Amir Goldstein <amir73il@...il.com> wrote:
>> +static inline bool fanotify_is_perm_event(u32 mask)
>> +{
>> +       return IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS) &&
>> +               mask & FAN_ALL_PERM_EVENTS;
>
> I know this is good w.r.t operation precedence, but it gets me eerie to see
> bit masking without (). maybe its just me.

Yeah, not easy to get used to, but here I don't think it hurts readability.

>> +                       } else
>> +                               FANOTIFY_PE(fsn_event)->response = FAN_ALLOW;
>
> Not your change, but if you post another version please add {} after else

Okay.

>
>> +               }
>> +               spin_unlock(&group->notification_lock);
>>
>> -       /*
>> -        * Destroy all non-permission events. For permission events just
>> -        * dequeue them and set the response. They will be freed once the
>> -        * response is consumed and fanotify_get_response() returns.
>> -        */
>> -       while (!fsnotify_notify_queue_is_empty(group)) {
>> -               fsn_event = fsnotify_remove_first_event(group);
>> -               if (!(fsn_event->mask & FAN_ALL_PERM_EVENTS)) {
>> -                       spin_unlock(&group->notification_lock);
>> -                       fsnotify_destroy_event(group, fsn_event);
>> -                       spin_lock(&group->notification_lock);
>> -               } else
>> -                       FANOTIFY_PE(fsn_event)->response = FAN_ALLOW;
>> +               /* Response for all permission events it set, wakeup waiters */
>> +               wake_up(&group->fanotify_data.access_waitq);
>>         }
>> -       spin_unlock(&group->notification_lock);
>> -
>> -       /* Response for all permission events it set, wakeup waiters */
>> -       wake_up(&group->fanotify_data.access_waitq);
>
> So I might as well learn something from this review -
> why did you move wake_up inside spinlock? Does it matter at all?

It would be strange if I did that.  But I didn't, it's just that diff
sometimes doesn't make it easy to read the (non) change.

Thanks,
Miklos

Powered by blists - more mailing lists