Hi Andrey,
On 07/22/2016 08:25 PM, Andrey Vagin wrote:
quoted
On Thu, Jul 21, 2016 at 11:48 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
Hi Andrey,
On 07/21/2016 11:06 PM, Andrew Vagin wrote:
quoted
[snip]
quoted
quoted
quoted
quoted
quoted
where ioctl_type is one of the following:
NS_GET_USERNS
Returns a file descriptor that refers to an owning user names‐
pace.
NS_GET_PARENT
Returns a file descriptor that refers to a parent namespace.
This ioctl(2) can be used for pid and user namespaces. For user
namespaces, NS_GET_PARENT and NS_GET_USERNS have the same mean‐
ing.
For each of the above, I think it is worth mentioning that the
close-on-exec flag is set for the returned file descriptor.
Hmm. That is an odd default.
Why do you say that? It's pretty common as the default for various
APIs that create new FDs these days. (There's of course a strong argument
that the original UNIX default was a design blunder...)
Interesting. I haven't kept up on that, but it seems reasonable.
[snip]
quoted
quoted
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
As in fstat() to get the st_ino field, right?
Both the st_ino and st_dev fields.
The most likely change to support checkpoint/restart in the future is to
preserve st_ino across migrations and instantiate a different instance
of nsfs to hold the inode numbers from the previous machine.
We would need to handle the preservation carefully or else there is
a chance that two namespace file descriptors (collected from different
sources) with different st_dev and st_ino fields may actuall refer to
the same object.
Which is a long way of saying we have the st_dev field please use it,
it may matter at some point.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
I like the idea to use kcmp to compare namespaces. I am going to add this
functionality to kcmp and describe all these in the man page.
quoted
As in fstat() to get the st_ino field, right?
Both the st_ino and st_dev fields.
The most likely change to support checkpoint/restart in the future is to
preserve st_ino across migrations and instantiate a different instance
of nsfs to hold the inode numbers from the previous machine.
It sounds tricky. BTW: Actually this is not only one places where we have
this sort of problem. For example, now mount id-s are not preserved when
a container is migrated. The same problem is applied to tmpfs, where
inode numbers are not preserved for files.
We would need to handle the preservation carefully or else there is
a chance that two namespace file descriptors (collected from different
sources) with different st_dev and st_ino fields may actuall refer to
the same object.
Which is a long way of saying we have the st_dev field please use it,
it may matter at some point.
Eric
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
I like the idea to use kcmp to compare namespaces. I am going to add this
functionality to kcmp and describe all these in the man page.
Hi Andrey,
Can you briefly sketch out the proposed API and how it would be used?
I'd find it useful to see that even before the implementation.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
From: W. Trevor King <hidden> Date: 2016-07-26 18:34:29
On Tue, Jul 26, 2016 at 11:25:24AM -0700, Andrew Vagin wrote:
Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
I like the idea to use kcmp to compare namespaces. I am going to add this
functionality to kcmp and describe all these in the man page.
Hi Andrey,
Can you briefly sketch out the proposed API and how it would be used?
I'd find it useful to see that even before the implementation.
Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
For example, if we want to compare pid namespaces for 1 and 2 processes:
What's the purpose of the following line, and the use of 'pid' in the
kcmp() call?:
pid = getpid();
ns_fd1 = open("/proc/1/ns/pid")
ns_fd2 = open("/proc/2/ns/pid")
if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
printf("Both processes live in the same pid namespace\n");
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
I like the idea to use kcmp to compare namespaces. I am going to add this
functionality to kcmp and describe all these in the man page.
Hi Andrey,
Can you briefly sketch out the proposed API and how it would be used?
I'd find it useful to see that even before the implementation.
Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
For example, if we want to compare pid namespaces for 1 and 2 processes:
What's the purpose of the following line, and the use of 'pid' in the
kcmp() call?:
It's the existing interface of kcmp. It's used to check whether the
two processes identified by pid1 and pid2 share a kernel resource
such as virtual memory, file descriptors, and so on.
If we want to compare two file descriptors of the current process,
it is one of cases for which kcmp can be used. We can call kcmp to
compare two namespaces which are opened in other processes.
Thanks,
Andrew
quoted
pid = getpid();
ns_fd1 = open("/proc/1/ns/pid")
ns_fd2 = open("/proc/2/ns/pid")
if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
printf("Both processes live in the same pid namespace\n");
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
I like the idea to use kcmp to compare namespaces. I am going to add this
functionality to kcmp and describe all these in the man page.
Hi Andrey,
Can you briefly sketch out the proposed API and how it would be used?
I'd find it useful to see that even before the implementation.
Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
For example, if we want to compare pid namespaces for 1 and 2 processes:
pid = getpid();
ns_fd1 = open("/proc/1/ns/pid")
ns_fd2 = open("/proc/2/ns/pid")
if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
printf("Both processes live in the same pid namespace\n");
Thanks,
Andrew
From: Andrew Vagin <hidden> Date: 2016-07-27 04:45:40
On Tue, Jul 26, 2016 at 11:32:25AM -0700, W. Trevor King wrote:
On Tue, Jul 26, 2016 at 11:25:24AM -0700, Andrew Vagin wrote:
quoted
Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
If you use the new ioctl-s to get ns_fd2, do you walk your local /proc
to find pid2?
If you use the new ioctl-s to get nf_fd2, you will have it in the
current process, so pid2 will be getpid().
pidX identifies a process where to find fdX.
man 2 kcmp:
The kcmp() system call can be used to check whether the two processes
identified by pid1 and pid2 share a kernel resource such as virtual
memory, file descriptors, and so on.
So, from my point of view, the important piece that was missing from
your commit message was the note to use readlink("/proc/self/fd/%d")
on the returned FDs. I think that detail needs to be part of the
commit message (and also the man page text). I think it even be
helpful to include the above program as part of the commit message:
it helps people more quickly grasp the API.
Please, please make the standard way to compare these things fstat.
That is much less magic than a symlink, and a little more future proof.
Possibly even kcmp.
I like the idea to use kcmp to compare namespaces. I am going to add this
functionality to kcmp and describe all these in the man page.
Hi Andrey,
Can you briefly sketch out the proposed API and how it would be used?
I'd find it useful to see that even before the implementation.
Sure. If a process wants to compare two namespaces, it needs to get file
descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
process which has them),
and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
For example, if we want to compare pid namespaces for 1 and 2 processes:
What's the purpose of the following line, and the use of 'pid' in the
kcmp() call?:
It's the existing interface of kcmp. It's used to check whether the
two processes identified by pid1 and pid2 share a kernel resource
such as virtual memory, file descriptors, and so on.
Yes, understood, but it seems a slightly weird use of the interface,
since in general pid1 will be the same as pid2 in this use case,
whereas in the other use cases, pid1 and pid2 are generally not
equal.
If we want to compare two file descriptors of the current process,
it is one of cases for which kcmp can be used. We can call kcmp to
compare two namespaces which are opened in other processes.
Is there really a use case there? I assume we're talking about the
scenario where a process in one namespace opens a /proc/PID/ns/*
file descriptor and passes that FD to another process via a UNIX
domain socket. Is that correct?
So, supposing that we want to build a map of the relationships
between namespaces using the proposed kcmp() API, and there are
say N namespaces? Does this mena we make (N * (N-1) / 2) calls
to kcmp()?
Cheers,
Michael
quoted
quoted
pid = getpid();
ns_fd1 = open("/proc/1/ns/pid")
ns_fd2 = open("/proc/2/ns/pid")
if (!kcmp(pid, pid, KCMP_NSFD, ns_fd1, ns_fd2))
printf("Both processes live in the same pid namespace\n");