autofs: show pipe inode in mount options

This is required for CRIU to migrate a mount point, when write end in user space is closed.
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 <[email protected]>

---
  fs/autofs4/inode.c |    4 ++++
  1 file changed, 4 insertions(+)

fs/autofs4/inode.c +0 -0

index a3ae0b2..16f875a 100644

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.

16.12.2015 13:02, Stanislav Kinsburskiy пишет:

Quoted 3 lines

This is required for CRIU to migrate a mount point, when write end in user
space is closed.

Quoted 17 lines

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 <[email protected]>

---
  fs/autofs4/inode.c |    4 ++++
  1 file changed, 4 insertions(+)

fs/autofs4/inode.c +0 -0

index a3ae0b2..16f875a 100644
@@ -77,6 +77,10 @@ static int autofs4_show_options(struct seq_file
 *m, struct dentry *root)
  		return 0;
 

Quoted 11 lines

fs/autofs4/inode.c +4 -1

  	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));

Quoted 6 lines

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.

Quoted 5 lines

16.12.2015 13:02, Stanislav Kinsburskiy пишет:

Quoted 3 lines

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"?

Quoted 17 lines

Quoted 17 lines

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 <[email protected]>

---
   fs/autofs4/inode.c |    4 ++++
   1 file changed, 4 insertions(+)

fs/autofs4/inode.c +0 -0

index a3ae0b2..16f875a 100644
@@ -77,6 +77,10 @@ static int autofs4_show_options(struct seq_file
 *m, struct dentry *root)
   		return 0;
 

Quoted 11 lines

Quoted 11 lines

fs/autofs4/inode.c +4 -1

   	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));

08.01.2016 08:20, Ian Kent пишет:

Quoted 8 lines · Stanislav Kinsburskiy

Quoted 7 lines

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.

Quoted 7 lines

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.

Fair enough. I'll resend with more descriptive message. But first I would like to clarify to you the problem root and why it's
done like this.

Quoted 5 lines

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.

Here I don't know, what's better. Of course Al can take it as well. But,
probably, first would be nice to make sure, that this solution is the best one.
Description of the problem is below.

Quoted 9 lines

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.

I should put it at the end, probably?

Quoted 19 lines

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.

Quoted 6 lines

16.12.2015 13:02, Stanislav Kinsburskiy пишет:

Quoted 4 lines

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.

Quoted 5 lines

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"?

So, here is a brief description of the problem.
To migrate autofs mount, one have to reconstruct control pipe between kernel and autofs master.
There are two cases I'm wiling to support:
1) Automount binary (autofs package). This program is very gentle and it
doesn't close write end of the pipe after mount.
2) Systemd. This program closes write end of the pipe once the mount is
done.

Quoted 66 lines

08.01.2016 08:20, Ian Kent пишет:

Quoted 8 lines · Stanislav Kinsburskiy

Quoted 7 lines

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.

Quoted 7 lines

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.

Fair enough. I'll resend with more descriptive message. But first I would like to clarify to you the problem root and why it's
done like this.

Quoted 5 lines

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.

Here I don't know, what's better. Of course Al can take it as well. But,
probably, first would be nice to make sure, that this solution is the best one.
Description of the problem is below.

Quoted 9 lines

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.

I should put it at the end, probably?

Quoted 18 lines

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.

Quoted 5 lines

16.12.2015 13:02, Stanislav Kinsburskiy пишет:

Quoted 4 lines

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.

Quoted 5 lines

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"?

Quoted 10 lines

So, here is a brief description of the problem.
To migrate autofs mount, one have to reconstruct control pipe between kernel and autofs master.
There are two cases I'm wiling to support:
1) Automount binary (autofs package). This program is very gentle and it
doesn't close write end of the pipe after mount.
2) Systemd. This program closes write end of the pipe once the mount is
done.

I must admit I'm having trouble understanding the description. Give me a little time with it.

I don't know how systemd works with autofs mounts only that it uses the autofs direct mount type.

autofs uses both indirect and direct mounts and both can have offsets (from the kernel POV semantically direct mounts). So there is quite a bit to worry about beside the kernel pipe.

Anyway, it seems your only concern is the kernel pipe and I wonder why you can't just set the mount catatonic (in autofs speak) on save and open a new kernel pipe then set the pipefd on the autofs mount on restore.

