[Lxc-users] tun use from within lxc

[Serge E. Hallyn]

uh, yeah - until sysfs directory tagging with network namespaces hits
upstream, devices in a network namespace other than the initial one
are not represented in sysfs.  I'd assume that
/sys/devices/virtual/net/vethKV9R8v actually does not exist and
therefore device_create_file(&tun->dev->dev, &dev_attr_tun_flags)
in drivers/net/tun.c:tun_set_iff() fails to create the 'flags'
file in there?

So maybe the creation of those three files should be put under a
(if tun->dev->nd_net != &init_net_ns) check in the meantime?

(Or maybe this is just proof that tun devices are simply not ready
for use in namespaces and we'll just hit another shortcoming
after patching this one...)

-serge

Quoting Nigel Magnay (nigel.magnay at gmail.com):
> Interestingly, doing
> 
> openvpn --mktun --dev tun0
> 
> in the lxc spits out a kernel bug into dmesg:
> 
> [ 1632.334040] tun0: Disabled Privacy Extensions
> [ 1632.334251] ------------[ cut here ]------------
> [ 1632.334263] kernel BUG at /build/buildd/linux-2.6.32/fs/sysfs/file.c:539!
> [ 1632.334269] invalid opcode: 0000 [#1] SMP
> [ 1632.334272] last sysfs file: /sys/devices/virtual/net/vethKV9R8v/flags
> [ 1632.334275] Modules linked in: veth binfmt_misc bridge stp ppdev
> parport_pc fbcon tileblit font bitblit softcursor psmouse intel_agp
> serio_raw i2c_piix4 agpgart vga16fb vgastate lp vmxnet3 shpchp parport
> vmw_pvscsi floppy
> [ 1632.334288]
> [ 1632.334297] Pid: 5075, comm: openvpn Not tainted (2.6.32-16-generic
> #25-Ubuntu) VMware Virtual Platform
> [ 1632.334300] EIP: 0062:[<c025b9a3>] EFLAGS: 00210246 CPU: 0
> [ 1632.334320] EIP is at sysfs_create_file+0x23/0x30
> [ 1632.334323] EAX: 00000000 EBX: e9db5ba0 ECX: e9db5a58 EDX: c07b0974
> [ 1632.334326] ESI: e9339f20 EDI: e9238c00 EBP: e9339ed8 ESP: e9339ed8
> [ 1632.334329]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 006a
> [ 1632.334334] Process openvpn (pid: 5075, ti=e9338000 task=e93059b0
> task.ti=e9338000)
> [ 1632.334337] Stack:
> [ 1632.334339]  e9339ee0 c03df988 e9339f08 c044b169 c07b08c0 00000002
> 00000001 e9db5800
> [ 1632.334346] <0> e99f2700 e9339f20 e9fe1090 00000000 e9339f50
> c044b5ac bfd60e8c e99f2700
> [ 1632.334351] <0> ffffffb3 e9339f4c 306e7574 00000000 00000000
> 00000000 00003001 00000000
> [ 1632.334356] Call Trace:
> [ 1632.334366]  [<c03df988>] ? device_create_file+0x18/0x20
> [ 1632.334375]  [<c044b169>] ? tun_set_iff+0x319/0x400
> [ 1632.334379]  [<c044b5ac>] ? tun_chr_ioctl+0x1ac/0x4a0
> [ 1632.334383]  [<c044b400>] ? tun_chr_ioctl+0x0/0x4a0
> [ 1632.334392]  [<c0213a11>] ? vfs_ioctl+0x21/0x90
> [ 1632.334396]  [<c020e8eb>] ? putname+0x2b/0x40
> [ 1632.334400]  [<c0213cf9>] ? do_vfs_ioctl+0x79/0x310
> [ 1632.334403]  [<c0213ff7>] ? sys_ioctl+0x67/0x80
> [ 1632.334409]  [<c020356e>] ? sys_open+0x2e/0x40
> [ 1632.334417]  [<c01033ec>] ? syscall_call+0x7/0xb
> [ 1632.334420] Code: 83 c4 04 5b 5d c3 66 90 55 89 e5 0f 1f 44 00 00
> 85 c0 74 17 85 d2 8b 40 18 74 10 85 c0 74 0c b9 02 00 00 00 e8 bf ff
> ff ff 5d c3 <0f> 0b eb fe 89 f6 8d bc 27 00 00 00 00 55 89 e5 83 ec 0c
> 89 5d
> [ 1632.334437] EIP: [<c025b9a3>] sysfs_create_file+0x23/0x30 SS:ESP
> 006a:e9339ed8
> [ 1632.334445] ---[ end trace e5a32668add24ded ]---
> 
> 
> 
> 
> On Mon, Apr 5, 2010 at 8:20 PM, Nigel Magnay <nigel.magnay at gmail.com> wrote:
> > Hi!
> >
> > Having had my earlier problems magically disappear (I suspect user
> > error), I'm experimenting a bit further.
> >
> > I'd like to connect an 'inner' lxc machine using openvpn to another
> > network. What I've done so far is
> >
> > - make sure tun exists in the outer machine (in fact, verified the
> > whole openvpn config can operate in the outer machine)
> > - added lxc.cgroup.devices.allow to the relevant node
> > - created /dev/net/tun item in the lxc fs
> >
> > When I start up openvpn however, I get a segmentation fault and
> > shortly afterwards the entire outer machine ceases to function. I
> > don't know if that's yet because I've missed something vital, or
> > there's a better way to expose the tun device to the 'inner' machine?
> >
> > I'll keep experimenting, but was wondering if there was any obvious
> > problems with what I'm trying..
> >
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Lxc-users mailing list
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users