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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 CD0DDC43460 for ; Tue, 6 Apr 2021 08:36:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 99448613C0 for ; Tue, 6 Apr 2021 08:36:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239927AbhDFIgQ (ORCPT ); Tue, 6 Apr 2021 04:36:16 -0400 Received: from mx2.suse.de ([195.135.220.15]:33036 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234953AbhDFIgP (ORCPT ); Tue, 6 Apr 2021 04:36:15 -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 45AC4B0C6; Tue, 6 Apr 2021 08:35:57 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id F21341F2B70; Tue, 6 Apr 2021 10:35:56 +0200 (CEST) Date: Tue, 6 Apr 2021 10:35:56 +0200 From: Jan Kara To: Amir Goldstein Cc: Jan Kara , Christian Brauner , linux-fsdevel , Linux API , Miklos Szeredi , "J. Bruce Fields" Subject: Re: fsnotify path hooks Message-ID: <20210406083556.GA19407@quack2.suse.cz> References: <20210330141703.lkttbuflr5z5ia7f@wittgenstein> <20210331094604.xxbjl3krhqtwcaup@wittgenstein> <20210331125412.GI30749@quack2.suse.cz> <20210401102947.GA29690@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) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu 01-04-21 17:18:05, Amir Goldstein wrote: > > > > > Also I'm somewhat uneasy that it is random (from > > > > > userspace POV) when path event is generated and when not (at least that's > > > > > my impression from the patch - maybe I'm wrong). How difficult would it be > > > > > to get rid of it? I mean what if we just moved say fsnotify_create() call > > > > > wholly up the stack? It would mean more explicit calls to fsnotify_create() > > > > > from filesystems - as far as I'm looking nfsd, overlayfs, cachefiles, > > > > > ecryptfs. But that would seem to be manageable. Also, to maintain sanity, > > > > > > > > 1. I don't think we can do that for all the fsnotify_create() hooks, such as > > > > debugfs for example > > > > 2. It is useless to pass the mount from overlayfs to fsnotify, its a private > > > > mount that users cannot set a mark on anyway and Christian has > > > > promised to propose the same change for cachefiles and ecryptfs, > > > > so I think it's not worth the churn in those call sites > > > > 3. I am uneasy with removing the fsnotify hooks from vfs helpers and > > > > trusting that new callers of vfs_create() will remember to add the high > > > > level hooks, so I prefer the existing behavior remains for such callers > > > > > > > > > > So I read your proposal the wrong way. > > > You meant move fsnotify_create() up *without* passing mount context > > > from overlayfs and friends. > > > > Well, I was thinking that we could find appropriate mount context for > > overlayfs or ecryptfs (which just shows how little I know about these > > filesystems ;) I didn't think of e.g. debugfs. Anyway, if we can make > > mountpoint marks work for directory events at least for most filesystems, I > > think that is OK as well. However it would be then needed to detect whether > > a given filesystem actually supports mount marks for dir events and if not, > > report error from fanotify_mark() instead of silently not generating > > events. > > > > It's not about "filesystems that support mount marks". > mount marks will work perfectly well on overlayfs. > > The thing is if you place a mount mark on the underlying store of > overlayfs (say xfs) and then files are created/deleted by the > overlayfs driver (in xfs) you wont get any events, because > overlayfs uses a private mount clone to perform underlying operations. OK, understood. > So while we CAN get the overlayfs underlying layer mount context > it is irrelevant because no user can setup a mount mark on that > private mount, so no need to bother calling the path hooks. > > This is not the case with nfsd IMO. > With nfsd, when "exporting" a path to clients, nfsd is really exporting > a specific mount (and keeping that mount busy too). > It can even export whole mount topologies. > > But then again, getting the mount context in every nfsd operation > is easy, there is an export context to client requests and the export > context has the exported path. > > Therefore, nfsd is my only user using the vfs helpers that is expected > to call the fsnotify path hooks (other than syscalls). I agree. Honza -- Jan Kara SUSE Labs, CR