But probably my suggestion is far to simplistic as I get the impression you have a process already in a given state which you want to restore.

One thing to keep in mind is that if an autofs mount is not set catatonic any access other than the owner process (process group pid) will hang unless there is an actual user space process to service the callback.

Although I don't know the flow of things that might be important at some point.

And if the mount is set catatonic the process needs to set the pipefd to take "ownership" which also clears the mount catatonic flag.

Anyway, let me think about what you've written for a while. Ian

08.01.2016 13:58, Ian Kent пишет:

Quoted 93 lines · Stanislav Kinsburskiy

Quoted 79 lines

08.01.2016 08:20, Ian Kent пишет:

Quoted 12 lines · Stanislav Kinsburskiy

Quoted 7 lines

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.

Quoted 5 lines

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.

Fair enough. I'll resend with more descriptive message. But first I would like to clarify to you the problem root and why it's
done like this.

Quoted 8 lines

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.

Here I don't know, what's better. Of course Al can take it as well.
But,
probably, first would be nice to make sure, that this solution is the
best one.
Description of the problem is below.

Quoted 11 lines

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.

I should put it at the end, probably?

Quoted 21 lines

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.

Quoted 6 lines

16.12.2015 13:02, Stanislav Kinsburskiy пишет:

Quoted 5 lines

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.

Quoted 6 lines

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"?

Quoted 13 lines

So, here is a brief description of the problem.
To migrate autofs mount, one have to reconstruct control pipe between
kernel and autofs master.
There are two cases I'm wiling to support:
1) Automount binary (autofs package). This program is very gentle and
it
doesn't close write end of the pipe after mount.
2) Systemd. This program closes write end of the pipe once the mount
is
done.

Quoted 6 lines

I must admit I'm having trouble understanding the description. Give me a little time with it.

I don't know how systemd works with autofs mounts only that it uses the
autofs direct mount type.

Systemd closes write end of the pipe after mount.

Quoted 5 lines

autofs uses both indirect and direct mounts and both can have offsets
(from the kernel POV semantically direct mounts). So there is quite a
bit to worry about beside the kernel pipe.

It's not about direct or indirects mounts.
It's about process state restore.
With CRIU migration, any task is frozen, then disassembled into pieces
(dump files), which are used to assemble task exactly in the same state
in was before dump.
The technology is very complex and uses a lot a different tricky techniques to make this possible in userspace to describe all the details here.

But below is a bit more information, which, hopefully, will clarify all
this a little bit more.
One of a process attributed to migrate is "opened files". Pipes also belong to this attribute.

To restore a pipe CRIU does the following (a very simplified description):
1) Creates a new pipe.
2) Writes (previously stores in images) its contents via write end.
3) Duplicate pipe descriptors to the fds of the process, which were used
before dump, if required
4) Send pipe descriptors to other processes, sharing it, via unix socket.
5) Close those pipe descriptors, which are not required (say, this process had only read end, while it's child had write end).

Thus in case of restoring and autofs mount of systemd (which, for example, closed write end and has read end on fd 40), one have to create
a pipe (say, appeared with fd 5 and fd 6), fill it with content via fd
6, duplicate fd 5 into fd 40, call mount with pipe fd 6 and then close fd 6.
This is, yet again, a very simple explanation.

Quoted 7 lines

Anyway, it seems your only concern is the kernel pipe and I wonder why
you can't just set the mount catatonic (in autofs speak) on save and
open a new kernel pipe then set the pipefd on the autofs mount on restore.

I can't because of a bunch of reasons:
1) It can be migration, thus I don't have autofs mount on destination node at all
2) It can be a container, which is stopped after dump (thus mount point
is destroyed).

Quoted 12 lines

But probably my suggestion is far to simplistic as I get the impression
you have a process already in a given state which you want to restore.

One thing to keep in mind is that if an autofs mount is not set catatonic any access other than the owner process (process group pid)
will hang unless there is an actual user space process to service the
callback.

Quoted 6 lines

Although I don't know the flow of things that might be important at some point.

And if the mount is set catatonic the process needs to set the pipefd
to take "ownership" which also clears the mount catatonic flag.

The migration is already implemented and sent to CRIU mailing list. Here is the list, if you are interesting (I use kernel with this patch
applied):
https://lists.openvz.org/pipermail/criu/2016-January/024749.html

Quoted 3 lines

