lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140917210122.GA31893@paralelels.com>
Date:	Thu, 18 Sep 2014 01:01:22 +0400
From:	Andrew Vagin <avagin@...allels.com>
To:	Jan Kara <jack@...e.cz>
CC:	Heinrich Schuchardt <xypron.debian@....de>,
	Al Viro <viro@...IV.linux.org.uk>,
	Andrey Vagin <avagin@...nvz.org>,
	<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	"John McCutchan" <john@...nmccutchan.com>,
	Robert Love <rlove@...ve.org>,
	Eric Paris <eparis@...isplace.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	"Pavel Emelyanov" <xemul@...allels.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Subject: Re: [PATCH] fs: don't remove inotify watchers from alive inode-s

On Tue, Sep 16, 2014 at 11:12:11PM +0200, Jan Kara wrote:
> On Sat 13-09-14 18:15:09, Heinrich Schuchardt wrote:
> > On Tue 09-09-14 02:27:12, Al Viro wrote:
> > http://lkml.org/lkml/2014/9/8/762
> > > I agree that it changes user-visible ABI and I agree the behavior
> > > isn't really specified in the manpage.
> > 
> > Shouldn't we start with putting the expected behavior into the
> > manpage before patching the code? I am missing a patch for
> > man7/inotify.7.
>   Good idea. Thanks for bringing this up. And ideally we should write it
> down before settling for a solution to this problem. Because when thinking
> about it again, some details of the behavior are still vague.
> 
> > On Mon, Sep 08, 2014 at 04:01:56PM +0400, Andrey Vagin wrote:
> > http://lkml.org/lkml/2014/9/8/219
> > >
> > > 	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\n");
> > > 	read_evetns(fd);
> > >
> > > 	close(deleted);
> > > 	printf(" --- close\n");
> > > 	read_evetns(fd);
> > >
> > > Without this patch:
> > >   --- unlink
> > > 4	(IN_ATTRIB)
> > > 400	(IN_DELETE_SELF)
> > > 8000	(IN_IGNORED)
> > >   --- close
> > > FAIL
> > >
> > > With this patch:
> > >   --- unlink
> > > 4	(IN_ATTRIB)
> > > 400	(IN_DELETE_SELF)
> > >   --- close
> > > 8	(IN_CLOSE_WRITE)
> > > 400	(IN_DELETE_SELF)
> > > 8000	(IN_IGNORED)
> > > PASS
> > 
> > Shouldn't the second IN_DELETE_SELF occur before
> > --- close ?
> > Why is IN_CLOSE_WRITE created?
>   So I would like events to be generated until the watched inode really
> gets deleted. This way simple (non-hardlinked) file behaves and that's what
> seems "natural". In this light generating IN_CLOSE_WRITE is what we want to
> do.
> 
> Generation of IN_DELETE_SELF is less obvious I think. Do we want to
> generate IN_DELETE_SELF for each hardlink to the inode that gets removed? I
> don't think so (this actually would be too visible user API change IMHO).
> To match the single link case I think we want to generate IN_DELETE_SELF
> when the last link to the file is removed. But then generating it twice
> like we would do with the above patch is wrong... Opinions?

I think you are right. Could you look at the attached patch? Pay your
attention to the description. This patch removes differences of
behaviours for two equivalent cases. And the resulting behavior is equal
for one of these case.

If it looks good for you, I will send this patch together with the patch
for the man page.

Thank you and Heinrich for the comments and advices.

Thanks,
Andrey
> 
> 								Honza
> -- 
> Jan Kara <jack@...e.cz>
> SUSE Labs, CR

View attachment "0001-fs-don-t-remove-inotify-watchers-from-alive-inode-s-.patch" of type "text/plain" (3862 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