From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f68.google.com ([209.85.161.68]:45303 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726839AbeIMRlK (ORCPT ); Thu, 13 Sep 2018 13:41:10 -0400 MIME-Version: 1.0 References: In-Reply-To: From: Amir Goldstein Date: Thu, 13 Sep 2018 15:31:42 +0300 Message-ID: Subject: Re: Is it possible to add pid and comm members to the event structure to increase the display of user and thread information? To: nixiaoming@huawei.com Cc: Eric Paris , Robert Love , John McCutchan , Jan Kara , Al Viro , linux-kernel , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Sep 13, 2018 at 2:25 PM Nixiaoming wrote: > > On Tue, Sep 11, 2018 at 11:12 PM Amir Goldstein wrote: > >On Tue, Sep 11, 2018 at 9:51 AM Nixiaoming wrote: > >> > >> Inotify api cannot display information about users and processes. > >> That is, you can only know that the file event is generated, but you don't know who triggered the event, which is not conducive to fault location. > >> Is it possible to add pid and comm members to the event structure to increase the display of user and thread information? > >> > > > >"Is it possible?" is not the only relevant question. > >I suppose your patch can sort of works, but it exposes information to > >potentially unpriveleged > >processes, even exposes pid values outside of the process pid namespace. > > > >While those issues could be addressed, you can't change the format > >struct inotify_event > >without breaking existing applications. > > > In order to improve the fault location capability, can we make incompatible interface changes? Not unless application/sysadmin/distro opts-in for the incompatible change. > > >I guess you are not using fanotify API, which already provides pid > >information (albiet tgid), > >because it lacks other functionality that you need? Which > >functionality might that be? > >Is it directory modification events? > >If so than you might be interested in my effort to add support for > >those events to fanotify: > >https://github.com/amir73il/fsnotify-utils/wiki/Super-block-root-watch > > > The fanotify API does not support monitoring file deletion events Yes, I am working toward that goal. > The fanotify API supports tgid display, > but for multi-threaded programs, > it still cannot accurately identify which thread triggered the event. > Can I modify tgid to pid? > - event->tgid = get_pid(task_tgid(current)); > + event->tgid = get_pid(task_pid(current)); > So if you would like to change that you need to add a new flag to fanotify_init (e.g. FAN_EVENT_INFO_TID) new applications that would opt-in for the flag will get task_pid() while existing application will keep getting task_tgid() new applications will get -EINVAL when passing FAN_EVENT_INFO_TID to fanotify_init() on an old kernel and they could then fall back to getting tgid in events and be aware of that fact. Thanks, Amir.