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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1680EC433EF for ; Tue, 26 Oct 2021 14:38:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E968160E8F for ; Tue, 26 Oct 2021 14:38:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236791AbhJZOkf (ORCPT ); Tue, 26 Oct 2021 10:40:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234327AbhJZOkb (ORCPT ); Tue, 26 Oct 2021 10:40:31 -0400 Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2921C061745; Tue, 26 Oct 2021 07:38:06 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id l7so17480346iln.8; Tue, 26 Oct 2021 07:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mz5oUK/oK3BVMLZWJgHWXHDF3nQYv6jCeATw+GykwaI=; b=kQN4aD+XkvJTvy6+aMGUG/W7WLHjbdFpS4DETJrVPT1WmFGYqgswEF6umeQi5ybXtW uEOkT7dXmR6mOXcb9Ts8GdQNkPnvPVAWeWR7HJLgBHMOVu+LvoDzR1EFTlqzzJiQEEBM zdYZqh9dzAFwQlOuQ+LR8VfDGbSXCddW8gqzthN2MT5iljk7i3ttSNWxcJNWbAoEBfOg ZETI3PD/sJjPQrRUyD7FAFYLb7XKX6DbgTrtPOmpLdpNLRi1MM1SMYSXTuThVpfrrZ6I /j1zB7kS3aKtrPrLNvtg9R21g8Pf309GM2if3InRS7Vuk/nsv8DB/66VIAMwHJqMsa1R 0+Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mz5oUK/oK3BVMLZWJgHWXHDF3nQYv6jCeATw+GykwaI=; b=B0tsXZkvxHxU8gHvBT9nW4/66Axqt8XgaxUP3eJAOfJB1mZoQguEgNTxhRmCZ5ogi1 fLk1klYlQP3VSxWw1Sew/dhYYYljDhGTZ0fAyqrY1Qb4mvo35gbaYzyxXwikPDRVSYXj UlSSVKwKkHUSW7lBTsjAub2c1rzSb8hAVSYL4rvH4Bf/lqcpgwlikJ19ufrxcBhh1br7 nHOHEYbhHffEczKGTyuihta9GX/tUQZSWr8WFrJHYW0IOItgcEEe3hVP4nWWFgeIxDOZ eO4aNA2UE1GJG5OfouyvHr7jL+seyVTd9wrPpP+Z3pzZHEELpTYwuoJmj+CJ3f2glh1/ 8QSA== X-Gm-Message-State: AOAM531rftnMaBtg7OCHNJDjlM9ZLEL48S8DaLWcZKm0HS6X/X0Uyhhe g23PAoI0mJCY7v/NrKTfWKl5M0+ufoYC/ByEKZbfj8ZnZIc= X-Google-Smtp-Source: ABdhPJxV/vbN+puYn48rGotFmTAILT3LqA59R0OhV2ggXxFeFbQFI7FcwY00+hdnXdoPGhJLJXcJ7StYrBkvoSADM0Y= X-Received: by 2002:a92:d3d1:: with SMTP id c17mr14547328ilh.319.1635259086168; Tue, 26 Oct 2021 07:38:06 -0700 (PDT) MIME-Version: 1.0 References: <20211025204634.2517-1-iangelak@redhat.com> <20211025204634.2517-6-iangelak@redhat.com> In-Reply-To: <20211025204634.2517-6-iangelak@redhat.com> From: Amir Goldstein Date: Tue, 26 Oct 2021 17:37:55 +0300 Message-ID: Subject: Re: [RFC PATCH 5/7] Fsnotify: Add a wrapper around the fsnotify function To: Ioannis Angelakopoulos Cc: linux-fsdevel , virtio-fs-list , linux-kernel , Jan Kara , Al Viro , Miklos Szeredi , Vivek Goyal Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Oct 25, 2021 at 11:47 PM Ioannis Angelakopoulos wrote: > > Generally, inotify events are generated locally by calling the "fsnotify" > function in fs/notify/fsnotify.c and various helper functions. However, now > we expect events to arrive from the FUSE server. Thus, without any > intervention a user space application will receive two events. One event is > generated locally and one arrives from the server. > > Hence, to avoid duplicate events we need to "suppress" the local events > generated by the guest kernel for FUSE inodes. To achieve this we add a > wrapper around the "fsnotify" function in fs/notify/fsnotify.c that > checks if the remote inotify is enabled and based on the check either it > "suppresses" or lets through a local event. > > The wrapper will be called in the place of the original "fsnotify" call > that is responsible for the event notification (now renamed as > "__fsnotify"). > > When the remote inotify is not enabled, all local events will be let > through as expected. This process is completely transparent to user space. > > Signed-off-by: Ioannis Angelakopoulos > --- > fs/notify/fsnotify.c | 35 ++++++++++++++++++++++++++++++-- > include/linux/fsnotify_backend.h | 14 ++++++++++++- > 2 files changed, 46 insertions(+), 3 deletions(-) > > diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c > index 963e6ce75b96..848a824c29c4 100644 > --- a/fs/notify/fsnotify.c > +++ b/fs/notify/fsnotify.c > @@ -440,7 +440,7 @@ static void fsnotify_iter_next(struct fsnotify_iter_info *iter_info) > } > > /* > - * fsnotify - This is the main call to fsnotify. > + * __fsnotify - This is the main call to fsnotify. > * > * The VFS calls into hook specific functions in linux/fsnotify.h. > * Those functions then in turn call here. Here will call out to all of the > @@ -459,7 +459,7 @@ static void fsnotify_iter_next(struct fsnotify_iter_info *iter_info) > * if both are non-NULL event may be reported to both. > * @cookie: inotify rename cookie > */ > -int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir, > +int __fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir, > const struct qstr *file_name, struct inode *inode, u32 cookie) > { > const struct path *path = fsnotify_data_path(data, data_type); > @@ -552,6 +552,37 @@ int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir, > > return ret; > } > + > +/* > + * Wrapper around fsnotify. The main functionality is to filter local events in > + * case the inode belongs to a filesystem that supports remote events > + */ > +int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir, > + const struct qstr *file_name, struct inode *inode, u32 cookie) > +{ > + > + if (inode != NULL || dir != NULL) { > + /* > + * Check if the fsnotify_event operation is available which > + * will let the remote inotify events go through and suppress > + * the local events > + */ > + if (inode && inode->i_op->fsnotify_event) { > + return inode->i_op->fsnotify_event(mask, data, > + data_type, dir, > + file_name, inode, > + cookie); > + } > + if (dir && dir->i_op->fsnotify_event) { > + return dir->i_op->fsnotify_event(mask, data, > + data_type, dir, > + file_name, inode, > + cookie); > + } > + } > + That's not the way to accomplish what you want to do. Assuming that we agree to let filesystem silence VFS fsnotify hooks it should be done using an inode flag, similar to file flag FMODE_NONOTIFY. But the reason you want to do that seems a bit odd. Duplicate events are going to be merged with fanotify and I think that you ruled out fanotify for the wrong reasons (you should have only ruled out permission events) Thanks, Amir.