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=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 AEEE6C433E0 for ; Thu, 16 Jul 2020 23:13:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 937A72070E for ; Thu, 16 Jul 2020 23:13:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727120AbgGPXNp (ORCPT ); Thu, 16 Jul 2020 19:13:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:42556 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726007AbgGPXNo (ORCPT ); Thu, 16 Jul 2020 19:13:44 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id AB76DAB89; Thu, 16 Jul 2020 22:34:45 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 63C751E0E83; Fri, 17 Jul 2020 00:34:41 +0200 (CEST) Date: Fri, 17 Jul 2020 00:34:41 +0200 From: Jan Kara To: Amir Goldstein Cc: Jan Kara , linux-fsdevel Subject: Re: [PATCH v5 15/22] fsnotify: send event with parent/name info to sb/mount/non-dir marks Message-ID: <20200716223441.GA5085@quack2.suse.cz> References: <20200716084230.30611-1-amir73il@gmail.com> <20200716084230.30611-16-amir73il@gmail.com> <20200716170133.GJ5022@quack2.suse.cz> <20200716175709.GM5022@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 16-07-20 21:42:20, Amir Goldstein wrote: > On Thu, Jul 16, 2020 at 8:57 PM Jan Kara wrote: > > > > On Thu 16-07-20 20:20:04, Amir Goldstein wrote: > > > On Thu, Jul 16, 2020 at 8:01 PM Jan Kara wrote: > > > > > > > > On Thu 16-07-20 11:42:23, Amir Goldstein wrote: > > > > > Similar to events "on child" to watching directory, send event "on child" > > > > > with parent/name info if sb/mount/non-dir marks are interested in > > > > > parent/name info. > > > > > > > > > > The FS_EVENT_ON_CHILD flag can be set on sb/mount/non-dir marks to specify > > > > > interest in parent/name info for events on non-directory inodes. > > > > > > > > > > Events on "orphan" children (disconnected dentries) are sent without > > > > > parent/name info. > > > > > > > > > > Events on direcories are send with parent/name info only if the parent > > > > > directory is watching. > > > > > > > > > > Signed-off-by: Amir Goldstein > > > > > > > > Hum, doesn't this break ignore mask handling in > > > > fanotify_group_event_mask()? Because parent's ignore mask will be included > > > > even though parent is added into the iter only to carry the parent info... > > > > > > > > > > Hmm, break ignore mask handling? or fix it? > > > > > > Man page said: > > > "Having these two types of masks permits a mount point or directory to be > > > marked for receiving events, while at the same time ignoring events for > > > specific objects under that mount point or directory." > > > > Right, but presumably that speaks of the case of a mark where the parent > > has FS_EVENT_ON_CHILD set. For case of parent watching events of a child, I > > agree it makes sense to apply ignore masks of both the parent and the child. > > > > > The author did not say what to expect from marking a mount and ignoring > > > a directory. > > > > Yes and I'd expect to apply ignore mask on events for that directory but > > not for events on files in that directory... Even more so because this will > > be currently inconsistent wrt whether the child is dir (parent's ignore mask > > does not apply) or file (parent's ignore mask does apply). > > > > Indeed. For that I used this trick in my POC: > > /* Set the mark mask, so fsnotify_parent() will find this mark */ > ovm->fsn_mark.mask = mask | FS_EVENT_ON_CHILD; > ovm->fsn_mark.ignored_mask = mask; > > It's not how users are expected to configure an ignored mask on children > but we can work the ignored mask information into the object mask, like > I already did w.r.t FS_MODIFY and get the same result without the hack. OK, nice trick but for this series, I'd like to keep the original ignore mask behavior (bug to bug compatibility) or possibly let parent's ignore mask be applied only for events being sent to the parent due to its FS_EVENT_ON_CHILD. Can you please fix that up? I won't get to it before I leave for vacation but once I return, I'd like to just pick the fixed up commit and push everything to linux-next... Thanks! Honza -- Jan Kara SUSE Labs, CR