1455926603 Q * jrayhawk Quit: glibc upgrade
1455926805 J * jrayhawk ~jrayhawk@nursie.omgwallhack.org
1455929540 N * Bertl_zZ Bertl
1455929541 M * Bertl back now ...
1455929943 Q * fstd Remote host closed the connection
1455930233 J * fstd ~fstd@xdsl-84-44-221-210.netcologne.de
1455932803 J * neofutur neofutur@gabrielle.ww7.be
1455933470 Q * Jb_boin Ping timeout: 480 seconds
1455933730 Q * Aiken Ping timeout: 480 seconds
1455934099 J * Jb_boin ~dedior@proxad.eu
1455934477 M * AlexanderS Is it correct, that "vx_check(task->xid, VS_ADMIN_P|VS_WATCH_P|VS_IDENT)" should be true if the current task is in ctx 1?
1455935408 Q * Ghislain Quit: Leaving.
1455935448 M * Bertl among other cases, yes
1455935480 M * Bertl it will also be true if the task->xid matches and if you are in ctx 0
1455935551 M * Bertl if you just want to check for ctx 1, then vx_check(0, VS_WATCH_P) is what you're looking for
1455935555 Q * Jb_boin Ping timeout: 480 seconds
1455935733 J * Jb_boin ~dedior@proxad.eu
1455936247 M * AlexanderS Strange thing. There is already a check in __ptrace_may_access. But it seems it does not work. If I simply make a wrap the check with a "if (vx_current_xid() != 1)" access to /proc/PID/ns/* works.
1455936322 M * Bertl could it be that you have guest privacy enabled?
1455936352 M * Bertl CONFIG_VSERVER_PRIVACY=y
1455936441 M * AlexanderS Oh yes, that explains it.
1455936494 M * Bertl so most likely, everything is already fine with the kernel then :)
1455936711 M * AlexanderS Yes, I should checked it before. I think I will talk to Ben, if he could change this config option, or I need to build my own kernel.
1455936735 M * Bertl well, usually it is good to honor the privacy of guests
1455937267 M * AlexanderS I could use a something like: for i in /proc/virtual/*/; do chcontext --xid $(basename $i) DO_SOMETHING ; done 
1455937347 M * Bertl like vsomething does?
1455937771 M * AlexanderS Yes something like that. But vsomething uses /etc/vservers/* and I would only need all running contexts, without knowing the name.
1455938152 M * Bertl well, if vsomething ... -- --running doesn't work for you, then you have to do the shell loop
1455940077 J * Aiken ~Aiken@d63f.h.jbmb.net
1455943286 M * Bertl off to bed now ... have a good one everyone!
1455943288 N * Bertl Bertl_zZ
1455948667 Q * fstd Read error: Connection reset by peer
1455948981 J * fstd ~fstd@xdsl-84-44-221-210.netcologne.de
1455949500 Q * fstd Remote host closed the connection
1455949550 J * fstd ~fstd@xdsl-84-44-221-210.netcologne.de
1455949632 Q * fstd Read error: Connection reset by peer
1455949887 J * fstd ~fstd@xdsl-84-44-221-210.netcologne.de
1455950288 J * fstd_ ~fstd@xdsl-87-78-81-57.netcologne.de
1455950305 Q * fstd_ Remote host closed the connection
1455950437 J * fstd_ ~fstd@xdsl-87-78-81-57.netcologne.de
1455950495 Q * fstd Ping timeout: 480 seconds
1455950496 N * fstd_ fstd
1455951414 J * bzed__ ~bzed@shell.bzed.at
1455951430 J * bzed___ ~bzed@shell.bzed.at
1455951715 Q * bzed Ping timeout: 480 seconds
1455951720 N * bzed___ bzed
1455951760 Q * bzed_ Ping timeout: 480 seconds
1455962567 J * Ghislain ~aqueos@adsl1.aqueos.com
1455965737 Q * guerby Quit: Leaving
1455965789 J * guerby ~guerby@2a03:7220:8080:a500::1
1455970730 Q * Aiken Remote host closed the connection
1455973143 Q * fstd Remote host closed the connection
1455973224 J * fstd ~fstd@xdsl-84-44-224-64.netcologne.de
1455974878 N * Bertl_zZ Bertl
1455974879 M * Bertl morning folks!
1455977063 P * undefined 
1455978757 J * undefined ~undefined@00011a48.user.oftc.net
1455986112 J * aj__ ~aj@x590e0051.dyn.telefonica.de
1455992418 M * Bertl off for now ... bbl
1455992419 N * Bertl Bertl_oO
1455998284 J * bonbons ~bonbons@2001:a18:221:fd01:44ab:c36b:66a1:abe
1455999280 J * Aiken ~Aiken@d63f.h.jbmb.net
1456005591 J * Guest4835 ~user@3OZAAGPAZ.tor-irc.dnsbl.oftc.net
1456006102 N * Guest4835 hacworld
1456007508 M * Ghislain hi
1456007528 M * undefined howdy?
1456007540 M * Ghislain FYI 4.1.18 is compiled ok, booted ok. I launched my bench test for some time to stress test it
1456007559 M * Ghislain I modified 2 thing: removed the dentry limits and locks accounting
1456007616 M * Ghislain they were increasing  toward infinity in my previous test and are not used here and since i wa sunable to find and correct it i disabled the counting
1456007639 M * Ghislain ( // vx*_(inc/dec)  )
1456007652 M * Bertl_oO ah, okay, thanks for reminding me
1456007699 M * Ghislain i spotted only 3 thing not working, memory cgroups  virtmem, locks and dentry accounting :)
1456007970 M * Ghislain memory is an issue, the others we do not use them so this is less a problem of course
1456008004 M * Ghislain same i tried to find docs about cgroups and even tried to see how libcroup do it but this is way beyond my knwoledge
1456008053 M * Bertl_oO libcgroup does virtualization?
1456008191 M * Ghislain nope but it manipulate cgroups and i was hopping to find how they read limits
1456008244 M * Bertl_oO I presume from the proc interface
1456008402 M * Bertl_oO the problem is not so much where to get the data from, the cgroups contain the data we need
1456008448 M * Bertl_oO the problem is more that the cgroup itself is a moving target and the maintainers make sure that the interface is complicated and hides all the data
1456008478 M * Ghislain well you would not want to spoil the fun arent you ?
1456008500 M * Bertl_oO which in turn means that we have to undo all the hiding and make the relevant data available so that it can be used outside the cgroup mechanism, e.g. for virtualizing the memory/swap view
1456008599 M * Ghislain what do you mean undo all the hidding ?
1456008622 Q * hacworld Remote host closed the connection
1456008811 M * Bertl_oO we have a function called vx_vsi_swapinfo() which corrects the values before they are sent to userspace
1456008831 M * Bertl_oO i.e. it gets the cgroup for a task and retrieves the limit as well as the current usage
1456008848 M * Bertl_oO then adjusts the global values accordingly before they are passed on to userspace
1456008893 M * Ghislain yes, you mean you have allmost to adapt this one for every move of the cgroup api
1456008893 M * Bertl_oO the memory cgroup is easy to get via mem_cgroup_from_task()
1456008913 M * Bertl_oO which returns a struct mem_cgroup
1456008954 M * Bertl_oO or more precisely, a pointer to that struct
1456008967 M * Bertl_oO which is a private struct, i.e. it is only defined inside memcontrol.c
1456009197 M * Ghislain well i dont really understand what that means, sorry. Pointer ok, private struct then i am lost
1456009216 M * Bertl_oO it means that we can't just look at the values from inside the kernel
1456009226 M * Ghislain sounds like you cannot access it directly but need to send it to a function that can ?
1456009237 M * Bertl_oO we have to add accessory functions to retrieve them, or make the cgroup structure public
1456009244 M * Ghislain oh, but there is not any api to access it ?
1456009257 M * Bertl_oO not inside the kernel, no
1456009301 M * Ghislain you mean you can from outside but not from inside ? that sound silly :)
1456009323 M * Bertl_oO it is
1456009334 M * Ghislain it talks only to userland then
1456009691 M * Ghislain so i see why you say you add a function to permit that  or change the struct to public  but that could result in behavior we do not foresee
1456009729 M * Ghislain the function will allow a read only access to the values i guess
1456009867 M * Ghislain but if this is private how could you anyway do it in an 'accessory'  function ? (sorry for behind so noob here)
1456009897 M * Ghislain if the fondamental object ( rpivate struct) is the same any functions in the kernel will have the same issue
1456009908 M * Ghislain including the cgroup code itself ?
1456010017 M * Ghislain or duplicate the mem_cgroup_from_task() to return somethign non private
1456010035 M * Bertl_oO well, currently there is no other user but the cgroup subsystem itself
1456010111 M * Ghislain this system is recent but seems to have been created like in the old day on his own island, anyway i am not a dev so what do i know how this can be done in kernel land :(
1456010139 M * Ghislain api are all over the web but kernel is another matter perhaps
1456010177 M * Bertl_oO 3.x provided "internal" accessory functions called res_counter_read_u*()
1456010196 M * Bertl_oO so all we had to do is make a wrapper which uses the correct memcg
1456010209 M * Bertl_oO in 4.x the accessory functions are gone
1456010279 M * Ghislain they just removed their 'api' ? wooo ok i see the issue
1456010317 M * Ghislain        res_counter: delete res_counter_write()           Since commit 628f423 ("memcg: limit change shrink usage") both res_counter_write() and write_strategy_fn have been unused.  This patch deletes them both.
1456010340 M * Ghislain i see they provide api and as they do not use it they remove it... that is ... strange
1456010344 M * Bertl_oO check for res_counter_read_u64
1456010384 M * Bertl_oO removed between 3.18 and 3.19
1456010468 M * Bertl_oO I have no idea if there is a replacement available somewhere and how it might be called
1456010480 M * Ghislain check this one :https://github.com/torvalds/linux/commit/5b1efc027c0b51ca3e76f4e00c83358f8349f543
1456010488 M * Ghislain All memory accounting and limiting has been switched over to the lockless page counters.  Bye, res_counter!
1456010498 M * Ghislain page_counter ?
1456010620 M * Bertl_oO I see page_counter_read() which returns an unsigned long
1456010650 M * Bertl_oO which is 32bit on many architectures, but I presume it now counts pages instead of bytes
1456010657 M * Bertl_oO (so that might suffice)
1456010692 M * Bertl_oO the question is now, how to get to the page_counter?
1456010700 M * Ghislain yes i think that it is pages because all the cgroup thing is about pages
1456010726 M * Ghislain lol there is allways another step, let me decompress the 4.1.18 and have a look
1456010766 M * Ghislain i bet the way is pretty similar with the name change, but this would spoil the fun so there must be another trick
1456011567 M * Ghislain page_counter_memparse ?
1456011613 M * Ghislain nope
1456011627 M * Bertl_oO give me a few minutes, I have a plan :)
1456011633 M * Ghislain ok lol