linux-kernel - Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)

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]

Date:	Fri, 26 Sep 2014 00:38:37 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Heinrich Schuchardt <xypron.debian@....de>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	John McCutchan <john@...nmccutchan.com>,
	Robert Love <rlove@...ve.org>,
	Eric Paris <eparis@...isplace.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrey Vagin <avagin@...nvz.org>
Subject: Re: [PATCH] fs: don't remove inotify watchers from alive inode-s (v2)

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@...e.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/