1515644862 J * fstd_ ~fstd@xdsl-87-79-42-57.netcologne.de
1515645310 Q * fstd Ping timeout: 480 seconds
1515645310 N * fstd_ fstd
1515654681 N * Bertl_zZ Bertl
1515654685 M * Bertl  morning folks!
1515656212 M * jrayhawk Hmm. Lots of vsyscall complaints on my systems.
1515656214 M * jrayhawk [   33.854009] lockfile[2358] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffcf1ec4a30 ax:ffffffffff600400 si:400ece di:0
1515656217 M * jrayhawk [   33.854017] lockfile[2358]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007ffcf1ec4a30 error 15
1515656231 M * Bertl kernel/patch?
1515656239 M * jrayhawk Kernel: 4.4.111-vs2.3.9
1515656242 M * jrayhawk util-vserver: 0.30.216-pre3126-jessie0.1
1515656348 M * Bertl when googling for that I find docker and a too recent kernel on the host vs. an old system on the container
1515656403 M * Bertl so maybe that is an unrelated problem with the kernel (syscall interface) being too new and/or the guest system being too old
1515656406 M * jrayhawk The exact same userspace works fine on 4.1.19-vs2.3.8.4
1515656540 M * Bertl nevertheless, can you try with vsyscall=emulate (kernel command line option)?
1515656554 M * jrayhawk Ah, might be CONFIG_LEGACY_VSYSCALL_EMULATE, okay
1515657114 M * jrayhawk Okay, yeah, that looks much better.
1515657297 M * Bertl great! so I can consider this resolved?
1515657992 M * arekm jrayhawk: or not building with dietlibc
1515658022 M * arekm dietlibc uses vsyscall unfortunately
1515658926 M * jrayhawk It's some static binary from BenG; don't know offhand how it was built.
1515659005 M * jrayhawk So "resolved" in the sense that "this is a perfectly adequate solution to the problem, but the problem is probably going to come up a lot"
1515659123 M * Bertl so you need vsyscall=emulate to make it work or just the kernel config, and if the kernel config, did the default change in 4.4.x? (i.e. was it the same in 4.1.x or not)
1515659339 M * Bertl http://vserver.13thfloor.at/Experimental/patch-4.4.111-vs2.3.9.1-testme.diff
1515659364 M * Bertl this patch should bring cow link breaking back to life ... 
1515659474 M * Bertl (but might explode your kernel instead :)
1515659675 M * jrayhawk https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/Kconfig?h=linux-4.4.y&id=3dc33bd30f3e1c1bcaaafa3482737694debf0f0b I think this was 4.3 cycle; looks like the Debian config I copied over defaults to CONFIG_LEGACY_VSYSCALL_NONE=y against the advice of the kernel developers.
1515659726 M * jrayhawk But yes, changing that to default to EMULATE using either the configuration or the cmdline flag works.
1515659844 M * jrayhawk Hmm. BenG hasn't been in here in about 18 months.
1515659992 M * jrayhawk I actually ran into the author of that commit at a UPS Store the other month. The world is an oddly small place.
1515660106 J * nikolay ~nikolay@149.235.255.3
1515661349 A * arekm was looking for vsyscall dropping patches in debian dietlibc but no one did that change unfortunately :/
1515666337 M * arekm seems cow and vroot builds now
1515667143 M * Ghislain to compile what do you do ? me i patch then i copy /vserver/proc.c
1515667143 M * Ghislain  with the modified version, then i rsync firmware/intel-ucode/ with the one downloaded from intel, then i add to firmware Makefile the bnx2 drivers then i make the debian package
1515667165 M * Ghislain any of you use any extra step ?
1515667351 M * Bertl modified version?
1515667709 M * Ghislain the <               if (!dir_emit(ctx, "..", 2, ino, DT_DIR) < 0) 
1515667709 M * Ghislain >               if (!dir_emit(ctx, "..", 2, ino, DT_DIR))
1515667753 M * arekm Bertl: patch-4.4.111-vs2.3.9.1-testme.diff seems to be working fine, too here
1515667790 M * Bertl great! do you have cow link breaking enabled? do you use it? did you test it?
1515667806 M * arekm enabled in kernel but not using it
1515667869 M * Bertl can you try testfs.sh with ext2/3 on a scratch device (loopback or device mapper)?
1515667894 M * arekm where is testfs.sh?
1515667904 M * Bertl Ghislain: okay, will look into the dir_emit() shortly
1515667969 M * Bertl arekm: http://vserver.13thfloor.at/Stuff/SCRIPT/
1515668074 M * Ghislain i must admit my change is a shot in the dark but the original test do not test anything (boolean ar allways >0) and if (dir_emit(ctx, "..", 2, ino, DT_DIR)) lock any ls /proc so...
1515668187 M * Ghislain i mean boolean allways >=0
1515668220 M * Bertl yeah, simply removing the '< 0' part should be fine 
1515668255 M * Bertl but I'm currently checking if we should return 0 or 1 in this case
1515668343 M * Ghislain i havent been able to understand what it is trying to do, if you are on it put a comment so next time i will know what this do ;p
1515668362 M * Bertl it is a simple error check
1515668370 M * Bertl if dir_emit() fails, then do ...
1515668397 M * Bertl usually dir_emit() will work just fine, so that case is not really exercised much
1515668471 M * Ghislain well i havent been able to understand what dir_emit do.. it emit a directory into space ? :)
1515668495 M * Bertl it emits an entry in a (virtual) directory
1515668543 M * Bertl e.g. if you look at /proc/virtual/
1515668567 M * Bertl you'll see the '.' and '..' entry as well as 'info' and 'status'
1515668606 M * arekm Bertl: http://sprunge.us/INbZ 
1515668623 M * Bertl Ghislain: this is generated from proc_virtual_iterate()
1515668673 M * Bertl arekm: does /test exist?
1515668678 M * arekm Bertl: yes
1515668694 M * Bertl because it seems like the mount itself fails
1515668705 M * Bertl try to increase verbosity
1515668731 M * Ghislain oh thx
1515668742 M * arekm mount -t ext2 -o rw /dev/loop0 /test 3>&2
1515668742 M * arekm 1# succeeded.
1515668742 M * arekm mount -o remount,rw,tag /test 3>&2
1515668742 M * arekm mount: /test: mount point not mounted or bad option.
1515668742 M * arekm 2# succeeded.
1515668797 M * arekm http://sprunge.us/VJWC
1515668902 M * Bertl so xid tagging is probably disabled
1515668937 M * Bertl or not working properly
1515669068 M * arekm disabled, hm, don't remember any kernel option like that?
1515669153 M * Bertl # CONFIG_TAGGING_NONE is not set
1515669153 M * Bertl # CONFIG_TAGGING_UID16 is not set
1515669153 M * Bertl # CONFIG_TAGGING_GID16 is not set
1515669153 M * Bertl # CONFIG_TAGGING_ID24 is not set
1515669153 M * Bertl CONFIG_TAGGING_INTERN=y
1515669191 M * Bertl (just as an example, VCI says CONFIG_TAGGING_ID24 should be selected)
1515669256 M * arekm # zcat /proc/config.gz  |grep TAGGING
1515669257 M * arekm # CONFIG_TAGGING_NONE is not set
1515669257 M * arekm # CONFIG_TAGGING_UID16 is not set
1515669257 M * arekm # CONFIG_TAGGING_GID16 is not set
1515669257 M * arekm CONFIG_TAGGING_ID24=y
1515669259 M * arekm # CONFIG_TAGGING_INTERN is not set
1515669269 M * Bertl so that seems to be okay
1515673358 M * Bertl nah, cow link breaking causes the kernel to oops
1515675412 Q * Aiken Remote host closed the connection
1515675481 M * Ghislain if we put a non cow link enabled kernel on a vserver that used it will it explode and cause the universe to fold unto itself or just loose the benefit with no harm done ?
1515675811 M * Bertl it will work, but you might lose some functionality
1515675825 M * Bertl but I'm currently checking what causes the bug()
1515676257 M * Guy- Ghislain: iiuc hashified vserver guests won't be able to overwrite their hashified files
1515676538 M * Ghislain you should just do bug(){ if(!dir_emit()<0) continue;} and be done with it ;p
1515676557 M * Ghislain Guy-: that would be security ! :p
1515678435 M * Ghislain i think there is a faq explaining how to uncow a guest, will look
1515679352 M * Guy- Ghislain: it's not hard, but must be done from the host
1515679437 M * Guy- it'd be something like find guest/ -type f -links +1 | while read i; do cat "$i" >"$i.unhashify"; chown --reference "$i" "$i.unhashify"; chmod --reference "$i" "$i.unhashify"; chattr -i "$i"; rm "$i"; mv "$i.unhashify" "$i"; done
1515679443 M * Guy- modulo error checking
1515679463 M * Guy- it gets trickier if you need to handle posix ACLs and/or xattrs (for example, file capabilities)
1515679717 M * Ghislain ok thanks, i think i have stopped to use cow following some issues a longgggg time ago
1515679726 M * Ghislain but i will carefully look at that
1515679987 M * Bertl the interesting part is, that cow link breaking is not fully functional in 4.1.x
1515680015 M * Bertl but the breaking triggers in 4.4.x and causes a kernel dump
1515681354 M * Guy- Bertl: how is it not functional in 4.1.x?
1515681359 M * Guy- oh, I think I reported an issue with xattrs
1515681390 M * Bertl here is a simple test (on a suitable filesystem)
1515681405 M * Bertl touch file
1515681410 M * Bertl setattr --iunlink file
1515681416 M * Bertl ln file file.0
1515681427 M * Bertl chcontext --xid 10 -- chmod +x file.0
1515681711 M * Guy- indeed, this doesn't work
1515684859 M * Bertl almost there ...
1515685282 M * Ghislain if i add to testme.sh:
1515685282 M * Ghislain eexec 300   0 "touch $tmpdir/file1234567890;setattr --iunlink $tmpdir/file1234567890;ln $tmpdir/file1234567890 $tmpdir/file1234567890.0;chcontext $SID $UXID chmod +x $tmpdir/file1234567890.0"
1515685282 M * Ghislain does it help for future ref ?
1515685314 M * Bertl not really, as test 134 already checks for this case (and more)
1515685358 M * Ghislain testfs 134 you mean then
1515685367 M * Ghislain but its [134]# succeeded. here
1515685391 M * Bertl sorry 135
1515685415 M * Ghislain ah yes, 135 123 126 133 fail
1515686001 M * Bertl the basic cow link breaking is now working, but it leaves the filesystem in a busy state, so we are not releasing some reference or mutex correctly ... 
1515686023 M * Bertl will add some more instrumentation to debug this further
1515686459 M * Bertl off for now ... bbl
1515686465 N * Bertl Bertl_oO
1515688464 M * Le_Coyote Sorry if I sound rude because that's absolutely not the point, but what's VServer got over LXC these days, apart from hashification?
1515688504 M * Guy- Le_Coyote: arguably, friendlier/more mature userspace management tools
1515688532 M * Le_Coyote Yep, that's very true, maybe a little less so with LXD though
1515688566 M * Guy- hashification is quite a big plus (like the Swiss flag :)
1515688588 M * Le_Coyote Yeah, but I've never used it so I won't miss it if/when I switch
1515688588 M * Guy- does lxc have device remapping?
1515688607 M * Le_Coyote No idea. What's that?
1515688641 M * Guy- you can give a guest a /dev/something entry with major x,y and map it to device w,v on the host
1515688646 M * Le_Coyote My use of VServer is very basic: it's mainly for isolation, and I don't run more than 10 containers on a given host
1515688662 M * Guy- for you, lxc may be just as good
1515688673 M * Le_Coyote And all my guests are very standard: a mail server here, a web server there …
1515688688 M * Le_Coyote It's either that, or the "full" virt with KVM
1515688706 M * Le_Coyote But I don't think I can manage the manual patching/quest for the right kernel version much longer
1515688718 M * Guy- I have hosts that run dozens of instances of the same guest, and hashification conserves quite a bunch of resources there
1515688735 M * Le_Coyote Remind me, it's essentially RAM saving, right?
1515688750 M * Guy- RAM, disk space, disk cache (so also RAM)
1515688777 M * Le_Coyote Maybe I *should* give it a go
1515688791 M * Guy- the kernel patching isn't much of an issue for me, I compile my own kernels anyway
1515688809 M * Le_Coyote Oh I do too
1515688820 M * Le_Coyote What I meant is that, and I'm going to be very careful here:
1515688847 M * Le_Coyote I get the *feeling* that the vserver team, being rather small, cannot maintain so many branches
1515688866 M * Le_Coyote So the fact that the latest working patch is based on 4.1 is a slight deterrent
1515688897 M * Le_Coyote In other words, the question at the back of my mind is "what happens when I *need* 4.15 next month for some reason ?" …
1515688940 M * Le_Coyote I mean absolutely no disprespect at all, I'm vaguely aware of the amount of work that it represents, and it stands to reason that there should NOT be 14 parallel versions of the vserver patch matching the maintained kernel branches
1515688983 M * Le_Coyote But when stuff like meltdown/spectre happens and 4.1 is *not* patched, it becomes a problem
1515689058 M * Le_Coyote Does that sound unreasonable/unfair? I sure hope not :/
1515689066 M * Guy- I think it's a very reasonable point
1515689087 M * Guy- it's unfortunate that Bertl has to do all kernel maintenance/development alone
1515689173 M * Guy- I wonder what he could do to attract more manpower -- all the cool kids are probably hacking away at lxc these days
1515689186 M * Le_Coyote Yeah :/
1515689211 M * Le_Coyote Wouldn't it "make sense" to bring the best of vserver to LXC?
1515689225 M * Guy- oh absolutely
1515689227 M * Le_Coyote ie. hashify, userland tools essentially, as you said
1515689243 M * Le_Coyote I sense a "but" :)
1515689252 M * Guy- yes, there is one :)
1515689265 M * Guy- the kernel developers are not necessarily easy or pleasant to deal with
1515689275 M * Le_Coyote Thought as much
1515689306 M * Le_Coyote "Who are you and what are you doing to MY/OUR kernel?" kinda-thing I guess
1515689320 M * Guy- the linux-vserver patch was submitted to lkml once; it was rejected, perhaps wrongly or for the wrong reasons, I don't know
1515689341 M * Guy- but Bertl said he had neither the inclination nor the energy to push
1515689381 M * Guy- I can relate to that, but it's unfortunate, because if vserver were in the vanilla kernel, a lot of parallel development on lxc could have been avoided
1515689396 M * Le_Coyote And I get that. If someone had that and push the "interesting" part only, so as not to step on LXC's toes
1515689406 M * Le_Coyote My thoughts exactly
1515689462 M * Guy- I suppose you would have to break the vserver patch up into incremental improvements that are individually small
1515689489 M * Guy- this sounds like a lot of precision work
1515689497 M * Le_Coyote I expect it would, yeah
1515689529 M * Le_Coyote I'm even considering FreeBSD/jails as an alternative
1515689592 M * Guy- it's probably not an alternative unless you're already deeply familiar with freebsd or have a strategic reason (and the time) to become familiar with it
1515689646 M * Le_Coyote I've dealt with FBSD before and probably will have to in a near future, so that aspect shouldn't be a problem per se
1515689656 M * Guy- btw, re lkml attitude -- I think it's more like "who needs this crap anyway" and "that's totally not the way to do it, rewrite it from scratch in a different way"
1515689666 M * Le_Coyote Heh
1515689675 M * Ghislain freebsd is a great OS but if you dont want to bother with vserver you will not want to go freeBSD. The vulnerability wasnt even sent to the BSD poeple so they have no patch against spectre/meltdown at all
1515689714 M * Le_Coyote Um, their (FBSD's) website says otherwise (about having the info that is)
1515689741 M * Le_Coyote Or did I read that wrong O.o
1515689786 M * Le_Coyote But that's another issue, for sure
1515689892 M * Le_Coyote If there was a 4.9 or even 4.4 vserver patch, I wouldn't even be having these thoughts right now
1515689905 M * Guy- well, there almost is a 4.4 patch now
1515689919 M * Guy- should only be a matter of hours, or days at most until it's usable
1515689946 M * Guy- and Bertl said he was working on 4.14
1515689949 M * Le_Coyote Ah. Well now *that's* good news
1515690004 M * Le_Coyote I'd be happy with 4.4 anyway
1515690007 M * Guy- http://vserver.13thfloor.at/Experimental/patch-4.4.111-vs2.3.9.1-testme.diff
1515690021 M * Guy- there is a CoW bug, but since you don't use hashification it shouldn't affect you
1515690045 M * Guy- you could give it a try and report results :)
1515690050 M * Le_Coyote True. Then again I might just wait for the bug to be fixed
1515690054 M * Le_Coyote Yeah, that too :)
1515690087 M * Le_Coyote Are there any big differences I should be aware of, between 2.3.7.x  and 2.3.9?
1515690097 M * Guy- I don't think so
1515690156 M * Le_Coyote I need to search my inbox, I seem to recall a problem with one of the first 4.1 patches
1515690170 M * Le_Coyote And I remember thinking "welp! let's stick with 3.18 for now"
1515690316 M * Guy- I've been on 4.1.x+vs2.3.8.x for a very long time now
1515690338 M * Guy- probably since late 2015
1515690473 M * Le_Coyote Ok. So I'll either wait for 4.1 to get upstream fixes/backports, or for 4.4 to be deemed stable enough. In the meantime I'll see if I can test the 4.4 patch myself
1515690503 M * Le_Coyote Ghislain: was it you who said the "make oldconfig" was heavy stuff? :D
1515690537 M * Guy- it's not so bad actually
1515690541 M * Guy- most of it is just drivers
1515690571 M * Le_Coyote There really should be a "make oldconfig --samehardware" kinda thing
1515690575 M * Guy- but it would sure be nice to have an "undo" feature in make oldconfig, to jump back one question
1515690581 M * Le_Coyote THIS.
1515690584 M * Le_Coyote SO MUCH.
1515690598 M * gnarface heh, i wonder if there's an emacs module for kernel configuration...
1515690612 M * Le_Coyote Every time I missed a question, I died inside a little.
1515690622 M * Guy- emacs is a decent enough OS, all it lacks is a good editor
1515690633 M * Le_Coyote I smell a troll coming.
1515690635 M * Le_Coyote ;)
1515690651 M * Guy- Le_Coyote: what I do is, I write down the name of the config option and edit the .config manually after oldconfig is done
1515690668 M * Le_Coyote Yeah, I've done that a couple of times, too
1515690686 M * Le_Coyote Or, oldconfig could be synchronous
1515690694 M * Le_Coyote So if you break out of it, you can resume later
1515690712 M * Guy- that too
1515690721 M * gnarface long before "there's an app for that" became a meme, "there's an emacs module for that" was.  i'd honestly be surprised if there's no kernel config frontend of any sort in there, but i haven't gone looking 
1515690749 M * gnarface if there is one, i bet it supports undo
1515690761 M * Guy- wouldn't it be a "major mode" or somesuch?
1515690774 M * gnarface it might be called a major mode
1515690774 M * Guy- "module" is such a universal word
1515690803 M * Guy- I don't see emacs using it, certainly not in the original meaning :)
1515690805 M * gnarface i'm not sure if major modes are just for file editing in emacs.  there are also functions and stuff separate from the major modes.
1515690834 A * Le_Coyote mutters "vim" and goes into hiding
1515690847 M * gnarface there IS a major mode for the .config file
1515690862 M * gnarface i think it's just a generic config file mode though
1515690869 M * gnarface i don't think it supports context
1515690938 M * Ghislain Le_Coyote: yes you just want to enter each line for the make oldconfig but each time you do that a NON driver question just pass under your nose and you have to restart the process
1515690942 M * Ghislain :)
1515690985 M * Le_Coyote Hein? 
1515691009 M * Ghislain (18:08:23) Le_Coyote: Ghislain: was it you who said the "make oldconfig" was heavy stuff?
1515691015 M * Le_Coyote Ah yeah :)
1515691049 M * Le_Coyote Hence this talk about "undo" or "go back" :)
1515691134 M * Ghislain yep, about your question about lxc  i stayed with vserver because lxc has been a mess for  looong time. The simple quality of a project vserver that is a KISS project make me stick to it because i trust this way of doing
1515691171 M * Ghislain lxc had quite some work but i dont like a giant with argile feets
1515691185 M * Le_Coyote I'm with you on that one. I only fret when there are issues with mainline kernels 
1515691298 M * Ghislain well customers need 4 weeks of warning and such to have a simple reboot done so i prefer not to update the kernel too much. basicaly i wait for linus to rewrite the kernel in rust ;p
1515691330 M * Ghislain bugs would be mathematicaly proven :)
1515691357 M * Le_Coyote Same here. I'd been running 3.14 since Jan 2015 until I switched to 3.18 about 3 months ago
1515691426 M * Ghislain i used 4.1 for only one reason: when under heavy load all others would crawl and 4.1 was the first one that i could put under crazy load and maintain a solaris like access to the console
1515691442 M * Ghislain earlier the kernel was so strugling it loosed all ssh/console
1515691470 M * AlexanderS lxc suffers from bad network isolation, too. There is no _easy_ way to restrict a guest to use a specific ip address.
1515691474 M * Ghislain now i just look at 4.9+ because of the trace support added in BPF i want to play with
1515691483 M * Ghislain yes !
1515691502 M * Ghislain i LOVE to be able to isolate the net and not let the guest touch the stack at all
1515691520 M * Ghislain that is a major feature for me: no stack in the guest to mess with
1515691703 M * Le_Coyote AlexanderS: AH. Now THAT'S a pice of info I didn't have, thanks for that
1515691742 M * Le_Coyote Well ok then. Let's sit this one out until 4.x gets the go-ahead fom the more experienced users
1515691816 M * Le_Coyote Oh btw
1515691843 M * Le_Coyote daniel_hozac: is there anything else I can do regarding the vserver-stat segfault issue (with SSP)?
1515691994 M * AlexanderS Le_Coyote: Lxc does have network namespaces, but it is more like: "Here is an interface for you. You wouldn't do arpspoofing, would you?"
1515692167 M * Le_Coyote Hehe, I get the point :)
1515692285 M * Le_Coyote It's a good thing I came here. I was feeling quite stranded until then :)
1515699590 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951
1515702841 Q * Aiken Remote host closed the connection
1515703154 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951
1515704078 Q * Aiken Remote host closed the connection
1515704163 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951
1515707375 Q * Aiken Remote host closed the connection
1515708468 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951
1515710090 J * Ancient1 ~anciental@8VQAAA0FW.tor-irc.dnsbl.oftc.net
1515712940 Q * Ancient1 autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2018-01-11 23:22:20)
1515712971 J * Ancient1 ~anciental@7MPAAAC57.tor-irc.dnsbl.oftc.net
1515712975 Q * Ancient1 Max SendQ exceeded