1161996221 Q * mire Remote host closed the connection 1161996629 J * meandtheshell ~markus@85-124-232-237.work.xdsl-line.inode.at 1161998818 J * debugger_ Rui@217.129.151.190 1161999286 Q * debugger Ping timeout: 480 seconds 1161999458 N * debugger_ rgl 1162000516 J * blabla ~martin@modemcable247.168-202-24.mc.videotron.ca 1162000880 M * blabla I think I have found a bug in the patch-2.6.17.13-vs2.0.2.1.diff 1162000880 M * blabla the problem is in the kernel/timer.c 1162000880 M * blabla error message from the compiler: kernel/timer.c:1041:2: #endif without #if 1162000880 M * blabla so looked into the code and found that in the orginal file at line 1581 there is a #ifndef __alpha__ and this is missing in the patched version 1162000880 M * blabla I added it back, was it supposed to be removed or is it effectively a bug ? 1162001008 M * Bertl yeah, should be fine, but IIRC, we already fixed that 1162002168 J * bronson_ ~bronson@c-71-198-75-160.hsd1.ca.comcast.net 1162002473 J * _mcp ~hightower@wolk-project.de 1162002631 Q * mcp Read error: Connection reset by peer 1162003451 Q * ms_ Ping timeout: 480 seconds 1162004145 Q * ensc Killed (NickServ (GHOST command used by ensc_)) 1162004155 J * ensc ~irc-ensc@p54B4EAFE.dip.t-dialin.net 1162004314 J * Aiken ~james@tooax6-058.dialup.optusnet.com.au 1162005722 J * FireEgl FireEgl@2001:5c0:84dc:1:4::1 1162006018 J * debugger ~Rui@217.129.151.190 1162006471 Q * rgl Ping timeout: 480 seconds 1162006625 J * Aiken_ ~james@tooax8-192.dialup.optusnet.com.au 1162006951 Q * Aiken Ping timeout: 480 seconds 1162008114 M * Bertl okay, seems we tracked down the x86_64 issue, thanks to ntrs! 1162008139 M * Bertl will upload a patch tomorrow (because it is kind of ugly atm) 1162008157 M * Bertl and I'm pretty tired, so I'm off to bed now! 1162008166 M * Bertl have a good one everyone, cya! 1162008171 N * Bertl Bertl_zZ 1162008437 J * gerrit_ ~gerrit@adsl-75-2-53-116.dsl.ipltin.sbcglobal.net 1162009793 Q * Johnnie Ping timeout: 480 seconds 1162010180 J * ms_ ~ms@arkansas.doc.ic.ac.uk 1162010492 Q * yang Ping timeout: 480 seconds 1162010582 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net 1162011565 Q * Aiken_ Quit: Leaving 1162012533 J * bubulak ~bubulak@whisky.pendo.sk 1162013219 J * debugger_ ~Rui@217.129.151.190 1162013691 Q * debugger Ping timeout: 480 seconds 1162015616 Q * yang Ping timeout: 480 seconds 1162015679 J * yang ~yang@cpe-213-157-253-172.dynamic.amis.net 1162016323 J * Aiken ~james@tooax8-192.dialup.optusnet.com.au 1162017218 Q * debugger_ Read error: Connection reset by peer 1162017376 Q * _are_ Ping timeout: 480 seconds 1162020856 J * dna_ ~naucki@49-245-dsl.kielnet.net 1162021562 M * phreak`` Bertl_zZ: when you wake up, could you please take a look at http://dev.gentoo.org/~phreak/projects/vserver-sources/bugs/2.6.18-vs2.0.2.1-t8/2006-10-28.log and http://dev.gentoo.org/~phreak/projects/vserver-sources/bugs/2.6.18-vs2.0.2.2-rc3/2006-10-28.log ? That would be great :) 1162021751 J * _are_ ~are@62.112.159.81 1162022870 Q * bronson_ Ping timeout: 480 seconds 1162024699 J * Aiken_ ~james@tooax6-086.dialup.optusnet.com.au 1162024966 Q * Aiken Ping timeout: 480 seconds 1162025606 Q * ms_ Ping timeout: 480 seconds 1162027206 Q * _are_ Ping timeout: 480 seconds 1162027415 J * _are_ ~are@62.112.159.81 1162028996 J * mire ~mire@209-167-222-85.adsl.verat.net 1162030243 J * s0undt3ch_ ~s0undt3ch@81.193.57.100 1162030670 Q * s0undt3ch Ping timeout: 480 seconds 1162030670 N * s0undt3ch_ s0undt3ch 1162031606 Q * _are_ Ping timeout: 480 seconds 1162032335 J * ms_ ~ms@arkansas.doc.ic.ac.uk 1162032890 J * gpiero ~gpiero@adsl-ull-145-40.44-151.net24.it 1162032973 P * gpiero 1162033041 M * daniel_hozac phreak``: that's one of the issues we were tracking down yesterday. 1162033089 M * daniel_hozac phreak``: the 2.0.2.1-t8 looks very interesting... what were you doing to cause that? 1162033138 M * phreak`` daniel_hozac: running `emerge -e world` on my host and within a chroot; after that oops everything was segfaulting :) 1162033188 J * bonbons ~bonbons@83.222.36.111 1162033268 Q * dna_ Read error: Connection reset by peer 1162033272 N * _mcp mcp 1162033482 J * dna_ ~naucki@49-245-dsl.kielnet.net 1162033786 N * mcp _mcp 1162033852 M * phreak`` daniel_hozac: another thing I just encountered is this: 1162033860 M * phreak`` # vserver vs-mirror enter 1162033861 M * phreak`` vnamespace: vc_enter_namespace(): Permission denied 1162033904 M * daniel_hozac on stable? 1162033927 M * phreak`` nope, thats 2.1.1_rc43 1162033941 M * daniel_hozac ah, ok. 1162033955 M * daniel_hozac so somehow you removed STATE_ADMIN from the context. 1162034104 M * daniel_hozac anything strange about that guest or so? 1162034136 M * phreak`` only thing I've done recently is tar'ing up / (including /vservers) and packed that out on another disk. 1162034261 M * phreak`` ok, 2.1.1_rc43 also has the pid_task bug :| 1162034290 M * phreak`` started with Oct 28 12:28:36 epimetheus vxW: pid_task(3582,0): task c1d91070[#20,4222] did lookup f797ea90[#15,3582] 1162034867 M * daniel_hozac yeah, they both have that warning. 1162034896 M * daniel_hozac but those results are weird. 1162034907 M * daniel_hozac why is a process in context 20 trying to lookup a process in context 15? 1162034928 M * phreak`` no clue ... 1162035762 J * Nysis ~Office@dslb-088-073-029-068.pools.arcor-ip.net 1162035775 P * Nysis 1162035784 J * Nysis ~Office@dslb-088-073-029-068.pools.arcor-ip.net 1162035809 M * Nysis >:o 1162036212 M * Hollow daniel_hozac: do you want to take care of http://linux-vserver.org/Installation_on_Fedora ? 1162036929 P * Nysis 1162036952 M * daniel_hozac Hollow: powerfox has been taking care of the Fedora HOWTOs earlier. 1162037026 M * Hollow ok, will ask him to migrate the approriate pages then 1162039430 Q * Aiken_ Quit: Leaving 1162039767 J * rgl Rui@217.129.151.190 1162039771 M * rgl hello 1162039776 M * daniel_hozac hi 1162039847 M * rgl I'm trying to move all daemon from listening at 0.0.0.0, but now I'm stuck because it seems that xinetd can only listen at one interface a time... or maybe not? 1162039874 M * daniel_hozac the daemons on the host? 1162039900 M * daniel_hozac because, uh, you don't have to limit guests, they're already limited to their subset of IP addresses. 1162039944 M * rgl oh they are? 0.0.0.0 on the guest is 0.0.0.0 for the guest IPs? 1162039971 M * daniel_hozac yes, of course. 1162039973 M * rgl err 0.0.0.0 on the guest means it listen on all the guest IPs? 1162039981 M * rgl gee, dumb me! hehe 1162040118 J * Piet hiddenserv@tor.noreply.org 1162042134 M * Hollow daniel_hozac: do you know where i can find out which ulimits are supported inside looking at the kernel source..? 1162042141 M * Hollow bit lost here 1162042145 M * daniel_hozac hmm? 1162042158 M * daniel_hozac we don't change how ulimits work, do we? 1162042198 M * Hollow thought so too... but i'm currently migrating the resource limits page, and there is a column stating whether ulimit is supported or not, and it is different from what man ulimit/grep RLIMIT -r /usr/src/linux says.. 1162042218 M * Hollow so either it is outdated, or there is some difference.. 1162042335 M * daniel_hozac hmm, maybe the U means supported in the util-vserver configuration? 1162042351 M * daniel_hozac well no, that's a separate field... 1162042377 M * daniel_hozac well, i don't know, but i'd be inclined to say it's outdated. 1162042381 M * Hollow apropos... any plans about supporting VLIMITs with names too? 1162042395 M * daniel_hozac hmm? 1162042419 M * Hollow in vlimit.c i mean 1162042428 M * Hollow it defines all limit numbers, but not all names 1162042494 M * daniel_hozac ah, in util-vserver? 1162042512 M * Hollow yep 1162042549 M * daniel_hozac that would certainly make sense :) 1162042591 M * Hollow also some of the limits supported with names are not valid rlimits currently, though they are checked against rlimit_mask iirc... probably a cleanup would be good here :) 1162042614 M * daniel_hozac indeed. 1162042795 M * Hollow also the names in /proc/virtual/*/limit are quite inconsistent... will poke bertl about it ;) 1162042824 Q * mire Quit: Leaving 1162043186 Q * rgl Ping timeout: 480 seconds 1162044265 N * Bertl_zZ Bertl 1162044269 M * Bertl morning folks! 1162044275 M * Bertl Hollow: get your stick :) 1162044308 M * Hollow morning Bertl :) 1162044345 M * daniel_hozac morning 1162044345 M * Hollow Bertl: a few question regarding rlimits... in the old resource limits page, there is a column stating uliimt (supported), what exactly does that mean? 1162044366 M * Bertl simple, when we designed the rlimits 1162044375 M * Bertl we based this design on the ulimits 1162044388 M * Bertl (for ulimits, see man bash) 1162044409 M * Bertl now, the (so called) rlimits are limits 'per guest' 1162044427 M * Bertl while the ulimits are 'inherited' limits 'per process' 1162044436 M * Bertl example: 1162044454 M * Bertl NOFILE=10 as ulimit means 10 files per process 1162044469 M * Bertl NOFILE=10 as rlimit, means 10 files in the entire context 1162044484 M * Bertl (does that explain it?) 1162044488 M * Hollow ok, clear so far, but you can only set ulimits inside, right? 1162044505 M * Bertl nope, you can use ulimits everywhere 1162044521 M * Bertl and without the resource caps, you cannot change it afterwards 1162044528 M * Hollow yeah, but there is no vcmd for setting ulimits, you just sys_setrlimit for those.. 1162044536 M * Hollow +use 1162044542 M * Bertl yep, that's right 1162044552 M * Bertl so you 'set' it on guest startup, that's it 1162044567 M * Hollow so why is there an extra column stating if an ulimit is supported or not? aren't all RLIMIT_* supported? 1162044568 M * Bertl if you want to change them on the fly, you ahve to do the same for each process 1162044595 M * Bertl Hollow: nope, we added some rlimits and ulimit doesn't handle all of them 1162044624 M * Hollow with rlimits you mean RLIMIT_* or VLIMIT_*? 1162044672 M * Bertl the VLIMITs are RLIMITs too, just added by us, and named sligtly different 1162044735 M * Hollow yep, that's clear, but ulimit does support all RLIMIT_*, and it does support none of VLIMIT_* ... 1162044741 M * Hollow so the column doesn't make much sense to me 1162044762 M * Bertl url 1162044769 M * Hollow http://oldwiki.linux-vserver.org/Resource+Limits 1162044852 M * Bertl hmm, what I wonder is the flags '-' for RSS and AS 1162044867 M * Bertl but IIRC, it is because mainline didn't support them at some point 1162044877 M * Hollow i see... 1162044907 M * Hollow there are others flaws as well IMO... e.g. OPENFD is only accounted and not enforced (at least a grep in the kernel source said so) 1162044945 M * Hollow i.e. there is no use of vx_openfd_avail anywhere... 1162044947 M * Bertl we should definitely check (and lateron fix) that 1162044971 M * Hollow ok, i will do (at least) check that... 1162044975 M * Bertl and we should keep a list around 1162044975 M * Hollow as i migrate the page currently 1162044993 M * Bertl excellent, daniel_hozac, doener: around? 1162045043 M * Hollow Bertl: so, if no vx_*_avail is used i can assume that it is only accounted and not enforced currently, right? 1162045125 M * Bertl yes, I'd say so 1162045149 M * Hollow ok, i will update the new page accordingly then.. 1162045223 M * Bertl okay, and please while you are at it, complain about every missing check here, I'll double check that then just to make sure (and/or add it with priorities to the ToDo list) 1162045289 Q * gdm Quit: Reconnecting 1162045298 J * gdm ~gdm@www.iteration.org 1162045804 M * Hollow Bertl: btw... what is SEMARY? 1162045821 M * Bertl semaphore arrays 1162045825 M * Hollow thx 1162045906 Q * shedi Quit: Leaving 1162046305 J * spq_ ~spq@dslb-084-063-003-208.pools.arcor-ip.net 1162046384 P * spq_ 1162046869 M * Hollow Bertl: http://paste.linux-vserver.org/578 lists all limits that should be enforced, although some of them only contain a definition in vs_limit.h/vs_memory.h ... 1162046922 M * Hollow off now for a bit... back in an hour or so.. 1162046965 M * Bertl okay, memory checks are a little different than other limits 1162047396 Q * gerrit_ Ping timeout: 480 seconds 1162047455 M * matti :) 1162047459 M * matti Hello Bertl, Hollow :) 1162047466 M * Bertl hey matti! everything fine? 1162047513 A * phreak`` looks into #vserver and ducks 1162047590 M * gdm Bertl: is vserver networking dependent on nat or anything? 1162047596 M * gdm my networking seems broken 1162047596 Q * ms_ Ping timeout: 480 seconds 1162047608 M * matti phreak``: You cannot hide! 1162047609 M * Bertl gdm: nope, but lets hear your problems ... 1162047609 M * matti ;p 1162047611 M * matti phreak``: Hello :) 1162047613 M * matti Hi gdm :) 1162047624 M * gdm it is since i started playing around with teh firewall... but now i turned it off and it doesn't work still 1162047644 M * gdm i have ppl connecgted to an ircd on a vserver. but new ppl cannot connect 1162047645 M * h01ger gdm, default policies? 1162047658 M * phreak`` matti: yes, I can *g* just need my camouflage tent ;) 1162047665 M * phreak`` matti: heya :) 1162047689 M * matti Bertl: Yes, fine. I am a bit lonely, but besides that... yeah, everything is fine :) And you? 1162047692 M * matti phreak``: Hahah. 1162047699 M * Bertl gdm: what do you get when you telnet to the port? 1162047735 M * matti phreak``: I've a thermal video camera, you _cannot_ hide ;-p :)) 1162047744 M * phreak`` oO 1162047745 M * Bertl matti: well, get out .. to the movies or something like that, mett some people ... 1162047750 M * phreak`` matti: darn spy 1162047752 M * Bertl *meet 1162047780 M * gdm http://paste.linux-vserver.org/579 1162047819 M * matti phreak``: Szyy... This is a deep secret, you know... I'm working for Her Majesty and stuff like that ;p 1162047838 M * phreak`` aaaah :) 1162047851 M * matti Bertl: Thanks, will do :) 1162047871 M * Bertl matti: do you like jazz? 1162047877 M * matti Bertl: Yes. 1162047895 M * Bertl there are many nice jazz clubs around london IIRC 1162047910 M * gdm matti: you in london? 1162047918 M * gdm matti: i thought you were in south west 1162047922 M * matti Yes. 1162047924 M * matti Indeed. 1162047929 M * matti And there's nothing to do here ;p 1162047932 M * matti To be honest. 1162047933 M * matti ;] 1162047935 M * gdm hehe. 1162047945 M * gdm there is good jazz in bristol, if you ever get up there 1162047946 M * matti Besides country sides... and atlantic ocean ;p 1162047970 M * Dimmu and there is good cider in bristol :) 1162047972 M * Bertl well, uk public transportation isn't so bad 1162047982 M * matti gdm: Bristol is about 3 and a half hour by car ob coach :< 1162047989 M * matti Bertl: No bad - yes. 1162047996 M * matti Bertl: But expensive also ;] 1162048002 M * gdm telnet seems to work, Bertl but the reconnect does not 1162048022 M * gdm micah is going to get up soon, so i will get him to help me i hope ;-) 1162048023 M * Bertl gdm: well, then it is an ircd issue, not a network one 1162048042 M * matti gdm, Dimmu: Maybe we can meet in London? Or something? :) 1162048043 M * Bertl for the telnet to work, both directions have to be fine 1162048054 M * Dimmu I don't live in the UK :) 1162048061 M * Dimmu I was last week however :) 1162048065 M * matti Dimmu: Oh :) 1162048075 M * matti Dimmu: And you're from...? 1162048076 M * matti ;] 1162048078 M * Dimmu NL 1162048088 M * matti ;] 1162048169 M * gdm Bertl: the # CONFIG_IP_NF_NAT is not set shoudlnt' matter should it? 1162048184 M * gdm it was working before i messed with it yesterday, so i think not 1162048198 M * gdm it's also all the apt-proxy stuff as well, this is frustrating! 1162048207 M * gdm but i guess i will learn some stuff from it ;-) 1162048297 M * Bertl you showed the filter table on your paste, have you checked the nat table and the mangle table too? -t nat -t mangle? 1162048312 M * gdm there is no nat table 1162048317 M * gdm magle... i dont' know 1162048339 M * Bertl ah, yes, without CONFIG_IP_NF_NAT there is none, right :) 1162048360 M * gdm there is no mangle either 1162048371 M * gdm but i cannot telnet out of a vserver 1162048385 M * Bertl vserver has public ip? 1162048425 M * gdm yep 1162048435 M * gdm 209.51.169.94 1162048454 M * Bertl maybe your next hop router doesn't route that anymore? 1162048494 M * Bertl check for outgoing packets with tcpdump 1162048497 M * gdm i don't have control over that... how would i figure it out? 1162048520 M * Bertl start with a ping -I www.google.com (on the host) 1162048553 M * gdm that works 1162048596 M * Bertl now try from inside the guest 1162048613 M * gdm that works too 1162048626 M * Bertl so, network connectivity and routing is fine 1162048631 M * gdm yep 1162048653 M * Bertl try the telnet which failed, and tcpdump with a filter on the telnet port and icmp 1162048668 M * Bertl (tcpdump on the host) 1162048721 M * gdm oh, problem tho 1162048728 M * gdm i don't have tcpdump installed 1162048735 M * gdm and the apt-get is broken 1162048744 M * Bertl cool setup! :) 1162048762 M * daniel_hozac apt-get is broken on the host too? 1162048767 J * _node ~node@c-69-143-154-220.hsd1.md.comcast.net 1162048801 M * gdm oh wait. wierd 1162048842 M * matti ;] 1162048912 M * gdm it is broken on the host but working on another gues 1162048926 M * gdm so i now have tcpdump in a guest 1162048944 M * gdm both the host and the guest were using the apt-proxy (inside a vserver) 1162048951 M * gdm i am very confused! 1162049023 M * gdm ok. when i change the host to use proper repositories, it works 1162049357 M * Bertl a step into the right direction ... 1162049459 M * gdm ok, so maybe it is teh other site which is broken for that telnet command 1162049462 M * gdm so that is ok, i think 1162049486 M * Bertl IMHO you verified all network conenctivity on host and guest 1162049520 M * Bertl so either the ircd is broken, or some router (outside your control) is adding some kind of firewalling/DoS protection 1162049874 M * gdm yeah, i think you must be correct 1162049876 M * gdm ;-) 1162050116 Q * blabla Quit: Download Gaim: http://gaim.sourceforge.net/ 1162050858 M * derjohn Hi Bertl ! Is there still an issue with rc43 ? Or did I misunderstand the fragment of the chat yesterday ? 1162051069 M * phreak`` daniel_hozac: btw, remember about the STATE_ADMIN you told me ? all vServer suffer from the same, I can't enter any vServer :) 1162051096 M * Bertl derjohn: still an issue with rc43, but fix is already there and rc44 will be out pretty soon 1162051104 M * daniel_hozac phreak``: humm, really? with util-vserver? what's your configuration like? 1162051111 M * Bertl derjohn: (with a bunch of other fixes we made on the way) 1162051129 M * daniel_hozac Bertl: VXF_STATE_ADMIN isn't removed unless done so explicitly, right? 1162051131 M * phreak`` daniel_hozac: lemme upload it 1162051142 M * daniel_hozac (util-vserver still using VCMD_ctx_create_v0) 1162051150 M * Bertl daniel_hozac: old/legacy interface no 1162051164 M * Bertl daniel_hozac: new style interface requires it to be given 1162051169 M * daniel_hozac _v1, right? 1162051171 M * derjohn Bertl, fixes, no extension !!?? 1162051203 M * Bertl extension? 1162051219 M * phreak`` daniel_hozac: http://dev.gentoo.org/~phreak/etc-vservers.tar.bz2 1162051222 M * Bertl derjohn: btw, did you stop writing the changelogs at some point? 1162051328 M * Bertl daniel_hozac: http://linux-vserver.org/VCMD_HowTo 1162051330 M * derjohn Bertl, yes, as I wasnt able to get useful information abou the changes 1162051348 M * derjohn I think we should restart with the chanelog after the next devel release 1162051358 M * derjohn beginning with rc1 ;) 1162051378 M * daniel_hozac well, i think we really should have a changelog to release 2.1.1. 1162051415 M * daniel_hozac Bertl: ok? 1162051426 M * Bertl see the ^34 1162051426 M * derjohn daniel_hozac, full ack. 1162051449 M * daniel_hozac Bertl: yeah, but that's not required for ctx_create_v0, is it? 1162051454 M * daniel_hozac in fact, it's not supported at all. 1162051486 M * daniel_hozac (util-vserver is still using that since it would otherwise be incompatible with older kernels ;)) 1162051548 M * daniel_hozac phreak``: what happens if you remove the flags file? 1162051688 M * daniel_hozac phreak``: OH! you have lock in the flags file, hehe. 1162051690 M * Bertl daniel_hozac: yep, that's what I said, legacy automatically adds it 1162051714 M * daniel_hozac Bertl: ah, i just interpreted legacy as vc_new_s_context. 1162051774 M * daniel_hozac Bertl: VXF_INFO_LOCK is reused in recent devel patches to mean what it used to mean, right? 1162051809 M * daniel_hozac basically, it does something again. 1162051820 M * Bertl yep, IIRC 1162051824 M * daniel_hozac phreak``: so that's why you can't enter it, not the lack of VXF_STATE_ADMIN. 1162051828 M * Bertl let me check 1162051832 M * daniel_hozac quick grep shows that, at least. 1162051841 M * Bertl okay, then it's fine 1162051860 M * phreak`` daniel_hozac: hrm, I just removed the flags file :) 1162051875 M * daniel_hozac any reason you had lock and nproc in there? 1162051888 M * Bertl because the debian newvserver sets them :) 1162051909 M * phreak`` daniel_hozac: back then when I first set up that host, it was needed (1.9.5 iirc) 1162051918 M * phreak`` Bertl: nope, no Debian 1162051926 M * Bertl phreak``: nah, never needed 1162051932 M * phreak`` k 1162051947 M * Bertl phreak``: but I remember jacques tools to set it unconditionally 1162051976 M * Bertl it basically was a 2.4 legacy thing 1162052004 M * daniel_hozac seems strange to default to lock. 1162052006 M * phreak`` hrm, at least the first howto i looked at had something about that in it :) 1162052057 M * daniel_hozac FC6 kernel pushed, for those interested. :) 1162052108 M * phreak`` ok, that works now again. 1162052121 M * Bertl would be itneresting to find the howto 1162052124 M * phreak`` but still somehow triggered the pid_task thing :) 1162052144 M * Bertl yep, that's okay, will go away with rc44 1162052345 M * daniel_hozac the warning or the problem? :) 1162052359 M * Bertl 90% problem plus the stack trace 1162052364 M * Bertl warning will remain 1162052385 M * phreak`` hrm, still weird that one process from another context is looking up something from a seperate context :) 1162052823 M * daniel_hozac indeed. 1162052827 M * daniel_hozac Bertl: what was the cause? 1162052860 M * Bertl it is a mainline bug, but in an error path which never shows up 1162052884 M * daniel_hozac ok. 1162052913 M * Bertl http://vserver.13thfloor.at/Experimental/delta-problem.diff 1162052931 M * Bertl see the iput() in the middle of that patch? 1162052967 M * Bertl this _was_ harmless in 2.6.17, it causes the x86_64 issues in 2.6.18 1162053004 M * daniel_hozac ah. 1162053688 J * rgl Rui@217.129.151.190 1162053704 M * Bertl wb rgl! 1162053715 Q * ensc Remote host closed the connection 1162053717 M * rgl hello :D 1162053784 J * ensc ~irc-ensc@p54B4EAFE.dip.t-dialin.net 1162054325 J * ms_ ~ms@arkansas.doc.ic.ac.uk 1162054536 M * Hollow Bertl: http://wiki.linux-vserver.org/Resource_Limits 1162054588 M * Bertl hehe, I'd suggest to invert the 'N' flag to 1162054609 M * Bertl something like 'N' not supported with config/tool name 1162054642 M * Hollow heh, ok, will do 1162054670 M * Bertl and the LV Resource limits are missing the 'N' annotation 1162054684 M * Bertl (most of them should be supproted by the tools now, IIRC) 1162054721 M * Bertl but looks really nice! tx! 1162054834 M * Hollow well, you can always use the limit number, but especially VLIMITs are not supported by vlimit.c ;) 1162054860 M * Hollow ok, updated 1162054875 M * Hollow i have also migrated http://wiki.linux-vserver.org/Installation_on_Gentoo 1162054889 M * Hollow maybe you can migrate it for mandrake? 1162054903 M * Bertl there is one for andrake? 1162054907 M * Bertl *mandrake 1162054920 M * Bertl will have a look when I find some time 1162054935 M * Hollow indeed.. there is none 1162055932 Q * micah Quit: leaving 1162055943 J * micah ~micah@micah.riseup.net 1162056036 M * Hollow daniel_hozac: btw, also the exec-ulimit is missing some rlimits... AS, SIGPENDING, MSGQUEUE and RTPRIO (although the last may be useless, dunno) 1162056067 M * daniel_hozac do all of them exist on 2.4? 1162056079 M * Hollow no 2.4 around here... 1162056145 M * Hollow but exec-ulimit is also for 2.6, no? at least if i understood bertl correctly, those limits set with sys_setrlimit will get inherited on context startup.. 1162056153 M * daniel_hozac yep. 1162057193 J * mire ~mire@233-167-222-85.adsl.verat.net 1162057313 T * Bertl http://linux-vserver.org/ <- new and shiny | latest stable 2.02.1, exp 2.02.2-rc3, devel 2.1.0, exp 2.1.1-rc44, stable+grsec 2.0.2.1 | util-vserver-0.30.211 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1162057322 M * Bertl *rc44, stable will follow shortly 1162057344 M * Bertl have to take a shower first though ... 1162057503 M * Hollow nice :) 1162057517 M * Hollow off to dinner... bbl 1162057697 Q * sladen Ping timeout: 480 seconds 1162057880 M * gdm hi, question: it's possible to limit the memmory, cpu, etc of a vserver. is it also possible to do that for the host? 1162058014 J * sladen paul@starsky.19inch.net 1162058276 M * daniel_hozac no, the host is unlimited. 1162059998 M * gdm and when you are building a new vserver, does the resource consumption reflect under the host or under the (new) guest? 1162060026 M * daniel_hozac with most build methods, the host. 1162060321 Q * derjohn2 Ping timeout: 480 seconds 1162060358 J * derjohn2 ~aj@dslb-084-058-203-216.pools.arcor-ip.net 1162060893 J * debugger Rui@217.129.151.190 1162061346 Q * rgl Ping timeout: 480 seconds 1162061738 M * Bertl daniel_hozac: any patches from you which I did forget in rc44? 1162061754 M * daniel_hozac nope. 1162061764 M * daniel_hozac or, hmm, mips? 1162061786 M * daniel_hozac yeah, that's missing. 1162061791 M * Bertl url? 1162061821 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-mips-fix01.diff s/VX_WATCH/VX_WATCH_P/ 1162061874 M * Bertl ah, good 1162061895 Q * matled Read error: Connection reset by peer 1162061907 M * Bertl I'll run rc44 through PLM, let's see what turns up 1162061937 M * daniel_hozac sounds like a plan. 1162061944 M * daniel_hozac anything left that needs fixing before a release? 1162061952 M * Bertl nope, not that I know of 1162061960 M * Bertl but I'm glad we delayed the release 1162061970 M * Bertl some ugly things got fixed 'on the way' :) 1162061975 M * daniel_hozac indeed. 1162061988 M * daniel_hozac are we going to keep the IRQ switches? 1162062003 M * Bertl atm, yes 1162062012 M * daniel_hozac ok. 1162062028 M * doener Bertl: btw, did the git-bash-monster work as expected? 1162062042 M * Bertl but I'd like to find a solution (like the discussed in_interrupt()) for 2.2 1162062049 M * Bertl doener: worked like a charm 1162062053 M * doener ok 1162062071 M * Bertl http://www.13thfloor.at/~herbert/ebiederm_pid/ 1162062101 M * Bertl but didn't really help much :) but that's another thing ... 1162062138 M * doener did the problem get fixed some other way? which problem are we searching for actually? *g* 1162062155 M * Bertl hehe, there are no known problems atm :) 1162062181 M * Bertl daniel_hozac: hmm, the mips patch fails for rc44 1162062191 M * daniel_hozac even with s/VX_WATCH/VX_WATCH_P/? 1162062214 M * Bertl yes, but let me check if I replaced all oocurences 1162062246 M * Bertl ah, such a long patch, missed the second one *G* 1162062254 M * daniel_hozac hehe. 1162062422 Q * micah Quit: leaving 1162062426 J * micah ~micah@micah.riseup.net 1162062552 M * Hollow Bertl: will you prepare a changelog? 1162062698 M * Bertl yes, I'll have to :) 1162062717 M * Hollow ok, will prepare the usual announcement then.. 1162062821 M * Hollow 14 months since 2.1.0_pre1 :) 1162062864 M * Bertl hmm, but 2.1.0 was released too! :) 1162062871 M * Hollow but not as stable ;) 1162062881 M * daniel_hozac well, 2.1.1 isn't stable either? 1162062886 M * Bertl 2.1.1 will not be released as stable either 1162062888 M * Hollow uhm? 1162062897 M * daniel_hozac 2.1 is the devel branch? 1162062899 M * Bertl but there will be a 2.2.0 soon 1162062907 M * Hollow i thought you said to release it as stable 1162062913 M * Bertl nah 1162062924 M * Bertl but 2.2.0 will be based on 2.1.1 1162062947 M * Hollow ok.. then the announcement will wait 1162062949 M * Bertl a few cleanups still remain, and I'm going to ruip out the quota stuff 1162062968 M * Bertl well, a 2.1.1 announcement (as devel) would be appreciated 1162062981 M * daniel_hozac why rip out the quota stuff? lack of testing? 1162062994 M * Hollow Bertl: including submission to all news sites? 1162062994 M * Bertl it's half way to the real thing 1162063011 M * Bertl Hollow: can't hurt, after all it's a major release of the devel branch 1162063019 M * Hollow ok, will do it then.. 1162063059 M * Hollow will 2.0.2.2 be released too in the nearer future? 1162063214 M * Bertl yes, probably a 2.0.3 even 1162063226 M * daniel_hozac changes from 2.0.2.2? 1162063247 M * Bertl many things fixed in 2.1.1 will get into it 1162063284 M * Bertl have to look through it though 1162063332 M * Bertl k, morrigan is waiting for dinner now .. so I'm back later (after cooking :) 1162063345 M * daniel_hozac ok, cya! 1162063346 N * Bertl Bertl_oO 1162064089 Q * Piet Ping timeout: 480 seconds 1162064124 J * Piet hiddenserv@tor.noreply.org 1162066840 A * doener still wonders if you can fsck up the system now that namespace boundaries are mostly gone... (vanilla) 1162067201 Q * debugger Ping timeout: 480 seconds 1162068154 N * Bertl_oO Bertl 1162068165 M * Bertl back now ... 1162068188 M * Bertl doener: tried the cd and friends on init (as you suggested) no go there 1162068214 M * doener with the faked init proc entries? 1162068219 M * Bertl doener: or are we talking about different things? 1162068230 M * Bertl yes, with 'fake' init 1162068263 M * doener and fake init != blend-through, right? 1162068300 M * Bertl yeah 1162068306 M * doener ok 1162068348 M * doener I'm looking for missing checks right now, that allow to break stuff on vanilla ;) 1162068369 M * doener looks safe so far 1162068546 Q * FireEgl Quit: Bye... 1162068550 J * debugger ~Rui@217.129.151.190 1162068735 J * matled ~matled@85.131.246.184 1162068933 M * Bertl wb matled! 1162068955 J * FireEgl FireEgl@Sebastian.Atlantica.US 1162069499 Q * Piet Ping timeout: 480 seconds 1162069651 Q * ms_ Ping timeout: 480 seconds 1162069879 M * phreak`` Bertl: hrm, didn't you say that _rc44 should fix it ? :) 1162069913 M * daniel_hozac he did. 1162069923 M * daniel_hozac does that mean it doesn't? :) 1162069933 M * phreak`` at least not here .. 1162069947 M * daniel_hozac what is it, just so we're clear? the pid_task? 1162069960 M * phreak`` Oct 28 23:00:29 epimetheus vxW: pid_task(3564,0): task f75a4550[#20,5750] did lookup c1d9f050[#15,3564] 1162069964 M * phreak`` Oct 28 23:00:29 epimetheus BUG: warning at kernel/pid.c:272/pid_task() 1162069974 M * phreak`` and the trace 1162069981 M * Bertl that's something else 1162070000 M * Bertl please upload it anyways 1162070016 M * phreak`` Bertl: I pasted you the links this morning :) hold on a sec 1162070028 M * Bertl but it looks like you experience cross context lookups? 1162070034 M * phreak`` yeah 1162070062 M * phreak`` Bertl: http://dev.gentoo.org/~phreak/projects/vserver-sources/bugs/2.6.18.1-vs2.1.1-rc43/2006-10-28.log 1162070077 M * Bertl any idea why task 5750 in context #20 is looking for 3564? 1162070085 M * phreak`` thats what it looks like also with 2.1.1_rc44 1162070096 N * debugger rgl 1162070187 M * phreak`` neither 5750 (in #20) nor 3564 (in #15) do exist ... 1162070224 M * Bertl well, I'd appreciate a test run with: 1162070247 M * Bertl rc44, framepointer and stack unwinding enabled 1162070270 M * Bertl for a kernel, where you have the sources (compiled with debug info) 1162070278 M * Bertl is that possible? 1162070288 M * phreak`` sure .. 1162070308 M * Bertl I mean, the fact that this happens (the warning) is harmless 1162070310 M * daniel_hozac do you know what's causing it yet? 1162070323 M * phreak`` also stack_unwind ? 1162070326 M * Bertl no idea in this particular case 1162070334 M * Bertl phreak``: yes, please 1162070355 M * Bertl daniel_hozac: 90% of those warnings went away with the proper proc checks 1162070370 M * Hollow FYI, i collected all info i found on chroot breakout + barrier information at http://linux-vserver.org/Secure_chroot_Barrier 1162070381 M * daniel_hozac Bertl: ok, that's good. 1162070424 M * phreak`` Bertl: compiling now 1162070425 M * Bertl for example, you can get a nice warning if you explicitely lookup a pid from another guest or from the host 1162070477 M * daniel_hozac right. 1162070490 M * daniel_hozac but i thought the stack trace was supposed to be gone from rc44. 1162070492 M * Bertl chcontext --xid 100 -- ls /proc/2 1162070508 M * Bertl yeah, was supposed to be gone, but I forgot that hunk :) 1162070534 M * Bertl nevertheless, it might be interesting now to see where it comes from 1162070555 M * Bertl phreak``: btw, when do you get that? 1162070599 M * phreak`` Bertl: looks like right at context startup 1162071045 M * phreak`` Bertl: guess I'll only see the full trace on the console ? 1162071249 J * Aiken ~james@tooax6-204.dialup.optusnet.com.au 1162071337 Q * dna_ Quit: Verlassend 1162071370 M * Bertl phreak``: dmesg 1162071377 M * Bertl morning Aiken! 1162071517 M * phreak`` Bertl: http://paste.linux-vserver.org/581 1162071678 M * Bertl tx 1162071761 M * Bertl it's funny, but I'd say something is explicitely looking up that pid 1162071811 M * Bertl do you have contexts #20 and #15 in use? 1162071817 M * phreak`` yeah both .. 1162071841 M * phreak`` #15 being a vps with cron, rsync and httpd2; #20 being my samba host 1162071972 M * Bertl okay, would you mind providing the ps auxwww from both guests? 1162072047 M * phreak`` Bertl: sure, http://paste.linux-vserver.org/583 1162072048 M * Aiken good morning Bertl 1162072063 M * Aiken still generating OOPS on demand :( 1162072110 M * Bertl ah, yes, we still haven't addressed the CoW issues 1162072119 M * Bertl daniel_hozac: any news on this front? 1162072155 M * daniel_hozac i couldn't reproduce it here. Aiken: do you have a solid test-case? 1162072187 M * daniel_hozac i.e. a sure-fire way to trigger it? 1162072206 M * Bertl let's try to utilize/extend the testfs.sh for that, what do you think? 1162072227 M * Bertl it should already do everything required 1162072245 M * Bertl probably just a new test case has to be added 1162072254 M * daniel_hozac indeed. 1162072274 M * Bertl btw, I added a VCI flag for the CoW 1162072284 M * Bertl so full CoW support can now be detected 1162072301 M * daniel_hozac ok, good. 1162072346 M * Aiken daniel_hozac mount a filesystem, create a file and it's COW. break the link and unmount the filesystem 1162072359 M * daniel_hozac filesystem type? 1162072360 M * Aiken have done it with both ext3 and 2 1162072374 M * daniel_hozac i did ext3 here, didn't get anything. 1162072375 M * Bertl Aiken: testfs.sh should already do that? 1162072412 M * Bertl the failing test case #116 breaks the link with CoW 1162072444 M * Bertl the filesystem is mounted before, and unmounted afterwards 1162072475 M * daniel_hozac there is no open(file, O_WRONLY) test though, is there? 1162072518 M * Bertl nope, we are also missing the chown test 1162072528 M * Bertl IIRC 1162072538 M * Aiken I just had testfs.sh work 1162072553 M * Aiken and got localhost kernel: Assertion failure in ext3_put_super() at fs/ext3/super.c:420: "list_empty(&sbi->s_orphan)" 1162072553 M * Aiken Segmentation fault 1162072556 M * Aiken when I did it manually 1162072572 M * Bertl hum funny thing ... 1162072583 M * daniel_hozac and this is a newly created filesystem? 1162072592 M * Bertl maybe you could write a short script based on the testfs.sh? 1162072620 M * Aiken new filesystem 1162072688 M * Aiken http://paste.linux-vserver.org/584 1162072702 M * Aiken back shortly, the system is bad enough I have to go upstairs to reboot it 1162072719 M * Bertl okay, tx 1162072738 M * Bertl phreak``: could you disable the samba service for a test (in #20)? 1162072747 M * Bertl phreak``: and check if it happens again? 1162072839 M * Aiken I am using my own cow test, I break the link in 3 ways 1162072855 M * Aiken modify the file, chmod and chown 1162072877 M * Aiken the filesystem benifits from a fsck.ext? each time 1162072879 M * Bertl okay, and this is a script? 1162072890 M * Aiken yes 1162072898 M * Bertl can we get that one? 1162072960 M * phreak`` Bertl: sure, hold on a second. 1162072995 M * Aiken Bertl nothing fancy http://paste.linux-vserver.org/585 1162073047 M * phreak`` Bertl: still happening 1162073071 M * Bertl okay, was just a guess 1162073085 M * Bertl what services are enabled for that second guest? 1162073087 M * daniel_hozac Aiken: are you running it in a guest or on the host? 1162073095 M * Aiken host 1162073115 M * Bertl phreak``: is there something getting started between samba and cron? 1162073115 M * phreak`` Bertl: just cron is left now and init of course, but that ain't a service :) 1162073137 M * Bertl phreak``: could there be something which would be started but fails? 1162073171 M * Aiken breaking the link by changing the contents of the file is not doing it 1162073190 M * daniel_hozac Aiken: just chmod/chown? 1162073223 M * Aiken breaking the link with chown just caused an OOPS 1162073240 M * Bertl let's test his test script ... which I assume trigegrs it, no? 1162073241 M * Aiken i'll try the chmod after the next reboot 1162073278 M * Aiken Bertl I did the modify to break the link and nothing happened 1162073288 M * Aiken it OPPSed when I broke the link with chmod 1162073311 M * Bertl hum 1162073359 M * daniel_hozac that should be triggered by testfs as well then. 1162073397 M * Bertl maybe certain 'delais' are required 1162073416 M * Bertl to get writebacks and such 1162073447 M * Bertl Aiken: also, just to make sure, would be great to update to rc44 and retest 1162073464 M * Bertl (not that I think the fixes we did there are related) 1162073579 M * Aiken I have triggered it with ext3 on aoe, ext2 on local disk and ext3 on /dev/loop0 pointing to a local file (same file as when I run testfs) 1162073614 M * phreak`` Bertl: hrm, can't find anything that could fail during startup, only things in between are baselayout and init of course 1162073655 M * Aiken chmod is fine 1162073686 M * Aiken out of the 3 it is breaking a link with chown that is causing the OOPS 1162073774 M * Aiken grep chown testfs.sh does not return anything 1162073782 M * Bertl that's correct 1162073818 M * Aiken the failing test in testfs.sh (116) only does chown 1162073827 M * Bertl phreak``: hmm, could you place logger events between the various runlevel scripts for that guest? 1162073831 M * Aiken so testfs does not test the case that is blowing up for me 1162073848 M * Bertl okay, so the chown does it, right? 1162073860 M * Aiken yes 1162073870 M * Bertl from what uid/tagging do you chown to what other? 1162073872 M * Aiken no OPPS with modify or chmod 1162073952 M * Aiken downloading rc44 1162073995 M * phreak`` Bertl: hrm, the guest won't see anything of that ooops; right ? or do you just mean to put something like date +'%F - %T'; ps auxwww > $TEMPFILE between them so you could get the process numbers ? 1162074019 M * Bertl yeah, something like that, i.e. to narrow it down 1162074026 M * Bertl maybe add a sleep 10 there too 1162074067 M * Bertl I somehow get the feeling some process is explicitely looking that up (for whatever reason) 1162074114 M * Bertl Aiken: tagxid or not? 1162074308 M * Bertl hmm, well, I think I can reproduce part of it 1162074383 M * Bertl daniel_hozac: http://paste.linux-vserver.org/586 1162074541 M * Aiken anything out of my config that mentions TAG http://paste.linux-vserver.org/587 1162074565 M * Aiken I have had that error with ext2 1162074584 M * Aiken the filesystem benifited from a fsck 1162074600 M * Aiken everytime this happens the filesystem benifits from a fsck 1162074620 M * Bertl yeah, not unexpected 1162074641 M * daniel_hozac so chmod is fine, but chown is not? 1162074660 M * Aiken chmod is fine, chown is bad 1162074747 M * daniel_hozac path_release(&nd) in sys_chown should free the new inode, right? 1162074783 M * Bertl will check the code shortly, currently trying a few test cases 1162074847 M * Bertl we might also hit a journal issue on ext3 1162074912 M * Bertl nah, ext2 shows the same 1162075010 M * Bertl what about the 'original' inode? 1162075069 M * daniel_hozac should be dropped by dput(old_dentry) in cow_break_link_vfsmount, no? 1162075239 M * Bertl shouldn't both inodes be marked dirty at the end? 1162075255 M * daniel_hozac hmm, why? do we touch the old inode at all? 1162075274 M * Bertl we should remove the link 1162075282 Q * rgl Read error: Connection reset by peer 1162075288 M * Bertl i.e. reduce the link count, no? 1162075293 M * daniel_hozac ah, yes... 1162075315 M * daniel_hozac but that should be done by cow_break_link, shouldn't it? 1162075322 M * Bertl checking now 1162075329 M * daniel_hozac actually, the new inode should probably be marked dirty there as well. 1162075345 M * daniel_hozac oh, you mean that part. 1162075353 M * daniel_hozac well, that's if we're changing the last link. 1162075371 M * daniel_hozac i.e. there are no other links and we just remove the flags. 1162075377 M * daniel_hozac so there is no other inode to mark as dirty. 1162075387 M * Bertl yeah, that's fine 1162075407 M * Bertl but I don't see where any inodes are marked dirty when the link break happens 1162075414 M * Bertl maybe I'm missing that though 1162075477 M * daniel_hozac well, the new inode should be marked dirty automatically as it's just been created, no? 1162075485 J * gpiero ~gpiero@adsl-ull-145-40.44-151.net24.it 1162075485 M * Bertl yes, that's fine 1162075496 M * Bertl what about the old one? 1162075502 M * Bertl welcome gpiero! 1162075520 M * daniel_hozac wouldn't the rename first unlink the previous file? 1162075530 M * daniel_hozac which should mark it as dirty. 1162075533 M * Bertl but maybe it's simply a reference counting issue, let's dump inode counts before and after the break 1162075789 Q * meandtheshell Quit: exit (0); 1162075876 M * Aiken Bertl finally manged to get everything downloaded, want to try rc44 or wait? 1162075893 M * Aiken should have been -> want me to rc44? 1162075896 M * Bertl let's try rc44, can't hurt 1162075929 M * Bertl # chown 666.666 /test/A/yy 1162075929 M * Bertl [ 37.829118] chown:1 7fdc2430[#5802,2;2] 1162075929 M * Bertl [ 37.864548] chown:2 7fdc2430[#5802,1;1] 1162075929 M * Bertl [ 37.865230] chown:3 79297d84[#5803,1;1] 1162075951 M * Bertl ptr[#ino,count;nlink] 1162076005 M * daniel_hozac looks fine to me? 1162076010 M * Bertl interesting part, when I do this 1162076017 M * Bertl # umount /test/ 1162076017 M * Bertl [ 122.483898] VFS: Busy inodes after unmount of hdc1. Self-destruct in 5 seconds. Have a nice day... 1162076021 M * Bertl [ 122.603399] chown:1 7fd4ea48[#687,1;1] 1162076021 M * Bertl [ 122.604009] chown:2 7fd4ea48[#687,1;1] 1162076021 M * Bertl [ 122.604447] chown:3 7fd4ea48[#687,1;1] 1162076082 M * Bertl why would an umount trigger the chown again? on a different inode? 1162076163 M * Bertl another question, why do we have two references to the inode at the beginning? 1162076181 Q * bonbons Quit: Leaving 1162076226 M * Bertl a normal chown just has one reference ... 1162076267 M * Bertl ah, no, two dentries, two references ... my fault 1162076298 M * Bertl but imho it must be an inode which wasn't written back 1162076380 J * ms_ ~ms@arkansas.doc.ic.ac.uk 1162076386 M * Bertl wb ms_! 1162076764 M * daniel_hozac does the busy inodes message mean inodes with a reference count greater than 1? can we get an inode number? 1162076788 M * Bertl yep, already on it :) 1162076802 M * daniel_hozac ok :) 1162077018 M * Bertl http://paste.linux-vserver.org/588 1162077044 M * daniel_hozac Hollow: re: Resource_Limits, ANON isn't enforced, is it? 1162077064 M * Bertl daniel_hozac: btw, I added mark_dirty for both inodes (just in case) 1162077078 M * daniel_hozac but no change? 1162077087 M * Bertl the dump is with the mark added 1162077124 M * daniel_hozac ok. 1162077132 M * daniel_hozac what's inode 2? maybe ll -i? 1162077168 M * daniel_hozac so for some reason the path_release isn't releasing the new inode. 1162077196 M * Bertl nlinks of 3 looks like the dir to me :) 1162077212 M * daniel_hozac ah, yes. 1162077228 M * Hollow daniel_hozac: right... 1162077253 M * Hollow fixed.. 1162077257 M * daniel_hozac Hollow: and Determinig page size ;) 1162077264 M * daniel_hozac (note the lack of n) 1162077271 M * Bertl http://paste.linux-vserver.org/589 1162077277 M * Bertl that is without the setattr 1162077291 M * daniel_hozac is the DENTRY limit enforced as well? 1162077310 M * Hollow seems so... 1162077314 M * Hollow http://paste.linux-vserver.org/578 1162077330 M * daniel_hozac ok, cool. 1162077353 M * Bertl we did that a day after the 'ovz' exploit, remember? :) 1162077360 M * daniel_hozac ah, right! 1162077362 M * daniel_hozac hehe. 1162077397 M * daniel_hozac so it's definitely a problem with the cow code. 1162077399 M * Hollow the thing with ANON (and NSOCK too as i just saw) is... the kernel defines the vx_*_avail but does not use it.. 1162077406 M * daniel_hozac yep. 1162077413 M * Hollow same for openf 1162077414 M * Hollow d 1162077424 M * daniel_hozac Bertl: what are the dentries' reference counts? 1162077445 M * daniel_hozac are we missing a dput(new_dentry) somewhere? 1162077473 M * daniel_hozac would explain why the directory is still busy too. 1162077496 M * Bertl will check that shortly 1162077519 M * daniel_hozac seems strange for it to only be on chown though. 1162077526 M * Bertl but a stupid question here, why the heck is cow_break_link_vfsmount() called on non CoW inodes at all? 1162077528 M * Hollow apropos DENTRY... in which case could the current value shown in /proc/virtual/*/limit be negative? 1162077555 M * daniel_hozac Bertl: cow_break_link_vfsmount is what checks whether or not to break it. 1162077563 M * Bertl Hollow: an accounting bug, which might actually happen there 1162077572 M * Bertl s/bug/incorrectness 1162077578 M * Hollow ;) 1162077585 M * daniel_hozac Bertl: OH! i see it now. 1162077596 M * daniel_hozac sys_chown's nd.dentry isn't updated. 1162077612 M * daniel_hozac thus the path_release(&nd) doesn't free the new dentry, but the old dentry- 1162077627 M * Bertl so chown common gets a ** 1162077652 M * daniel_hozac yeah. 1162077677 M * Bertl I'm still not happy with those 1162077694 M * daniel_hozac i agree, i think it's rather ugly. 1162077701 M * daniel_hozac but i'm not sure how else to do it. 1162077706 M * Bertl couldn't we test and break the links before 1162077725 M * daniel_hozac "before"? in sys_chown you mean? 1162077742 M * Bertl yep, and let chown do it's thing on the proper dentry/inode 1162077769 M * daniel_hozac that would mean duplicating it to sys_lchown and sys_fchownat. 1162077800 M * Bertl shouldn't be a problem if it is some call/inline 1162077820 M * daniel_hozac true... but then we might be trying to break the link on a -EROFS. 1162077871 M * Bertl what if we do the following: 1162077892 M * Bertl have a CoW_break_nd_something() 1162077918 M * Bertl call that (with error checks) early in all sys_*chown() 1162077924 M * daniel_hozac isn't that what we have already? ;) 1162077945 M * Bertl nah,, let me give an example 1162077986 M * daniel_hozac _vfsmount isn't using an nd simply because chown_common (e.g.) didn't have an nd, just a dentry and a mnt separate. 1162078044 M * Bertl http://paste.linux-vserver.org/590 1162078073 M * Bertl now we could move the ro checks completely to cow_break_nd() 1162078086 M * Bertl and simply return success on non-ro, non-cow 1162078102 M * daniel_hozac yeah, sure. 1162078123 M * Bertl at the same time we can reliably modify the dentry in the namidata 1162078133 M * Bertl *nameidata 1162078174 M * daniel_hozac well, &nd.dentry, nd.mnt is just as reliable, no? ;) but sure, passing the struct is cleaner. 1162078190 M * daniel_hozac and if we move the check from chown_common, using the struct makes sense. 1162078199 M * daniel_hozac (as chown_common was the only one with them separate) 1162078217 M * Bertl I think we could even pass a pointer to an array of pointer here *G* but that wwould hurt my eyes too much :) 1162078228 M * daniel_hozac hehehe. 1162078249 M * Bertl okay, do you want to prepare/test a patch? 1162078266 M * Hollow off to bed now folks... have a good one! 1162078268 M * daniel_hozac sure. 1162078272 M * daniel_hozac good night Hollow! 1162078277 M * Bertl Hollow: u2! 1162078339 M * daniel_hozac Bertl: is the case of dentry->d_inode == NULL worth checking against? (like chown_common does) 1162078346 M * Bertl daniel_hozac: maybe call it cow_check_and_break() 1162078364 M * daniel_hozac yeah, the current name always felt bad. 1162078377 M * Bertl yeah, IIRC that happens in special cases, don't remember when actually 1162078393 M * daniel_hozac so we should check for that too. 1162078421 M * Bertl we could make it a warn_on() and check, and see if something pops up 1162078436 M * Bertl if nothing is seen, we can remove that check 1162078450 M * Bertl (at which point it becomes an implicit BUG_ON() :) 1162078493 M * daniel_hozac well, the chown_common one should've already shown itself, no? 1162078521 M * Bertl yeah, right 1162078540 M * daniel_hozac hmm, should we remove the checks from chown_common? 1162078557 M * Bertl well, they are pointless if we do the cow check before 1162078559 M * daniel_hozac i'm inclined to say no, as fchown won't use the new check_and_break. 1162078576 M * Bertl hum, right 1162078589 M * Bertl we decided not to handle that one for now ... 1162078619 M * Bertl leave it there, makes the patch smaller and shouldn't hurt 1162079039 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-cow-fix06.diff 1162079079 M * daniel_hozac (compile-tested only, rebooting now) 1162079299 J * Osgiliath ~osgiliath@kurzweil.no-ip.org 1162079303 M * daniel_hozac i don't get the busy inodes message, but it's possible i didn't reproduce it correctly. 1162079314 M * Osgiliath hi :) 1162079328 M * Aiken compiling to now 1162079471 M * derjohn2 goog evening folks! If I complile a new kernel, is it enough to take rc44 ? 1162079505 M * derjohn2 or should I use delta-cow , too? 1162079548 M * daniel_hozac if you intend to break links using chown, you'll probably want the delta-cow-fix06 ;) 1162079652 M * Bertl hey Osgiliath! 1162079654 M * Aiken no OOPS :) 1162079658 M * daniel_hozac Aiken: great!§ 1162079672 M * Bertl §? 1162079682 M * Osgiliath : ) 1162079697 M * daniel_hozac key next to ! ;) 1162079697 M * Aiken something else I have noticed is when using cow and I deleted the cowed image I need to run fsck to recover the space 1162079723 M * Bertl Aiken: check if that still holds 1162079800 M * Bertl Osgiliath: so how's the oracle doing? 1162079818 M * Osgiliath good ! 1162079843 M * Bertl so we can add oracle 10g to the 'working programs' :) 1162079860 M * Osgiliath i think so 1162079949 M * daniel_hozac Aiken: how do you reproduce that? what do you lose space to? 1162079976 M * daniel_hozac IMHO a COWed guest should be very minimal, just some files in /var and /etc that should really be taking up space. 1162079989 M * daniel_hozac or do you mean after some sort of chown -R guest operation?