1433117989 N * Bertl_zZ Bertl
1433117991 M * Bertl back now ...
1433130706 Q * sannes Ping timeout: 480 seconds
1433131262 J * sannes ~ace@2a02:fe0:c120:9660:1888:92c4:1939:2ca6
1433134406 J * Aiken ~Aiken@d63f.h.jbmb.net
1433135476 M * Bertl off to bed now ... have a good one everyone!
1433135485 N * Bertl Bertl_zZ
1433137306 J * aj__ ~aj@88.128.80.157
1433138646 J * Ghislain ~aqueos@adsl1.aqueos.com
1433140597 Q * aj__ Ping timeout: 480 seconds
1433142303 J * nikolayK ~nikolay.k@199.91.137.248
1433143230 Q * nikolayK Quit: Leaving
1433143276 J * aj__ ~aj@fw.gkh-setu.de
1433144544 J * nikolayK ~nikolay.k@199.91.137.248
1433146219 J * wicope ~wicope@0001fd8a.user.oftc.net
1433154887 J * Gremble ~Gremble@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net
1433155046 Q * ensc|w Ping timeout: 480 seconds
1433156071 Q * Gremble Read error: Connection reset by peer
1433156093 J * Gremble ~Gremble@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net
1433156401 Q * fstd Remote host closed the connection
1433156402 J * fstd ~fstd@xdsl-84-44-223-92.netcologne.de
1433157504 Q * gnarface Remote host closed the connection
1433157818 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net
1433158711 Q * Gremble Read error: Connection reset by peer
1433158732 J * Gremble ~Gremble@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net
1433159960 Q * fstd Remote host closed the connection
1433159971 J * fstd ~fstd@xdsl-81-173-185-98.netcologne.de
1433160012 Q * fstd Remote host closed the connection
1433160019 J * fstd ~fstd@xdsl-81-173-185-98.netcologne.de
1433160402 Q * Gremble Ping timeout: 480 seconds
1433161013 J * Gremble ~Gremble@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net
1433161319 N * Bertl_zZ Bertl
1433161321 M * Bertl morning folks!
1433161448 Q * Aiken Remote host closed the connection
1433161476 J * Ghislain1 ~aqueos@adsl1.aqueos.com
1433161489 Q * Ghislain Read error: Connection reset by peer
1433165842 Q * Gremble Remote host closed the connection
1433169175 J * calderonth ~thomas@2001:7a8:1161:39:ddde:de05:3bb9:8571
1433169282 M * calderonth Hi, to which email adress should I report a bug with VServer?
1433169689 M * calderonth I'll send it to vserver@list.linux-vserver.org
1433169730 M * Bertl yes that would be fine
1433169745 M * Bertl what bug do you see and with what kernel/patch version?
1433169804 M * Ghislain1 that's teasing ! :)
1433169868 M * calderonth I'll send the mail then we can discuss it
1433169874 M * calderonth :)
1433169899 M * Ghislain1 :P
1433170103 Q * wicope Remote host closed the connection
1433170715 J * Gremble ~Gremble@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net
1433170728 M * calderonth OK mail sent
1433170735 M * calderonth running Linux kernel x86 version 3.2.69 with GrSecurity + VServer 2.3.2.17
1433170822 M * Bertl okay, we don't have a mixed patch for that
1433170844 M * Bertl i.e. I presume you added grsec yourself or?
1433170863 M * calderonth Yes, I took the combined patch available on grsecurity.net and applied it on a vanilla kernel
1433170968 M * Bertl ah, so you probably want to report it to the grsec folks as well (if not already done so)
1433170983 M * calderonth I did so, they told me to report it to you guys
1433171015 M * calderonth (issue being triggered specifically when entering VServer contexts, otherwise, no issue)
1433171023 M * calderonth (with namespace PID)
1433171088 M * Bertl good
1433171253 M * fback Bertl: then I'm going to report something too (and sorry, nothing new with previous issue, hope to do something before thursday)
1433171292 M * fback Bertl: seems that 64 bit kernel plus 32 bit userland on host work without issues ;-)
1433171347 M * Bertl good to hear :)
1433171706 M * Bertl calderonth: ah, you are the person doing stress tests?
1433171808 M * Bertl spender told me about problems with the proxy output (information leak) and unexplained stack traces caused by missing proxy information (a few days back)
1433171847 M * calderonth Yes
1433171876 M * Bertl the child process pid problem sounds like it might not even be Linux-VServer related
1433171903 M * Bertl is there a chance that you can test this case without Linux-VServer patched into the kernel?
1433171911 M * Bertl i.e. by just creating the namespaces?
1433171978 M * Bertl ah, and one more question, do you actually use PID namespaces or do you use PID isolation (as provided by Linux-VServer)?
1433172267 M * calderonth I am using CLONE_NEWPID
1433172323 M * Bertl okay, then it should be simple to test without Linux-VServer
1433172471 M * calderonth yes and no, the code using to enter the VServer context is high-level, I am not sure I can use the Linux implementation as a drop-in replacement
1433172669 M * Bertl okay, well, one question remains, do you disable the Linux-VServer specific IP isolation for the guest or is it still active despite the fact that you use PID namespaces?
1433172697 M * Bertl because that could cause some unexpected problems
1433172788 M * calderonth IP as in Internet Protocol ?
1433172806 M * Bertl sorry, I meant PID isolation
1433172814 M * Bertl http://linux-vserver.org/Capabilities_and_Flags
1433172943 M * calderonth Yes I am using those
1433173070 M * Bertl so you probably want to disable INFO_INIT for a test
1433173123 M * Bertl it is not supposed to be used together with PID namespaces
1433173130 M * calderonth Currently, cflags is empty
1433173185 M * Bertl if you're talking about the config file, then try adding ~fakeinit there
1433173240 M * calderonth ok
1433173804 M * calderonth No effect
1433173882 M * Bertl so to me it looks like you're hitting a problem with the pid namespace (mainline)
1433173918 M * Bertl i.e. I would expect the very same issue with just namespaces without any Linux-VServer patch
1433173968 M * calderonth hum ... ok, I'll try to reproduce with a basic forking daemon example
1433174027 M * Bertl we do not modify the namespaces per se, although we change the way namespace proxies are created
1433174072 M * Bertl so I cannot rule out that Linux-VServer is somehow involved, but without the PID isolation code (fakeinit) we should not do anything differently than mainline
1433174140 M * calderonth Well, I have some more debugging to do then ^^
1433174670 Q * nikolayK Quit: Leaving
1433174999 M * Bertl calderonth: please keep us updated about your findings!
1433175007 M * calderonth I sure will
1433175164 J * bonbons ~bonbons@2001:a18:202:8801:b865:59a:352f:41a3
1433175302 M * Bertl thanks! appreciated!
1433175343 M * daniel_hozac i assume you're not using util-vserver, right?
1433175353 M * daniel_hozac because pid namespaces aren't really supported yet.
1433175411 M * calderonth nope, I am using a private library that wraps around the vserver API
1433175414 M * Bertl yeah, the API was mentioned, so I presume it is hard coded
1433175501 M * Bertl interesting point is how you disabled the fakeinit flag in this case? :)
1433175537 M * Bertl i.e. I would double check that you do not accidentially have the VXF_INFO_INIT enabled for your guest
1433175563 M * Bertl e.g. you can manually remove the flag after starting the guest context
1433175589 M * calderonth the logic is: not present in cflags, then not enabled in the context
1433175598 M * calderonth I will double check just in case
1433175611 M * daniel_hozac "cflags" being what?
1433175663 M * calderonth a file where those flags are stored
1433175744 M * daniel_hozac yes, but what does it get passed to?
1433176192 M * calderonth From what I can pick from the wrapper, to the vserver syscall with VCMD_enter_space_v1, xid, then mask
1433176251 M * calderonth however, I did not develop this part, I have to investigate further to make sure, VXF_INFO_INIT is disabled, should be the case, but I'll make sure
1433176270 M * calderonth I'll also try to reproduce standard 3.2 kernel
1433176273 M * daniel_hozac enter_space will not touch context flags.
1433176347 Q * Gremble Quit: I Leave
1433176387 M * calderonth There is some setup code prior to calling enter_space, as mentioned, I'll double cehck
1433176389 M * calderonth check
1433179025 Q * calderonth Quit: Konversation terminated!
1433179080 J * wicope ~wicope@0001fd8a.user.oftc.net
1433182617 Q * Ghislain1 Quit: Leaving.
1433183200 M * Bertl off for a nap ... bbl
1433183210 N * Bertl Bertl_zZ
1433186193 J * Wermwud ~Wermwud@69-29-150-18.stat.centurytel.net
1433187212 Q * aj__ Ping timeout: 480 seconds
1433191051 J * [Guy] ~korn@elan.rulez.org
1433191054 J * bragon ~alex@tobold.bragon.info
1433191064 Q * wicope magnet.oftc.net helix.oftc.net
1433191064 Q * Guy- magnet.oftc.net helix.oftc.net
1433191064 Q * Defaultti magnet.oftc.net helix.oftc.net
1433191064 Q * Romster magnet.oftc.net helix.oftc.net
1433191064 Q * bragon_ magnet.oftc.net helix.oftc.net
1433191064 Q * swenTjuln magnet.oftc.net helix.oftc.net
1433191132 J * wicope ~wicope@0001fd8a.user.oftc.net
1433191132 J * Guy- ~korn@elan.rulez.org
1433191132 J * Defaultti defaultti@lakka.kapsi.fi
1433191132 J * Romster ~Romster@202.168.100.149.dynamic.rev.eftel.com
1433191132 J * bragon_ ~alex@tobold.bragon.info
1433191132 J * swenTjuln ~Swen@195.95.173.243
1433191134 Q * wicope Max SendQ exceeded
1433191134 Q * Defaultti Max SendQ exceeded
1433191136 Q * swenTjuln Ping timeout: 480 seconds
1433191143 Q * Guy- Read error: No route to host
1433191154 Q * bragon_ Read error: No route to host
1433191208 J * wicope ~wicope@0001fd8a.user.oftc.net
1433191224 J * Defaultti defaultti@lakka.kapsi.fi
1433191252 J * Aiken ~Aiken@d63f.h.jbmb.net
1433191285 J * swenTjuln ~Swen@195.95.173.243
1433191619 J * derjohn_mob ~aj@p578b6aa1.dip0.t-ipconnect.de
1433191803 Q * bonbons Quit: Leaving
1433192749 N * Bertl_zZ Bertl
1433192750 M * Bertl back now ...
1433193275 Q * wicope Remote host closed the connection
1433199011 J * Ghislain ~aqueos@adsl1.aqueos.com
1433199073 Q * Ghislain 
1433203159 Q * fstd Remote host closed the connection
1433203169 J * fstd ~fstd@xdsl-84-44-145-213.netcologne.de