All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, David Sterba <dsterba@suse.com>,
	Christoph Hellwig <hch@lst.de>, Joel Becker <jlbec@evilplan.org>,
	John Johansen <john.johansen@canonical.com>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3 00/10] Sort out fsnotify_nameremove() mess
Date: Mon, 27 May 2019 10:24:57 +0200	[thread overview]
Message-ID: <20190527082457.GE21124@kroah.com> (raw)
In-Reply-To: <20190526143411.11244-1-amir73il@gmail.com>

On Sun, May 26, 2019 at 05:34:01PM +0300, Amir Goldstein wrote:
> Jan,
> 
> For v3 I went with a straight forward approach.
> Filesystems that have fsnotify_{create,mkdir} hooks also get
> explicit fsnotify_{unlink,rmdir} hooks.
> 
> Hopefully, this approach is orthogonal to whatever changes Al is
> planning for recursive tree remove code, because in many of the
> cases, the hooks are added at the entry point for the recursive
> tree remove.
> 
> After looking closer at all the filesystems that were converted to
> simple_remove in v2, I decided to exempt another 3 filesystems from
> the fsnotify delete hooks: hypfs,qibfs and aafs.
> hypfs is pure cleanup (*). qibfs and aafs can remove dentry on user
> configuration change, but they do not generate create events, so it
> is less likely that users depend on the delete events.
> 
> That leaves configfs the only filesystem that gets the new delete hooks
> even though it does not have create hooks.

why doesn't configfs have create hooks?  That's what userspace does in
configfs, shouldn't it be notified about it?  Keeping it "unequal" seems
odd to me.


thanks,

greg k-h

  parent reply	other threads:[~2019-05-27  8:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-26 14:34 [PATCH v3 00/10] Sort out fsnotify_nameremove() mess Amir Goldstein
2019-05-26 14:34 ` [PATCH v3 01/10] fsnotify: add empty fsnotify_{unlink,rmdir}() hooks Amir Goldstein
2019-05-26 14:34 ` [PATCH v3 02/10] btrfs: call fsnotify_rmdir() hook Amir Goldstein
2019-05-26 14:34 ` [PATCH v3 03/10] rpc_pipefs: call fsnotify_{unlink,rmdir}() hooks Amir Goldstein
2019-05-27 10:53   ` Jan Kara
2019-05-27 13:26     ` Amir Goldstein
2019-05-27 14:00       ` Jan Kara
2019-05-30  5:43   ` Amir Goldstein
2019-05-30 12:16     ` Trond Myklebust
2019-05-26 14:34 ` [PATCH v3 04/10] tracefs: " Amir Goldstein
2019-06-13 16:53   ` Amir Goldstein
2019-08-30 19:48     ` Steven Rostedt
2019-09-02  8:46       ` Jan Kara
2019-05-26 14:34 ` [PATCH v3 05/10] devpts: call fsnotify_unlink() hook Amir Goldstein
2019-05-26 14:34 ` [PATCH v3 06/10] debugfs: simplify __debugfs_remove_file() Amir Goldstein
2019-05-30  5:49   ` Amir Goldstein
2019-05-30 12:27     ` Greg KH
2019-06-03 13:31   ` Greg Kroah-Hartman
2019-05-26 14:34 ` [PATCH v3 07/10] debugfs: call fsnotify_{unlink,rmdir}() hooks Amir Goldstein
2019-06-03 13:31   ` Greg Kroah-Hartman
2019-05-26 14:34 ` [PATCH v3 08/10] configfs: call fsnotify_rmdir() hook Amir Goldstein
2019-05-30  6:06   ` Amir Goldstein
2019-06-13 16:57     ` Amir Goldstein
2019-05-26 14:34 ` [PATCH v3 09/10] fsnotify: move fsnotify_nameremove() hook out of d_delete() Amir Goldstein
2019-05-26 14:34 ` [PATCH v3 10/10] fsnotify: get rid of fsnotify_nameremove() Amir Goldstein
2019-05-27  8:24 ` Greg Kroah-Hartman [this message]
2019-05-27  9:49   ` [PATCH v3 00/10] Sort out fsnotify_nameremove() mess Amir Goldstein
2019-05-27 11:41     ` Greg Kroah-Hartman
2019-05-27 11:59 ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190527082457.GE21124@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=amir73il@gmail.com \
    --cc=anna.schumaker@netapp.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jlbec@evilplan.org \
    --cc=john.johansen@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=trond.myklebust@hammerspace.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.