[Devel] Kernel 2.6.33-rc6, 3 bugs container specific.

[Jean-Marc Pigeon]

Hello,

        Tried 2.6.33-rc6 to check container, 3 bugs show up.
        (test done on x86_64, Pentium(R) Dual-Core CPU E5400)

        #1: Critical / fixed?:
        Already reported: system hang very badly if you start
        a container (clone) while cloneflag is set with at least 
        one of the set:
        CLONE_NEWNET|CLONE_NEWIPC|CLONE_NEWNS|CLONE_NEWPID|CLONE_NEWUTS.
        
        Bug is said fixed: 
        (commit  fabf318e5e4bda0aca2b0d617b191884fda62703),
        and is somewhere in queue, hopefully will be part of rc7.


        #2: Trouble  / can be override by sys_admin
         arping not working if HOST interface not named
         the same as in CONT. 

            Lets say you set the HOST "eth0" interface to be
            "fast" to met whatever your standard are and
            rename CONT veth to be eth0 using command:
            ip link set vth_name name eth0
            (within CONT) to allow very standard CONT template.

           directory HOST:/sys/class/net will report
           br0  fast lo  sit0 'to-vth'

           directory CONT:/sys/class/net will report
           exactly the same

           Problem: file
           /etc/sysconfig/network-scripts/ifup-eth
           is doing "ip link set dev eth0 up" as
           eth0 is the name we want to have in CONT.
           So far so good, just after arping is
           trying to make sure no one is using the
           IP to be set.
           and arping is accessing file
           /sys/class/net/eth0/broadcast
           which doesn't exist --> Network setting hang!.

           Fix: when "ip link set vth_name name othername"
           is applied, /sys/class/net/ should be updated
           by kernel too.


        #3: Very critical / CONT can't be production grade.
            HOST and CONT share the same kmsg ring buffer.

            Some part of the kernel running as CONT
            could printk CONT specific message (iptable
            packet tracing is a good example) even worse
            CONT:rsyslog is reading kmsg too, meaning
            it is competing with HOST:rsyslog to get
            critical information. So the whole ring buffer
            is garbled (not good at all).

            My advice is to give a specific "ring buffer"
            to each started container. This is the way it
            was implemented by the openvz guys (seems to
            me a very good solution), other solution would
            be to say CONT:/proc/kmsg to be a kind of
            device null, but then how kernel will give to
            container context, informations on it specific 
            CONT problem???


        My 3 cents.
        Seems to me we are very close to have a "production"
        container, thanks to all contributor...
-- 
A bientôt
==========================================================================
Jean-Marc Pigeon                                   Internet: jmp at safe.ca
SAFE Inc.                                          Phone: (514) 493-4280
                                                   Fax:   (514) 493-1946
        Clement, 'a kiss solution' to get rid of SPAM (at last)
           Clement' Home base <"http://www.clement.safe.ca">
==========================================================================

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers