1515988036 M * Bertl_oO arekm: excellent! tx!
1515988403 M * Le_Coyote daniel_hozac: is the __constructor__ attribute really necessary in vserver-stat.c (initHertz and initPageSize)? Removing it seems to work on my system and makes it SSP "compatible" (ie no segfault)
1515988892 M * Bertl_oO do the tools pass the test scripts? do they start a guest just fine? does isolation work? does vserver-stat work as expected? if you can answer all of those questions with yes, I'd say it is not necessary ...
1515988992 M * Le_Coyote daniel_hozac: gdb here with assembly: https://imgur.com/a/sXrvS
1515989003 M * Le_Coyote Bertl_oO: everything works except vserver-stat
1515989010 M * Le_Coyote Oh sorry
1515989056 M * Le_Coyote I would say it's not either, since they only seem to initialize the value of Hertz and PageSize, which are initialized in main anyway
1515989109 M * Le_Coyote Bertl_oO: not sure which test scripts you're referring to. I've heard about testfs but never used it since I usually don't foray into very experimental stuff, but that's it
1515989620 M * Bertl_oO testme.sh and testfs.sh are the main test scripts, note that they are not designed to excercise the tools but the kernel
1515989655 M * Bertl_oO but they use the tools, so if something breaks or changes there then it is a good indication that the tools are broken
1515989696 M * Bertl_oO regarding vserver-stat, so does it work now without the __constructor__ attribute or not?
1515989706 M * Ghislain testfs.sh do not work without the patch i sent to the ML long ago 
1515989730 M * Bertl_oO which one was that? URL?
1515989787 M * Ghislain it was an hard engeneered patch that replace 'df' with 'df -k', patch on the ml the 16/11/2017
1515989831 M * Bertl_oO I see, and it fixed what exactly?
1515989842 M * Ghislain if you do nto df on debian use human so it add the K or MB and mess with the results
1515989854 M * Bertl_oO understood
1515989865 M * Ghislain df -k  make it print kilobytes allways so it works
1515989871 M * Bertl_oO okay, I'll see that I add that 'debian' workaround 
1515989894 M * Ghislain well its been one of my greatest acheivement with the dir_emit patch...
1515989930 M * Ghislain also i was wondering about /proc/virtual/xxx/limit
1515989937 M * Bertl_oO which unfortunately got destroyed by me removing the entire thing ... I feel very guilty :)
1515989955 M * Ghislain i have guest that run for 200+ days and most of the counters are at 0 
1515989963 M * Ghislain yes you hurt my feelings !
1515989986 M * Ghislain but your change was based on my profound research and i see no credit in the code, sad world we live in
1515989993 M * Bertl_oO I'm going through the limit stuff too, but what we need there is mainly test cases
1515990019 M * Ghislain well i dont even know what a rmap or vml is
1515990032 M * Ghislain if you have a doc i can try to work on some
1515990046 M * Bertl_oO so I was thinking about either removing most limits (as they are fairly unused nowadays) or creating a test script similar to testfs.sh which checks them
1515990101 M * Bertl_oO the checks are not always trivial though, because some limits do not have a 1:1 relation to what userspace does
1515990142 M * Bertl_oO for example the dentry count will certainly increase if you access (e.g. stat) a file you previously didn't access or create a new one
1515990170 M * Bertl_oO but as it will be cached, the dentry will remain, so it doesn't decrement until the guest is destroyed or some limit is reached
1515990191 M * Bertl_oO (or some kernel heuristics decide to drop the dentry :)
1515990212 M * Ghislain hum that make this limit quite problematic to use, it does increment to infinity on all my servers
1515990225 M * Ghislain       1 DENT:   1518602503             0/1518602503           -1/      -1            0 
1515990225 M * Ghislain       1 DENT:   1645043186             0/      -1             -1/      -1            0
1515990265 M * Ghislain that one i am for removing but i dont use it so perhaps i am not the right one to ask
1515990287 M * Bertl_oO well, it shouldn't do that, but it also won't go up one and down one when you do a stat
1515990314 M * Bertl_oO the problem is with caching here, dentries are not purged/freed unless there is a good reason to do so
1515990332 M * Ghislain but if you delete a file will it ? i mean create 10k files, remove 10k file, what will the dentry be ?
1515990361 M * Bertl_oO there will probably be a negative dentry there for the 'missing' file
1515990385 M * Bertl_oO but I can show you how to do some meaningful testing there
1515990414 M * Bertl_oO the key is to have a separate filesystem which you can mount and unmount 
1515990427 M * Bertl_oO (like for example a tmpfs)
1515990439 M * Bertl_oO where all the testing/accounting happens
1515990440 M * Ghislain ok, the only limits i use are files and proc  
1515990448 M * Ghislain oh that sound easy
1515990475 M * Bertl_oO then you have to make sure that the tests themselves do not create (new) dentries outside
1515990513 M * Ghislain but outside should not count against this context dentry ?
1515990519 M * Bertl_oO so probably the easiest way is to have them run twice (or several times) and only look at the results from the 2nd or later runs
1515990586 M * Bertl_oO so basically create a context with a test mounting a tmpfs, running some tests, unmounting the thing and checking dentry counts before and after
1515990614 M * Bertl_oO repeat that 2-3 times and see if that is stable or always ends with an offset
1515990638 M * Bertl_oO (which would indicate false accounting)
1515990678 M * Bertl_oO back in the old days, accounting like the dentry made a lot of sense to prevent obscure exploits
1515990704 M * Bertl_oO i.e. when a guest is creating endless file entries or similar to fill up memory
1515990736 M * Bertl_oO nowadays with proper cgroup accounting (does it really work in those cases?) it should not be a problem anymore
1515990781 M * Ghislain i just tried in php a flock on a file and the lock count did not increased, should so something bad
1515990839 M * Ghislain if we can have a kernel patched for those intel flaws that works and we can have a reboot week then i would be delighted to write some test like this
1515990871 M * Bertl_oO not sure the lock accounting is still present in recent patches
1515990898 M * Bertl_oO but yes, I have no problem bringing this stuff back to life if there is some interest and we have something to test with
1515990902 M * Le_Coyote Bertl_oO: yes, vserver-stat works perfectly fine without the attribute declaration
1515990910 M * Ghislain it is in the /proc/virtual/xx/limit :) perhaps a cosmetic thing only left over sad and lonely
1515990986 M * Ghislain VM VML RSS ANON RMAP LOCKS, all are 0 on all my guests
1515991003 M * Ghislain and MSGQ
1515991066 M * Bertl_oO well, yes, the API is kind of stable, so those entries do not go away
1515991091 M * Bertl_oO but we can also modernize this if there is a good reason
1515991104 M * Bertl_oO (needs to be synchronized with tool changes)
1515991128 M * Ghislain i dont use them i just noticed that and was wondering if this was becasue some limits fails to be accounted or not
1515991128 M * Bertl_oO in any case, we should make sure that we do not account/limit stuff which is already handled by the mainline kernel
1515991143 M * Bertl_oO because that would simply be a waste of resources doing the accounting twice
1515991196 M * Ghislain agreed
1515991232 M * Bertl_oO here in my test setup for example, the DENT count is at -453 for a test guest on 4.4.x
1515991269 M * Bertl_oO so it is obviously wrong but in the other direction as your observations
1515991278 M * Ghislain my 4.4 is allready at : DENT:     120653               0/  120653
1515991292 M * Ghislain mine has a lamp stack running into it
1515991294 M * Bertl_oO it also decrements by about 11 when I enter the guest
1515991305 M * Ghislain :)
1515991318 M * Bertl_oO no, actually 13 :)
1515991441 M * Bertl_oO the probably solid limits at the moment are PROC, FILES, OFD and SOCK
1515991475 M * Bertl_oO I also assume that SHM and SEM* work, but haven't tested that for a long time
1515991510 M * Ghislain at least the counter goes up/down and seems resonable
1515991520 M * Bertl_oO the memory limits (VM,VML,RSS,ANON,RMAP) have been disabled since memory cgroups handle that 
1515991542 M * Bertl_oO (not sure locked memory is accounted there though)
1515991559 M * Ghislain cgroup do swap , normal and kernel
1515991648 M * Ghislain i dont understand why the memory vmem into guest id not working, we changed to the new functions that should return  consistent result non long ago
1515991721 M * Ghislain do you think kernel memory accounting is the cgroup things that messed it up ?
1515991721 M * Bertl_oO the memory virtualization is a little tricky, because out of tradition there are several (different) interfaces to userspace
1515991732 M * Ghislain ah
1515991748 M * Bertl_oO and an additional problem is that we need to provide indirect data
1515991764 M * Bertl_oO so, the cgroup accounts the used memory and has a limit
1515991782 M * Bertl_oO but userspace needs to be presented with a 'free' memory instead of 'used'
1515991811 M * Bertl_oO so while this sounds easy (just subtract the used from the limit) it unfortunately isn't that simple
1515991950 M * Ghislain yes indeed this sounds easy :)
1515992096 M * Aiken Bertl_oO, with my testing last night there is also testme passed, testfs passed for ext2,3,4 and failed for the others which are not compiled into the kernel so no surprise, last time I looked the guest was running with netns with ipv4 & ipv6
1515992293 M * Bertl_oO Aiken: what were your testfs.sh options?
1515992441 M * Bertl_oO Ghislain: but the VIRT_MEM should be relatively straight forward to fix, I just have to put debug output into all the places where we interface userspace and also verify the consistency and correctness of the output (relative to the cgroup)
1515992471 M * Aiken  -l -t -D and -t -D as per the testfs and testme page
1515992511 M * Bertl_oO ah, please add -xyz as well, ext2 is 'expected' to fail some of those tests, but ext3/4 should pass all
1515992539 M * Bertl_oO (although I do not remember why ext2 fails them)
1515992716 M * Aiken http://rilapy.jbmb.net/vserver/testfs
1515992895 M * Ghislain well if we can figure vmem this is the last thing to check for me before i can patch everything (well start by my machine and walk to the customer ones)
1515994887 M * Bertl_oO Aiken: yeah, that looks about right, tx!
1515994962 M * Bertl_oO Ghislain: so which kernel do we target first with VIRT_MEM?
1515995119 M * Ghislain well 4.4 is all where the test have been done, even if i really look to 4.9+ i feel i wil restart from 0 on this one
1515995144 M * Bertl_oO so let's start with 4.4.x then
1515995151 M * Ghislain also we where several to test the 4.4, so perhaps tell me if you had any hard time on 4.9 compared to 4.4
1515995154 M * Ghislain oky
1515995228 M * Ghislain i just tremble in fear of you asking an addr2line ;p
1515995259 M * Bertl_oO I'll add the instrumentation to the kernel and you put some thought into a simple bash script which prepares a context and cgroup and compares the values outside (from the cgroup) with the values reported inside
1515995291 M * Bertl_oO and maybe does some plausibility checks (like summing up stuff or so)
1515995311 M * Bertl_oO sounds good?
1515995327 M * Ghislain i'll try :)
1515995391 M * Bertl_oO do not hesitate to ask here if you have some questions or encounter an issue or need to make some decisions
1515996932 M * Ghislain well i try to see how testxx.sh do, i see a lot of chcontext but not any creation
1515998675 M * Bertl_oO yeah, that's because those tests are quite happy with short lived contexts
1515998687 M * Bertl_oO there are basically two approaches you can take
1515998713 M * Bertl_oO 1) create a context with a task keeping it around (like e.g. sleep 1000)
1515998742 M * Bertl_oO 2) create a persistent context which will stay around even if there is no task inside
1515998774 M * Bertl_oO but you also need to create the proper cgroup (mem/swap) to do the memory accounting
1515999279 M * Bertl_oO https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
1515999697 M * Bertl_oO (has some example scripts)
1516000253 J * fstd_ ~fstd@xdsl-87-79-99-191.netcologne.de
1516000705 Q * fstd Ping timeout: 480 seconds
1516000705 N * fstd_ fstd
1516001401 M * Bertl_oO https://www.kernel.org/doc/Documentation/cgroup-v1/memcg_test.txt
1516005824 M * Ghislain i see 
1516005964 J * nikolay ~nikolay@149.235.255.3
1516006868 M * Bertl_oO  off to bed now ... have a good one everyone!
1516006878 N * Bertl_oO Bertl_zZ
1516015129 J * druschka_domaintechnik ~druschka@91-135-172-81.net.pr-link.at
1516016569 J * Gremble ~Gremble@cpc1-aztw34-2-0-cust397.18-1.cable.virginm.net
1516021737 Q * Aiken Remote host closed the connection
1516025933 M * Ghislain woha 4.9 will have reptoline but it seems not the 4.4 :(
1516025958 M * Ghislain also to compile it you need a latest gcc that is in no distrib yet
1516026045 M * Le_Coyote Wut?
1516026058 M * Le_Coyote Which version does it require?
1516028200 M * Ghislain latest one 8.0 
1516029222 M * Guy- it's in Debian experimental, fwiw
1516029847 M * Ghislain you mean not buster but the next one then
1516030149 M * Ghislain dam it i will have to rebuild my entire toolchain again (or hope backport got it)
1516030160 M * arekm Bertl_zZ: 4.9 with vserver on x32 fails to build: http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=kernel&id=4a952ea3-1dcc-40cc-9914-b8d98ea2e5ec&action=tail
1516030184 M * arekm Bertl_zZ: err, not x32 but i686 
1516030198 M * Ghislain oh, what is that tool you use to build the kernel ?
1516030226 M * arekm pld/linux rpm packages builder
1516030598 M * Ghislain ok thanks, will have a look :)
1516030967 Q * druschka_domaintechnik Quit: druschka_domaintechnik
1516031034 M * Gremble repo.psand.net now updated with the latest 3.18 and 4.1 kernels
1516031045 M * Gremble 4.4 and 4.9 builds hopefully in a week or two
1516031088 M * Guy- Ghislain: I literally mean debian experimental (so not unstable, which would be sid)
1516031103 M * Guy- Ghislain: this: deb http://http.debian.net/debian experimental main contrib non-free
1516031270 M * Ghislain ohh ok ! sorry
1516032601 Q * nikolay Quit: Leaving
1516032723 N * Bertl_zZ Bertl
1516032921 M * Bertl  morning folks!
1516033585 M * Ghislain hello bertl
1516033872 M * gnarface  morning Bertl!
1516033936 M * Bertl arekm: interesting, tx!
1516033946 M * Gremble Ghislain, are you sure you gcc-8 for building Linux 4.9? It's the debian default for Stretch which compiles with gcc 6.3. Perhaps I missed a crucial part of the conversation.
1516033984 M * Ghislain well the patch reptoline for spectre require a new compiler feature that exist only on the latest gcc8.0
1516033985 M * Bertl I think the cruicial (missing) point is reptoline
1516034002 M * Gremble ah, reptoline
1516034106 M * Bertl but there is also IBRS ...
1516034148 M * Bertl (at least for modern CPUs where a microcode update is available)
1516034169 M * Ghislain ibrs ? Incident Base Reporting System ? :)
1516034218 M * Bertl indirect branch restricted
1516034220 M * Bertl speculation
1516034233 M * Ghislain one solution is to enable only one core and disable context switching so only one thing is done at a time, at least there is no more side channel in the processors core
1516034235 M * arekm Bertl: and 4.4 did build fine on i686
1516034248 M * arekm 4.4 http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=1&name=kernel&id=85a93921-f595-48ad-b1a9-7b134f503783&action=tail
1516034262 M * Bertl yeah, kind of expected, the 64bit changes happened only for 4.9 (yet)
1516034264 M * Ghislain of course, some may be experiencing a little performance issue
1516036794 M * Bertl arekm: hmm, I just did a build with 'linux32' on 4.9.x and I don't get the errors you see, can you tell me how that kernel is built (i.e. what ARCH/other options are given?)
1516037055 Q * Gremble Quit: Leaving
1516039267 M * Bertl off for now ... bbl
1516039272 N * Bertl Bertl_oO
1516041262 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951
1516042983 J * druschka_domaintechnik ~druschka@85.118.185.154
1516043490 M * CcxWrk https://lwn.net/SubscriberLink/744287/5eee1285b812966d/ [Meltdown/Spectre mitigation for 4.15 and beyond]
1516043595 M * Le_Coyote Thanks for that
1516043611 M * Le_Coyote Let's hope, as far as vserver is concerned, there will be backports to 4.4 and 4.9
1516052140 J * Gremble ~Gremble@cpc1-aztw34-2-0-cust397.18-1.cable.virginm.net
1516053803 Q * druschka_domaintechnik Quit: druschka_domaintechnik
1516057213 J * Long_yanG ~long@15255.s.t4vps.eu
1516057355 Q * LongyanG Ping timeout: 480 seconds
1516058044 M * Gremble ah,
1516058436 Q * Gremble Quit: Leaving
1516059560 J * sannes ~ace@2a02:fe0:c130:1d90:243a:5d81:2dad:3f61