[CRIU] crtools - TCP dumping within a network namespace

[Andrew Vagin]

On Thu, Apr 25, 2013 at 01:52:04PM -0400, Dilip Daya wrote:
> On Thu, 2013-04-25 at 12:34 +0400, Cyrill Gorcunov wrote:
> > On Thu, Apr 25, 2013 at 12:27:00PM +0400, Andrew Vagin wrote:
> > > On Wed, Apr 24, 2013 at 10:43:38AM -0400, Dilip Daya wrote:
> > > > Hi criu-developers:
> > > >
> > > 
> > > Hello Dilip Daya,
> > > 
> > > I found a root cause of this problem.
> > > 
> > > > (00.002174) 3232 fdinfo 4: pos: 0xffffffffffffffff flags:           100000/0
> > > > (00.002190) Dumping path for 4 fd via self 53 [net:[4026532312]]
> > > 
> > > [net:[4026532312]] is a magic file for a net namespce (/proc/PID/ns/net).
> > > crtools doesn't support such files yet.  I'm going to fix crtools for
> > > printing a clear error in this case.
> > > 
> > > Why is this file descriptor required for your program? Can it be closed?
> 
> This file descriptor is required for network-namespace to identify a
> netns instance and cannot be closed. This file keeps the network
> namespace of the process specified by PID alive. This file is bind
> mounted to keep the network namespace alive without a process. So if you
> close this file it would destroy the network-namespace.
> See "man 5 proc" for details on /proc/[pid]/ns/net.

Sorry, I don't understand this explanation. I asked how tcp-howto uses
this file descriptor. Could you show source code of tcp-howto?

You said that this file is bind mounted. Where is it bind mounted?

For example the util ip bind mounts netns in /var/run/netns/[NAME]
# strace -e mount ip net add test-netns
mount("/proc/self/ns/net", "/var/run/netns/test-netns", 0x431a1d,
MS_BIND, NULL) = 0
+++ exited with 0 +++

Then any application for changing netns can open this file, calls setns()
and closes this file.

The netns will be destroied only when /var/run/netns/test-netns will be
umounted.

Sometimes an application wants to return in the source netns and in this
case the program opens /proc/self/ns/net and uses this descriptor for
returning back (crtools uses this scheme).

> 
> To answer your question of "why" I require this file, some background:
> Some six months or so ago, I'd communicated with Pavil of my interest
> in investigating socket level failover within a network namespace and
> using TCP_REPAIR.  Seeing that I now have a few days on this topic I
> revisited crtools to check its latest status and so started playing with
> "tcp-howto".
> 
> 
> > > 
> > > Thanks.
> > 
> > Guys, maybe something like below for a while?
> 
> Thanks, Cyrill. I applied your patch and here is excerpt from dump.log:
> 
> --- img-dir/dump.log:
> ...
> (00.026321) Dumping opened files (pid: 5840)
> (00.026323) ----------------------------------------
> pie: Parasite cmd 12/0xc process
> (00.026383) 5840 fdinfo 0: pos: 0xffffffffffffffff flags:           100002/0
> (00.026391) tty: Dumping tty 49 with id 0x1
> pie: Parasite cmd 14/0xe process
> (00.026464) fdinfo: type: 0x b flags: 0100002/0 pos: 0xffffffffffffffff fd: 0
> (00.026473) 5840 fdinfo 1: pos: 0xffffffffffffffff flags:           100002/0
> (00.026478) fdinfo: type: 0x b flags: 0100002/0 pos: 0xffffffffffffffff fd: 1
> (00.026483) 5840 fdinfo 2: pos: 0xffffffffffffffff flags:           100002/0
> (00.026486) fdinfo: type: 0x b flags: 0100002/0 pos: 0xffffffffffffffff fd: 2
> (00.026492) 5840 fdinfo 3: pos: 0xffffffffffffffff flags:                2/0
> (00.026498)     Searching for socket 2ac1 (family 16)
> (00.026509) No filter for socket
> (00.026522) fdinfo: type: 0x d flags: 02/0 pos: 0xffffffffffffffff fd: 3
> (00.026529) 5840 fdinfo 4: pos: 0xffffffffffffffff flags:           100000/0
> (00.026547) Dumping path for 4 fd via self 53 [net:[4026532332]]
> (00.026557) Error (files-reg.c:349): No directory for original file found in net:[4026532332]. Unsupported file.
> (00.026563) ----------------------------------------
> (00.026566) Error (cr-dump.c:1454): Dump files (pid: 5840) failed with -1
> pie: Parasite cmd 3/0x3 process
> (00.026699) Unlock network
> (00.026707) Unfreezing tasks into 1
> (00.026709)     Unseizing 5840 into 1
> (00.026748) Error (cr-dump.c:1640): Dumping FAILED.
> ---
> 
> At this time, the "# ./tcp-howto 10.27.82.60 2345" client was _not_
> affected and continued its output.
> 
> So, I guess as you've all stated thus far, crtools is not supported
> within a network-namespace as of yet.
> 
> 
> Thanks.
> -- 
> -DilipD.
>