Anyway, let me think about what you've written for a while. Ian

Sure, take your time.

Quoted 136 lines

08.01.2016 13:58, Ian Kent пишет:

Quoted 93 lines · Stanislav Kinsburskiy

Quoted 79 lines

08.01.2016 08:20, Ian Kent пишет:

Quoted 12 lines · Stanislav Kinsburskiy

Quoted 7 lines

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.

Quoted 5 lines

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.

Fair enough. I'll resend with more descriptive message. But first I would like to clarify to you the problem root and why it's
done like this.

Quoted 8 lines

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.

Here I don't know, what's better. Of course Al can take it as well.
But,
probably, first would be nice to make sure, that this solution is the
best one.
Description of the problem is below.

Quoted 11 lines

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.

I should put it at the end, probably?

Quoted 21 lines

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.

Quoted 6 lines

16.12.2015 13:02, Stanislav Kinsburskiy пишет:

Quoted 5 lines

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.

Quoted 6 lines

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"?

Quoted 13 lines

So, here is a brief description of the problem.
To migrate autofs mount, one have to reconstruct control pipe between
kernel and autofs master.
There are two cases I'm wiling to support:
1) Automount binary (autofs package). This program is very gentle and
it
doesn't close write end of the pipe after mount.
2) Systemd. This program closes write end of the pipe once the mount
is
done.

Quoted 6 lines

I must admit I'm having trouble understanding the description. Give me a little time with it.

I don't know how systemd works with autofs mounts only that it uses the
autofs direct mount type.

Systemd closes write end of the pipe after mount.

Quoted 5 lines

autofs uses both indirect and direct mounts and both can have offsets
(from the kernel POV semantically direct mounts). So there is quite a
bit to worry about beside the kernel pipe.

It's not about direct or indirects mounts.
It's about process state restore.
With CRIU migration, any task is frozen, then disassembled into pieces
(dump files), which are used to assemble task exactly in the same state
in was before dump.
The technology is very complex and uses a lot a different tricky techniques to make this possible in userspace to describe all the details here.

But below is a bit more information, which, hopefully, will clarify all
this a little bit more.
One of a process attributed to migrate is "opened files". Pipes also belong to this attribute.

To restore a pipe CRIU does the following (a very simplified description):
1) Creates a new pipe.
2) Writes (previously stores in images) its contents via write end.
3) Duplicate pipe descriptors to the fds of the process, which were used
before dump, if required
4) Send pipe descriptors to other processes, sharing it, via unix socket.
5) Close those pipe descriptors, which are not required (say, this process had only read end, while it's child had write end).

Quoted 8 lines

Thus in case of restoring and autofs mount of systemd (which, for example, closed write end and has read end on fd 40), one have to create
a pipe (say, appeared with fd 5 and fd 6), fill it with content via fd
6, duplicate fd 5 into fd 40, call mount with pipe fd 6 and then close fd 6.
This is, yet again, a very simple explanation.

Right, as said initially (more or less), if you need the patch you posted then it shouldn't cause a problem so it should be ok. Al hasn't responded so I guess that means I should go the linux-next path possibly via pull request for the series I have to rename autofs4 to autofs (along with this one, to prevent merge conflicts).

I haven't asked Steven about this yet so I'm not sure if a pull request is even the right thing to do.

There is another case I was wondering about.

That's when there is a direct mount that is covered by a real mount.

autofs will have a file handle open to it (on the underlying mount point path) to use for control purposes like expires. I think you also need to restore those file handles to restore process state and in this case the mount point is covered.

Quoted 28 lines

Quoted 6 lines

Anyway, it seems your only concern is the kernel pipe and I wonder why
you can't just set the mount catatonic (in autofs speak) on save and
open a new kernel pipe then set the pipefd on the autofs mount on restore.

I can't because of a bunch of reasons:
1) It can be migration, thus I don't have autofs mount on destination node at all
2) It can be a container, which is stopped after dump (thus mount point
is destroyed).

Quoted 15 lines

But probably my suggestion is far to simplistic as I get the impression
you have a process already in a given state which you want to restore.

One thing to keep in mind is that if an autofs mount is not set catatonic any access other than the owner process (process group pid)
will hang unless there is an actual user space process to service the
callback.

Although I don't know the flow of things that might be important at some point.

Quoted 8 lines

Quoted 3 lines

