All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
@ 2014-09-19 15:45 Andrey Vagin
  2014-09-19 15:56 ` [PATCH] inotify.7: describe ambiguous behaviour of IN_DELETE_SELF Andrey Vagin
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Andrey Vagin @ 2014-09-19 15:45 UTC (permalink / raw)
  To: linux-fsdevel
  Cc: linux-kernel, Heinrich Schuchardt, Jan Kara,
	Michael Kerrisk (man-pages),
	Andrey Vagin, Alexander Viro, John McCutchan, Robert Love,
	Eric Paris, Cyrill Gorcunov, Pavel Emelyanov

Currently watchers are removed in dentry_iput(), if n_link is zero.  But
other detries can be linked with this inode.

For example if we create two hard links, open the first one and set an
inotify watcher on one of them.  Then if we remove the opened file and
then another file, the inotify watcher will be removed. But we will have
the alive file descriptor, which allows us to generate more events.

And here is another behaviour, if files are removed in another order.
The watcher will not be removed and we will keep getting inotify events
for that inode.

This patch removes difference of behaviours for these cases. Watchers
are removed, only if nlink is zero and i_dentry list is empty. The
resulting behaviour is the same with what has been described in the
second case.

Look at a following example:

	fd = inotify_init1(IN_NONBLOCK);
	deleted = open(path, O_CREAT | O_TRUNC | O_WRONLY, 0666);
	link(path, path_link);

	wd_deleted = inotify_add_watch(fd, path_link, IN_ALL_EVENTS);

	unlink(path);
	unlink(path_link);

	printf(" --- unlink path, path_link\n");
	read_evetns(fd);

	close(deleted);
	printf(" --- close\n");
	read_evetns(fd);
	printf(" --- end\n");

We expect to get the same set of events for this case and for the
case, when files are deleted in another order. But now we get the
different set of events.

Without this patch:
The first case, when "path" is deleted before "path_link"
 --- unlink path, path_link
4	(IN_ATTRIB)
400	(IN_DELETE_SELF)
8000	(IN_IGNORED)
 --- close
 --- end

and for the case, when "path_link" is deleted before "path"
 --- unlink path_link, path
4	(IN_ATTRIB)
 --- close
8	(IN_CLOSE_WRITE)
400	(IN_DELETE_SELF)
8000	(IN_IGNORED)
 --- end

With this patch we have the same output for both cases:
 --- unlink
4	(IN_ATTRIB)
 --- close
8	(IN_CLOSE_WRITE)
400	(IN_DELETE_SELF)
8000	(IN_IGNORED)
 --- end
PASS

v2: generate IN_DELETE_SELF when the last link to the file is removed

Reviewed-by: Jan Kara <jack@suse.cz>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Heinrich Schuchardt <xypron.debian@gmx.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: John McCutchan <john@johnmccutchan.com>
Cc: Robert Love <rlove@rlove.org>
Cc: Eric Paris <eparis@parisplace.org>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
---
 fs/dcache.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 7a5b514..3a0e3bc 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -278,12 +278,15 @@ static void dentry_iput(struct dentry * dentry)
 	__releases(dentry->d_inode->i_lock)
 {
 	struct inode *inode = dentry->d_inode;
+	bool last_dentry;
+
 	if (inode) {
 		dentry->d_inode = NULL;
 		hlist_del_init(&dentry->d_alias);
+		last_dentry = hlist_empty(&inode->i_dentry);
 		spin_unlock(&dentry->d_lock);
 		spin_unlock(&inode->i_lock);
-		if (!inode->i_nlink)
+		if (!inode->i_nlink && last_dentry)
 			fsnotify_inoderemove(inode);
 		if (dentry->d_op && dentry->d_op->d_iput)
 			dentry->d_op->d_iput(dentry, inode);
@@ -303,13 +306,16 @@ static void dentry_unlink_inode(struct dentry * dentry)
 	__releases(dentry->d_inode->i_lock)
 {
 	struct inode *inode = dentry->d_inode;
+	bool last_dentry;
+
 	__d_clear_type(dentry);
 	dentry->d_inode = NULL;
 	hlist_del_init(&dentry->d_alias);
 	dentry_rcuwalk_barrier(dentry);
+	last_dentry = hlist_empty(&inode->i_dentry);
 	spin_unlock(&dentry->d_lock);
 	spin_unlock(&inode->i_lock);
-	if (!inode->i_nlink)
+	if (!inode->i_nlink && last_dentry)
 		fsnotify_inoderemove(inode);
 	if (dentry->d_op && dentry->d_op->d_iput)
 		dentry->d_op->d_iput(dentry, inode);
-- 
1.9.3


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH] inotify.7: describe ambiguous behaviour of IN_DELETE_SELF
  2014-09-19 15:45 [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Andrey Vagin
@ 2014-09-19 15:56 ` Andrey Vagin
  2014-09-19 16:15 ` [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Cyrill Gorcunov
  2014-09-24 10:51 ` Jan Kara
  2 siblings, 0 replies; 9+ messages in thread
