From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-yw1-f67.google.com ([209.85.161.67]:34510 "EHLO
        mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728278AbeI1BwY (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Thu, 27 Sep 2018 21:52:24 -0400
Received: by mail-yw1-f67.google.com with SMTP id m129-v6so1604613ywc.1
        for <linux-fsdevel@vger.kernel.org>; Thu, 27 Sep 2018 12:32:34 -0700 (PDT)
MIME-Version: 1.0
References: <20180921182031.3184-1-amir73il@gmail.com> <20180927133924.GA8800@quack2.suse.cz>
In-Reply-To: <20180927133924.GA8800@quack2.suse.cz>
From: Amir Goldstein <amir73il@gmail.com>
Date: Thu, 27 Sep 2018 22:32:23 +0300
Message-ID: <CAOQ4uxhNtpG7eqXMCVA2ynrUznnQtEyD_CQLzhbAzdozn7GUUQ@mail.gmail.com>
Subject: Re: [PATCH v2 0/2] New fanotify event info API
To: Jan Kara <jack@suse.cz>
Cc: Nixiaoming <nixiaoming@huawei.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Sep 27, 2018 at 4:39 PM Jan Kara <jack@suse.cz> wrote:
>
> On Fri 21-09-18 21:20:29, Amir Goldstein wrote:
> > Jan,
> >
> > Reposting my slightly modified cleanup patch along with the patch
> > from nixiaoming that uses it to add a new fanotify_init() flag.
> >
> > After a few review cycles with nixiaoming, per his request, I took
> > his FAN_EVENT_INFO_TID patch to my tree, fixes a couple of issues
> > including commit message wording and tested it.
> >
> > For me, the new API seems very intuitive, not sure why thread id was
> > not reported to begin with, but if you like more concrete use cases,
> > you will need to ask them from nixiaoming.
> >
> > Thanks,
> > Amir.
> >
> > Amir Goldstein (1):
> >   fanotify: store fanotify_init() flags in group's fanotify_data
> >
> > nixiaoming (1):
> >   fanotify: support reporting thread id instead of process id
>
> Thanks. Both patches look good to me and I've queued them up to my tree.
>

Thanks!
However... I have found some issue that may require v3:

- I do not like the idea of changing uapi bit group constants
  (FAN_ALL_INIT_FLAGS) and adding new bit group constants
  (FAN_EVENT_INFO_FLAGS) which I don't think should be in uapi.
- uapi flag FAN_MARK_FILESYSTEM collides with kernel internal flag
  FAN_MARK_ONDIR

Sigh!
I will send a suggestion patch of how I think those issues should be sorted
out as a basis for making the API change for_next safer.

Thanks,
Amir.