From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D6DEC282C2 for ; Thu, 7 Feb 2019 16:10:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 401BE2175B for ; Thu, 7 Feb 2019 16:10:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pAyzJBKE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726319AbfBGQK5 (ORCPT ); Thu, 7 Feb 2019 11:10:57 -0500 Received: from mail-yb1-f196.google.com ([209.85.219.196]:36163 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726171AbfBGQK5 (ORCPT ); Thu, 7 Feb 2019 11:10:57 -0500 Received: by mail-yb1-f196.google.com with SMTP id h40so164206ybj.3 for ; Thu, 07 Feb 2019 08:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yD1kv8ZN4RbNXf6CgQ0Gh2JX1z9PDgLshJv4WrvCB8Q=; b=pAyzJBKEZaTEZqheezwhxqRenYjghj9Df4vUC4reMyDNGkceARqbaqJf3SzKcxf9qL 2X2mTfpdXGXEZmd7+XYa7pFH/Mt4Ylk2zp2UDqysB7zbC62doaC37F9n2YFMf72diazT 485qmZ9IzoYSAVH8ZHOstUifAd2bTkl+ygL8VUrcpeHck0xnz6RtpdTcztjhKzOlHW6N P/UylxW9y2GILkHQrTLU82x18nos98QmSpsIzh5UCypSLQpwKwEvAUHlwh6c6WxBfwLM pCoe/OIHK0HU4mFXZXKQOVnnIl/8eNzhXvZdmykyxgbZ2N30bUYyhOEikKfUBDsQ9vz9 fQMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yD1kv8ZN4RbNXf6CgQ0Gh2JX1z9PDgLshJv4WrvCB8Q=; b=b2OJTEc97h4xRpV+qbk64EJYFrfcF08pXQ+9RhnbF2t6Jo/+lnh3p4kwL2c0LhyPxf 4KUESujvsA4wh9sIOpu55dACYuNg6Kf2YLE8F6c9Hn0888MjiviyctjwWNcNVHOMJXNM P/V7JDBrVhdmp9MFpCViEchWZnQd5W11zlVUfClfHNpkQ7F0ddphkx5WCcd1V+N2VwLG ICqRjmlJ+aC39cB8XCkEUKGkrU7jLzXWYg7GKvG5lDK4QetICX/FAsEf8/l7YM5xGZkC SF9kta3PZNNf8Evnz2/hWoXLFRKX2n3y8tvELx/LA3Em6H82B+ZsHiADfrtOeJOu0MBJ 4bUw== X-Gm-Message-State: AHQUAuZwc+KkAoXePJfqA2+lR8k5cVjPVNpi++DlyoKuioNl0CFx70Ya hR2dQNtmGFmXA7+8pK/F2LSgNSAQFuXs/R1eun4= X-Google-Smtp-Source: AHgI3IZQyqhbQDOVFyZk8vb7HvKExEhY8soHepdkPkoBDr/mTHjxB5Y6PBqn3C9GIqlQGd7vmdEGpKnGR7jXgBdB4Dk= X-Received: by 2002:a25:ba84:: with SMTP id s4mr14063274ybg.325.1549555856423; Thu, 07 Feb 2019 08:10:56 -0800 (PST) MIME-Version: 1.0 References: <20190110170444.30616-1-amir73il@gmail.com> <20190110170444.30616-16-amir73il@gmail.com> <20190207151845.GH3597@quack2.suse.cz> In-Reply-To: <20190207151845.GH3597@quack2.suse.cz> From: Amir Goldstein Date: Thu, 7 Feb 2019 18:10:44 +0200 Message-ID: Subject: Re: [PATCH v5 15/17] fanotify: support events with data type FSNOTIFY_EVENT_INODE To: Jan Kara Cc: Matthew Bobrowski , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Feb 7, 2019 at 5:18 PM Jan Kara wrote: > > On Thu 10-01-19 19:04:42, Amir Goldstein wrote: > > When event data type is FSNOTIFY_EVENT_INODE, we don't have a refernece > > to the mount, so we will not be able to open a file descriptor when user > > reads the event. However, if the listener has enabled reporting file > > identifier with the FAN_REPORT_FID init flag, we allow reporting those > > events and we use an identifier inode to encode fid. > > > > The inode to use as identifier when reporting fid depends on the event. > > For dirent modification events, we report the modified directory inode > > and we report the "victim" inode otherwise. > > For example: > > FS_ATTRIB reports the child inode even if reported on a watched parent. > > FS_CREATE reports the modified dir inode and not the created inode. > > > > Signed-off-by: Amir Goldstein > > --- > > fs/notify/fanotify/fanotify.c | 67 ++++++++++++++++++++---------- > > fs/notify/fanotify/fanotify.h | 2 +- > > fs/notify/fanotify/fanotify_user.c | 3 +- > > 3 files changed, 48 insertions(+), 24 deletions(-) > > > > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c > > index fcb98ea99508..e3ca1632feb8 100644 > > --- a/fs/notify/fanotify/fanotify.c > > +++ b/fs/notify/fanotify/fanotify.c > > @@ -96,7 +96,7 @@ static int fanotify_get_response(struct fsnotify_group *group, > > > > pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__, > > group, event, ret); > > - > > + > > return ret; > > } > > > > @@ -106,9 +106,10 @@ static int fanotify_get_response(struct fsnotify_group *group, > > * been included within the event mask, but have not been explicitly > > * requested by the user, will not be present in the returned mask. > > */ > > -static u32 fanotify_group_event_mask(struct fsnotify_iter_info *iter_info, > > - u32 event_mask, const void *data, > > - int data_type) > > +static u32 fanotify_group_event_mask(struct fsnotify_group *group, > > + struct fsnotify_iter_info *iter_info, > > + u32 event_mask, const void *data, > > + int data_type) > > { > > __u32 marks_mask = 0, marks_ignored_mask = 0; > > const struct path *path = data; > > @@ -118,14 +119,14 @@ static u32 fanotify_group_event_mask(struct fsnotify_iter_info *iter_info, > > pr_debug("%s: report_mask=%x mask=%x data=%p data_type=%d\n", > > __func__, iter_info->report_mask, event_mask, data, data_type); > > > > - /* If we don't have enough info to send an event to userspace say no */ > > - if (data_type != FSNOTIFY_EVENT_PATH) > > - return 0; > > - > > - /* Sorry, fanotify only gives a damn about files and dirs */ > > - if (!d_is_reg(path->dentry) && > > - !d_can_lookup(path->dentry)) > > + if (data_type == FSNOTIFY_EVENT_PATH) { > > + /* Path type events are only relevant for files and dirs */ > > + if (!d_is_reg(path->dentry) && !d_can_lookup(path->dentry)) > > + return 0; > > Hum, does this mean that fanotify won't report O_PATH open on symlink > unlike inotify? So shouldn't the condition rather be: > > if (!FAN_GROUP_FLAG(group, FAN_REPORT_FID)) { > if (data_type != FSNOTIFY_EVENT_PATH) > return 0; > if (!d_is_reg(path->dentry) && !d_can_lookup(path->dentry)) > return 0; > } > > ? Makes sense. Thanks, Amir.