From: Andrey Vagin @ 2014-09-19 15:56 UTC (permalink / raw)
  To: linux-fsdevel
  Cc: linux-kernel, Heinrich Schuchardt, Jan Kara,
	Michael Kerrisk (man-pages),
	Alexander Viro, Andrey Vagin

Since kernel 3.18, IN_DELETE_SELF occurs only if nobody uses an object.
Before, if we have two hardlinks where one of them  is  opened and  we
delete  the opened  file  before  the second one, we receive
IN_DELETE_SELF.  It's wrong, because the file remains opened. If files
are deleted in another order, we don't receive IN_DELETE_SELF as expected.

This patch can be committed only after the kernel patch:
"[PATCH] fs: don't remove inotify watchers from alive inode-s (v2)"

Signed-off-by: Andrey Vagin <avagin@openvz.org>
---
 man7/inotify.7 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/man7/inotify.7 b/man7/inotify.7
index e1cabe2..b7a6e2f 100644
--- a/man7/inotify.7
+++ b/man7/inotify.7
@@ -504,6 +504,19 @@ if the older had not yet been read)
 instead checked if the most recent event could be coalesced with the
 .I oldest
 unread event.
+
+Since kernel 3.18,
+.\" commit XXXXXX
+.B IN_DELETE_SELF
+occurs only if nobody uses an object. Before, if we have two hardlinks where
+one of them is opened and we delete the opened file before the second one, we
+receive
+.B IN_DELETE_SELF.
+It's wrong, because the file remains opened. If files are deleted in another
+order, we don't receive
+.B IN_DELETE_SELF
+as expected.
+
 .SH SEE ALSO
 .BR inotifywait (1),
 .BR inotifywatch (1),
