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=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT 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 125C1C282C2 for ; Thu, 7 Feb 2019 15:18:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E00A621916 for ; Thu, 7 Feb 2019 15:18:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727203AbfBGPSr (ORCPT ); Thu, 7 Feb 2019 10:18:47 -0500 Received: from mx2.suse.de ([195.135.220.15]:50164 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726196AbfBGPSr (ORCPT ); Thu, 7 Feb 2019 10:18:47 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7877BAF17; Thu, 7 Feb 2019 15:18:45 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 29DE91E3DB5; Thu, 7 Feb 2019 16:18:45 +0100 (CET) Date: Thu, 7 Feb 2019 16:18:45 +0100 From: Jan Kara To: Amir Goldstein Cc: Jan Kara , Matthew Bobrowski , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v5 15/17] fanotify: support events with data type FSNOTIFY_EVENT_INODE Message-ID: <20190207151845.GH3597@quack2.suse.cz> References: <20190110170444.30616-1-amir73il@gmail.com> <20190110170444.30616-16-amir73il@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190110170444.30616-16-amir73il@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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; } ? Honza -- Jan Kara SUSE Labs, CR