And if the mount is set catatonic the process needs to set the pipefd
to take "ownership" which also clears the mount catatonic flag.

The migration is already implemented and sent to CRIU mailing list. Here is the list, if you are interesting (I use kernel with this patch
applied):
https://lists.openvz.org/pipermail/criu/2016-January/024749.html

ok, I'll try and have a look although I'm pressed for time so I'm not sure I'll spend much time on it.

In any case the project needs to do what it thinks best so my only real concern is to try and alert you to possible problems.

Hi again,

I would like to ask about any progress with this patch? Any other requirements to make it able to merge?

Quoted 4 lines · Stanislav Kinsburskiy

Hi again,

I would like to ask about any progress with this patch? Any other requirements to make it able to merge?

Sorry for the delay.

Since there haven't been any comments from Al or Stephen I'm think I should include it in the series I plan on sending to linux-next to rename autofs4 to autofs (among other things).

I haven't had anything significant enough for autofs to warrant maintaining a tree and sending push requests so I'll need to ask Stephen what I need to do (perhaps you could offer some advise on that
now Stephen, please).

I'm also struggling to get back to this and carry out the needed testing and I'll need to re-base the series too now but I'm getting there.

I didn't see a follow up patch with an updated description, did I miss
it?

Ian
--
To unsubscribe from this list: send the line "unsubscribe autofs" in

Quoted 4 lines

Hi again,

I would like to ask about any progress with this patch? Any other requirements to make it able to merge?

Sorry for the delay.

Since there haven't been any comments from Al or Stephen I'm think I should include it in the series I plan on sending to linux-next to rename autofs4 to autofs (among other things).

I haven't had anything significant enough for autofs to warrant maintaining a tree and sending push requests so I'll need to ask Stephen what I need to do (perhaps you could offer some advise on that now Stephen, please).

I'm also struggling to get back to this and carry out the needed testing and I'll need to re-base the series too now but I'm getting there.

I didn't see a follow up patch with an updated description, did I miss it?

Ian

I haven't had anything significant enough for autofs to warrant maintaining a tree and sending push requests so I'll need to ask Stephen what I need to do (perhaps you could offer some advise on that now Stephen, please).

Hi Ian,

Quoted 5 lines · On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent <[email protected]> wrote:

I haven't had anything significant enough for autofs to warrant maintaining a tree and sending push requests so I'll need to ask Stephen what I need to do (perhaps you could offer some advise on that now Stephen, please).

I guess if its just a few patches every now and then, then Andrew Morton may be the best person to shepherd them upstream.

Quoted 11 lines · On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell < [email protected]>…

Hi Ian,

Quoted 6 lines · On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent <[email protected]> wrote:

I haven't had anything significant enough for autofs to warrant maintaining a tree and sending push requests so I'll need to ask Stephen what I need to do (perhaps you could offer some advise on that
now Stephen, please).

Quoted 2 lines

I guess if its just a few patches every now and then, then Andrew Morton may be the best person to shepherd them upstream.

yup, send 'em along.

I actually was handling the autofs4 stuff back in 2014 for a bit.

Quoted 14 lines · Andrew Morton

Quoted 11 lines · On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell < [email protected]>…

Hi Ian,

Quoted 6 lines · On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent <[email protected]> wrote:

I haven't had anything significant enough for autofs to warrant maintaining a tree and sending push requests so I'll need to ask Stephen what I need to do (perhaps you could offer some advise on that
now Stephen, please).

Quoted 6 lines

Quoted 2 lines

I guess if its just a few patches every now and then, then Andrew Morton may be the best person to shepherd them upstream.

yup, send 'em along.

I actually was handling the autofs4 stuff back in 2014 for a bit.

Thanks Andrew.

Last time I tried to send the module rename series we got confused some how, patches not seen leading to conflicts in applying later patches IIRC, which lead to the recommendation I send them to linux-next.

The series has grown a bit too now but I'm thinking I should send them in smaller groups, such as coding style fixes and white space fixes, change to use pr* logging, etc.

Hopefully that will make the process much more straight forward.

The thing is the patches are mostly not urgent which is why I keep postponing sending them when higher priority things come up.

As for the patch from Stanislav, I'll put that at the top of my patch queue, have a quick look at it and send it over so that, hopefully, it can get merged.

I'll probably send a couple of others too to get things going on with (what I'm calling) the module rename series.