-- 
1.9.3


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-09-19 15:45 [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Andrey Vagin
  2014-09-19 15:56 ` [PATCH] inotify.7: describe ambiguous behaviour of IN_DELETE_SELF Andrey Vagin
@ 2014-09-19 16:15 ` Cyrill Gorcunov
  2014-09-24 10:51 ` Jan Kara
  2 siblings, 0 replies; 9+ messages in thread
From: Cyrill Gorcunov @ 2014-09-19 16:15 UTC (permalink / raw)
  To: Andrey Vagin
  Cc: linux-fsdevel, linux-kernel, Heinrich Schuchardt, Jan Kara,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Pavel Emelyanov

On Fri, Sep 19, 2014 at 07:45:16PM +0400, Andrey Vagin wrote:
> Currently watchers are removed in dentry_iput(), if n_link is zero.  But
> other detries can be linked with this inode.
> 
...
> 
> v2: generate IN_DELETE_SELF when the last link to the file is removed
> 
> Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-09-19 15:45 [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Andrey Vagin
  2014-09-19 15:56 ` [PATCH] inotify.7: describe ambiguous behaviour of IN_DELETE_SELF Andrey Vagin
  2014-09-19 16:15 ` [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Cyrill Gorcunov
@ 2014-09-24 10:51 ` Jan Kara
  2014-09-24 20:19   ` Andrew Morton
  2 siblings, 1 reply; 9+ messages in thread
From: Jan Kara @ 2014-09-24 10:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-fsdevel, linux-kernel, Heinrich Schuchardt, Jan Kara,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Cyrill Gorcunov, Pavel Emelyanov, Andrey Vagin

  Hello,

  Andrew, what do you think about the patch below? Al objected that it
changes userspace visible behavior some time ago and then he didn't react
to our explanations...
								Honza

On Fri 19-09-14 19:45:16, Andrey Vagin wrote:
> Currently watchers are removed in dentry_iput(), if n_link is zero.  But
> other detries can be linked with this inode.
> 
> For example if we create two hard links, open the first one and set an
> inotify watcher on one of them.  Then if we remove the opened file and
> then another file, the inotify watcher will be removed. But we will have
> the alive file descriptor, which allows us to generate more events.
> 
> And here is another behaviour, if files are removed in another order.
> The watcher will not be removed and we will keep getting inotify events
> for that inode.
> 
> This patch removes difference of behaviours for these cases. Watchers
> are removed, only if nlink is zero and i_dentry list is empty. The
> resulting behaviour is the same with what has been described in the
> second case.
> 
> Look at a following example:
> 
> 	fd = inotify_init1(IN_NONBLOCK);
> 	deleted = open(path, O_CREAT | O_TRUNC | O_WRONLY, 0666);
> 	link(path, path_link);
> 
> 	wd_deleted = inotify_add_watch(fd, path_link, IN_ALL_EVENTS);
> 
> 	unlink(path);
> 	unlink(path_link);
> 
> 	printf(" --- unlink path, path_link\n");
> 	read_evetns(fd);
> 
> 	close(deleted);
> 	printf(" --- close\n");
> 	read_evetns(fd);
> 	printf(" --- end\n");
> 
> We expect to get the same set of events for this case and for the
> case, when files are deleted in another order. But now we get the
> different set of events.
> 
> Without this patch:
> The first case, when "path" is deleted before "path_link"
>  --- unlink path, path_link
> 4	(IN_ATTRIB)
> 400	(IN_DELETE_SELF)
> 8000	(IN_IGNORED)
>  --- close
>  --- end
> 
> and for the case, when "path_link" is deleted before "path"
>  --- unlink path_link, path
> 4	(IN_ATTRIB)
>  --- close
> 8	(IN_CLOSE_WRITE)
> 400	(IN_DELETE_SELF)
> 8000	(IN_IGNORED)
>  --- end
> 
> With this patch we have the same output for both cases:
>  --- unlink
> 4	(IN_ATTRIB)
>  --- close
> 8	(IN_CLOSE_WRITE)
> 400	(IN_DELETE_SELF)
> 8000	(IN_IGNORED)
>  --- end
> PASS
> 
> v2: generate IN_DELETE_SELF when the last link to the file is removed
> 
> Reviewed-by: Jan Kara <jack@suse.cz>
> Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
> Cc: Heinrich Schuchardt <xypron.debian@gmx.de>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: John McCutchan <john@johnmccutchan.com>
> Cc: Robert Love <rlove@rlove.org>
> Cc: Eric Paris <eparis@parisplace.org>
> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> Cc: Pavel Emelyanov <xemul@parallels.com>
> Signed-off-by: Andrey Vagin <avagin@openvz.org>
> ---
>  fs/dcache.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 7a5b514..3a0e3bc 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -278,12 +278,15 @@ static void dentry_iput(struct dentry * dentry)
>  	__releases(dentry->d_inode->i_lock)
>  {
>  	struct inode *inode = dentry->d_inode;
> +	bool last_dentry;
> +
>  	if (inode) {
>  		dentry->d_inode = NULL;
>  		hlist_del_init(&dentry->d_alias);
> +		last_dentry = hlist_empty(&inode->i_dentry);
>  		spin_unlock(&dentry->d_lock);
>  		spin_unlock(&inode->i_lock);
> -		if (!inode->i_nlink)
> +		if (!inode->i_nlink && last_dentry)
>  			fsnotify_inoderemove(inode);
>  		if (dentry->d_op && dentry->d_op->d_iput)
>  			dentry->d_op->d_iput(dentry, inode);
> @@ -303,13 +306,16 @@ static void dentry_unlink_inode(struct dentry * dentry)
>  	__releases(dentry->d_inode->i_lock)
>  {
>  	struct inode *inode = dentry->d_inode;
> +	bool last_dentry;
> +
>  	__d_clear_type(dentry);
>  	dentry->d_inode = NULL;
>  	hlist_del_init(&dentry->d_alias);
>  	dentry_rcuwalk_barrier(dentry);
> +	last_dentry = hlist_empty(&inode->i_dentry);
>  	spin_unlock(&dentry->d_lock);
>  	spin_unlock(&inode->i_lock);
> -	if (!inode->i_nlink)
> +	if (!inode->i_nlink && last_dentry)
>  		fsnotify_inoderemove(inode);
>  	if (dentry->d_op && dentry->d_op->d_iput)
>  		dentry->d_op->d_iput(dentry, inode);
> -- 
> 1.9.3
> 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-09-24 10:51 ` Jan Kara
@ 2014-09-24 20:19   ` Andrew Morton
  2014-09-25  8:30     ` Jan Kara
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2014-09-24 20:19 UTC (permalink / raw)
  To: Jan Kara
  Cc: linux-fsdevel, linux-kernel, Heinrich Schuchardt,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Cyrill Gorcunov, Pavel Emelyanov, Andrey Vagin

On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara <jack@suse.cz> wrote:

>   Hello,
> 
>   Andrew, what do you think about the patch below? Al objected that it
> changes userspace visible behavior some time ago and then he didn't react
> to our explanations...

Difficult situation.  There's some really important information missing
from the changelog:

- Who cares?  Is there some real application which is hurting from
  the current situation?  If so, who, what, how and why.  If not, then
  why change anything?

- A description of the userspace API change impact.  How did the
  interface change?  What is the risk of this change causing damage to
  real applications?

If we can answer these questions then we're in a position to make the
pain-versus-gain tradeoff decision.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-09-24 20:19   ` Andrew Morton
@ 2014-09-25  8:30     ` Jan Kara
  2014-09-25 20:38       ` Cyrill Gorcunov
  2014-10-02 10:45       ` Jan Kara
  0 siblings, 2 replies; 9+ messages in thread
From: Jan Kara @ 2014-09-25  8:30 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jan Kara, linux-fsdevel, linux-kernel, Heinrich Schuchardt,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Cyrill Gorcunov, Pavel Emelyanov, Andrey Vagin

On Wed 24-09-14 13:19:47, Andrew Morton wrote:
> On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara <jack@suse.cz> wrote:
> 
> >   Hello,
> > 
> >   Andrew, what do you think about the patch below? Al objected that it
> > changes userspace visible behavior some time ago and then he didn't react
> > to our explanations...
> 
> Difficult situation.  There's some really important information missing
> from the changelog:
> 
> - Who cares?  Is there some real application which is hurting from
>   the current situation?  If so, who, what, how and why.  If not, then
>   why change anything?
  I believe Openvz guys hit this in their application but I'll defer to
them for more details.

> - A description of the userspace API change impact.  How did the
>   interface change?  What is the risk of this change causing damage to
>   real applications?
  I believe this was covered in the changelog. Without the patch depending
on the order of unlinks for hardlinked file you sometimes get events:
4       (IN_ATTRIB)
400     (IN_DELETE_SELF)
8000    (IN_IGNORED)

and sometimes you get events:
4       (IN_ATTRIB)
<possibly more events happening for unlinked file>
8       (IN_CLOSE_WRITE)
400     (IN_DELETE_SELF)
8000    (IN_IGNORED)

With the patch you'll always have the second case. So without the patch you
don't receive some events if the file has at least 2 hardlinks and then
gets unlinked. I think the risk that some application relies on *not* getting
those events is pretty low (especially since in the common case of file
without hardlinks you will get all those events).

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-09-25  8:30     ` Jan Kara
@ 2014-09-25 20:38       ` Cyrill Gorcunov
  2014-10-02 10:45       ` Jan Kara
  1 sibling, 0 replies; 9+ messages in thread
From: Cyrill Gorcunov @ 2014-09-25 20:38 UTC (permalink / raw)
  To: Jan Kara
  Cc: Andrew Morton, linux-fsdevel, linux-kernel, Heinrich Schuchardt,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Pavel Emelyanov, Andrey Vagin

On Thu, Sep 25, 2014 at 10:30:10AM +0200, Jan Kara wrote:
> On Wed 24-09-14 13:19:47, Andrew Morton wrote:
> > On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara <jack@suse.cz> wrote:
> > 
> > >   Hello,
> > > 
> > >   Andrew, what do you think about the patch below? Al objected that it
> > > changes userspace visible behavior some time ago and then he didn't react
> > > to our explanations...
> > 
> > Difficult situation.  There's some really important information missing
> > from the changelog:
> > 
> > - Who cares?  Is there some real application which is hurting from
> >   the current situation?  If so, who, what, how and why.  If not, then
> >   why change anything?
>   I believe Openvz guys hit this in their application but I'll defer to
> them for more details.

Hi, sorry for delay! Indeed we found this weird behaviour while been testing
the results of restore of deleted files. When criu observes opened descriptor on
deleted file its contents get written into criu image file which we call "ghost"
files. On restore we create a temporary ghost file with some unique name. Then
we restore file descriptors which were opened at the moment of checkpoint:
we create a hardlink to this ghost file, then open it and this is done for every
descriptor we need to recover. Then if there were a watch mark on the ghost
file we restore them as well but at the end we need to do a cleanup and finally
remove the ghost file itself which cause the problem mentioned in Andrew's changelog
to appear -- when we remove ghost file inode->n_link becomes 0 thus our restored
inotify are dropped off by the kernel while here still opened files are floating
around. I can't say that it's catastrophical but if there a chance to fix it
on kernel level making events flow more sane, this would be just great, also
our primary target is to make c/r process transparent to the userspace and
without the patch i fear we can't reach it.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-09-25  8:30     ` Jan Kara
  2014-09-25 20:38       ` Cyrill Gorcunov
@ 2014-10-02 10:45       ` Jan Kara
  2014-10-02 19:44         ` Andrew Morton
  1 sibling, 1 reply; 9+ messages in thread
From: Jan Kara @ 2014-10-02 10:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jan Kara, linux-fsdevel, linux-kernel, Heinrich Schuchardt,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Cyrill Gorcunov, Pavel Emelyanov, Andrey Vagin

On Thu 25-09-14 10:30:10, Jan Kara wrote:
> On Wed 24-09-14 13:19:47, Andrew Morton wrote:
> > On Wed, 24 Sep 2014 12:51:55 +0200 Jan Kara <jack@suse.cz> wrote:
> > 
> > >   Hello,
> > > 
> > >   Andrew, what do you think about the patch below? Al objected that it
> > > changes userspace visible behavior some time ago and then he didn't react
> > > to our explanations...
> > 
> > Difficult situation.  There's some really important information missing
> > from the changelog:
> > 
> > - Who cares?  Is there some real application which is hurting from
> >   the current situation?  If so, who, what, how and why.  If not, then
> >   why change anything?
>   I believe Openvz guys hit this in their application but I'll defer to
> them for more details.
> 
> > - A description of the userspace API change impact.  How did the
> >   interface change?  What is the risk of this change causing damage to
> >   real applications?
>   I believe this was covered in the changelog. Without the patch depending
> on the order of unlinks for hardlinked file you sometimes get events:
> 4       (IN_ATTRIB)
> 400     (IN_DELETE_SELF)
> 8000    (IN_IGNORED)
> 
> and sometimes you get events:
> 4       (IN_ATTRIB)
> <possibly more events happening for unlinked file>
> 8       (IN_CLOSE_WRITE)
> 400     (IN_DELETE_SELF)
> 8000    (IN_IGNORED)
> 
> With the patch you'll always have the second case. So without the patch you
> don't receive some events if the file has at least 2 hardlinks and then
> gets unlinked. I think the risk that some application relies on *not* getting
> those events is pretty low (especially since in the common case of file
> without hardlinks you will get all those events).
  Ping Andrew? Do you still need more info or are you now OK to merge the
patch?

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)
  2014-10-02 10:45       ` Jan Kara
@ 2014-10-02 19:44         ` Andrew Morton
  0 siblings, 0 replies; 9+ messages in thread
From: Andrew Morton @ 2014-10-02 19:44 UTC (permalink / raw)
  To: Jan Kara
  Cc: linux-fsdevel, linux-kernel, Heinrich Schuchardt,
	Michael Kerrisk (man-pages),
	Alexander Viro, John McCutchan, Robert Love, Eric Paris,
	Cyrill Gorcunov, Pavel Emelyanov, Andrey Vagin

On Thu, 2 Oct 2014 12:45:52 +0200 Jan Kara <jack@suse.cz> wrote:

> > With the patch you'll always have the second case. So without the patch you
> > don't receive some events if the file has at least 2 hardlinks and then
> > gets unlinked. I think the risk that some application relies on *not* getting
> > those events is pretty low (especially since in the common case of file
> > without hardlinks you will get all those events).
>   Ping Andrew? Do you still need more info or are you now OK to merge the
> patch?

Resend please, with a completed changelog.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-10-02 19:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-19 15:45 [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Andrey Vagin
2014-09-19 15:56 ` [PATCH] inotify.7: describe ambiguous behaviour of IN_DELETE_SELF Andrey Vagin
2014-09-19 16:15 ` [PATCH] fs: don't remove inotify watchers from alive inode-s (v2) Cyrill Gorcunov
2014-09-24 10:51 ` Jan Kara
2014-09-24 20:19   ` Andrew Morton
2014-09-25  8:30     ` Jan Kara
2014-09-25 20:38       ` Cyrill Gorcunov
2014-10-02 10:45       ` Jan Kara
2014-10-02 19:44         ` Andrew Morton

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.