On Wed, Oct 25, 2017 at 1:44 PM, Amir Goldstein <amir7...@gmail.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
