Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752005AbdCPKjF (ORCPT ); Thu, 16 Mar 2017 06:39:05 -0400 Received: from mx2.suse.de ([195.135.220.15]:43899 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbdCPKjD (ORCPT ); Thu, 16 Mar 2017 06:39:03 -0400 Date: Thu, 16 Mar 2017 11:38:59 +0100 From: Jan Kara To: Amir Goldstein Cc: Jan Kara , Filip =?utf-8?B?xaB0xJtkcm9uc2vDvQ==?= , linux-fsdevel , linux-kernel , Alexander Viro Subject: Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Message-ID: <20170316103859.GR12989@quack2.suse.cz> References: <20170315140536.GI12989@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1471 Lines: 42 On Wed 15-03-17 16:34:11, Amir Goldstein wrote: > On Wed, Mar 15, 2017 at 4:05 PM, Jan Kara wrote: > >> So the string fields in my proposal are optional. > >> userspace opts-in to get them by specifying the FAN_EVENT_INFO_NAME flag: > >> > >> fanotify_init(FAN_CLOEXEC | FAN_CLASS_NOTIF | > >> FAN_EVENT_INFO_PARENT | FAN_EVENT_INFO_NAME, > >> > >> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events > >> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name. > > > > So when thinking about this again, I'm again concerned that the names need > > not tell userspace what it thinks. I know we already discussed this but > > in our last discussion I think I forgot to point out that inotify directory > > events (and fanotify would be the same AFAICT) may come out of order compared > > to real filesystem changes. E.g. sequence: > > > > Task 1 Task 2 > > > > mv a b > > mv b c > > > > may come out of inotify as: > > > > IN_MOVED_FROM "b" COOKIE 1 > > IN_MOVED_TO "c" COOKIE 1 > > IN_MOVED_FROM "a" COOKIE 2 > > IN_MOVED_TO "b" COOKIE 2 > > > > Really? How come? > > fsnotify_move() inside vfs_rename() is serialized with lock_rename() Sorry, I got confused by the unlocking in vfs_rename() however that unlocks only the moved file / directory but not the directory in which the rename is happening. Taking my objection back. Honza -- Jan Kara SUSE Labs, CR