From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH] VFS/inotify: send netlink messages when an inotify watch has been set or removed. Date: Sat, 7 Jan 2012 19:05:36 +0000 Message-ID: <20120107190536.GP23916@ZenIV.linux.org.uk> References: <4F084A4C.6080207@bononline.nl> <20120107143802.GM23916@ZenIV.linux.org.uk> <20120107155707.GO23916@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stef Bon , linux-fsdevel@vger.kernel.org, rlove@rlove.org, eparis@parisplace.org To: Stef Bon Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:34990 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753148Ab2AGTFk (ORCPT ); Sat, 7 Jan 2012 14:05:40 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Jan 07, 2012 at 05:59:10PM +0100, Stef Bon wrote: > Yes you've got a point here. Absolutly, the moving of a subtree is not > noticed by the fuse fs, and therefore cannot be taken into account. > And yes, I agree, that the only way to deal with that is "if you do > this with the fuse fs, strange things can happen type of warning". I'm > happy we agree on something! There are almost certainly some things we agree on, but that's not the *only* way to deal with that. "Don't use inotify" is another. And it's not just moving a subtree. mount --bind followed by umount of the original is another obvious example. So's having per-user namespaces, etc. Moreover, exact same example of a race would still apply without mount being involved - have user pass /proc/6969/fd/42/bar/barf to inotify_add_watch() and replace mount --move with dup2(). Passing the pathname is *hopeless* here. And IMNSHO so's relying on inotify in general - it's not a general-purpose API and any program relying on it being usable on an arbitrary part of tree is buggy.