linux-kernel - Re: [PATCH] autofs: show pipe inode in mount options

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: <1452237640.2973.19.camel@themaw.net>
Date:	Fri, 08 Jan 2016 15:20:40 +0800
From:	Ian Kent <raven@...maw.net>
To:	skinsbursky@...tuozzo.com
Cc:	criu@...nvz.org, autofs@...r.kernel.org,
	linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH] autofs: show pipe inode in mount options

On Thu, 2016-01-07 at 16:46 +0100, Stanislav Kinsburskiy wrote:
> Good day, gentlemen.
> 
> Could you update, what's the status with this patch?
> Without it it's impossible to match process pipe with kernel pipe,
> while 
> this is "must have" to be able to migrate AutoFS via CRIU.

Right, I did mean to reply to this mail but have been distracted by
family stuff.

I don't know what CRIU is and people looking at changelog entries
shouldn't need to do a web search to find out.

Could you change it a little.

I'm also not sure whether to forward this (assuming the description is
updated a little) to Al or to include it in the series to rename
autofs4 to autofs that I'm hoping to ask be included in linux-next
fairly soon.

Passing it on to Al will likely interfere with the series coming from
linux-next so that could be bit of a hassle.

Another thing I'm wondering about is the order this entry will appear
at in the options. You order choice is sensible though and autofs
shouldn't have a problem with the inserted option but other
applications might.

Finally, and perhaps most importantly, I don't get what your trying to
do, you also haven't given any clues to that in the patch dscription.

IOW how do you expect to use this.

> 
> 
> 16.12.2015 13:02, Stanislav Kinsburskiy пишет:
> > This is required for CRIU to migrate a mount point, when write end
> > in user
> > space is closed.

Like I said what does this mean.

autofs doesn't need this when it re-constructs a mount tree from
existing mounts on re-start or after a SIGKILL on the automount
process.

How is this different and how will it be used?

The question to be answered here is "is this the best way to do it and
will it work for the autofs mount types you expect it to"?

> > To be able to migrate such mount, read end of the pipe have to be
> > searched
> > within autofs master process, and pipe inode will be used as a key.
> > 
> > Signed-off-by: Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>
> > ---
> >   fs/autofs4/inode.c |    4 ++++
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/fs/autofs4/inode.c b/fs/autofs4/inode.c
> > index a3ae0b2..16f875a 100644
> > --- a/fs/autofs4/inode.c
> > +++ b/fs/autofs4/inode.c
> > @@ -77,6 +77,10 @@ static int autofs4_show_options(struct seq_file
> > *m, struct dentry *root)
> >   		return 0;
> >   
> >   	seq_printf(m, ",fd=%d", sbi->pipefd);
> > +	if (sbi->pipe)
> > +		seq_printf(m, ",pipe_ino=%ld", sbi->pipe->f_inode
> > ->i_ino);
> > +	else
> > +		seq_printf(m, ",pipe_ino=-1");
> >   	if (!uid_eq(root_inode->i_uid, GLOBAL_ROOT_UID))
> >   		seq_printf(m, ",uid=%u",
> >   			from_kuid_munged(&init_user_ns,
> > root_inode->i_uid));
> > 
>