1319846520 M * daniel_hozac also, there is now a /etc/vservers/.distributions/mageia directory with the required configuration for it.
1319847582 Q * bonbons Quit: Leaving
1319847794 Q * clopez Ping timeout: 480 seconds
1319848508 Q * ghislain Quit: Leaving.
1319851472 Q * cehteh Ping timeout: 480 seconds
1319851532 J * cehteh ~ct@pipapo.org
1319853982 J * derjohn_foo ~aj@p4FFD0EB4.dip.t-dialin.net
1319854364 Q * derjohn_mob Ping timeout: 480 seconds
1319854867 J * cehteh` ~ct@pipapo.org
1319854908 Q * cehteh Ping timeout: 480 seconds
1319855894 Q * cehteh` Ping timeout: 480 seconds
1319858657 J * cehteh ~ct@pipapo.org
1319858740 Q * cehteh 
1319859020 J * cehteh ~ct@pipapo.org
1319866453 Q * quasisane Remote host closed the connection
1319866629 J * quasisane ~sanep@c-76-24-80-97.hsd1.nh.comcast.net
1319866710 Q * Aiken Remote host closed the connection
1319866875 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1319867032 Q * hparker Quit: Quit
1319867380 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1319871414 N * Bertl_zZ Bertl
1319871418 M * Bertl morning folks!
1319871462 M * Bertl daniel_hozac: wow! thanks, will do some testing asap
1319873077 M * Bertl off for now ... bbl
1319873081 N * Bertl Bertl_oO
1319875183 J * ghislain ~AQUEOS@adsl2.aqueos.com
1319875367 J * sannes1 ~ace@cm-84.209.106.118.getinternet.no
1319877005 J * bonbons ~bonbons@2001:960:7ab:0:99a6:ff86:3a49:1053
1319877772 Q * fback Ping timeout: 480 seconds
1319879915 J * petzsch ~markus@p57B66DC4.dip.t-dialin.net
1319880537 J * fback fback@red.fback.net
1319884940 Q * petzsch Quit: Leaving.
1319887978 Q * fisted Ping timeout: 480 seconds
1319888109 J * fisted ~fisted@xdsl-87-78-208-236.netcologne.de
1319888409 J * petzsch ~markus@p57B66DC4.dip.t-dialin.net
1319888704 Q * eyck Remote host closed the connection
1319888732 Q * Aiken Remote host closed the connection
1319889373 M * arekm daniel_hozac: hi, any progress on cow (for 3.1 kernel)?
1319890411 Q * petzsch Quit: Leaving.
1319892352 M * daniel_hozac arekm: not yet. hoping to get to it today.
1319892765 M * _Shiva_ export DISTCC_VERBOSE=0
1319892765 M * _Shiva_ export DISTCC_VERBOSE=0
1319892787 M * _Shiva_ sorry - missed the right window on paste ..
1319892834 M * m_ueberall echo DOH\! ;)
1319896026 Q * sannes1 Remote host closed the connection
1319896057 J * sannes1 ~ace@cm-84.209.106.118.getinternet.no
1319900615 Q * bergerx Quit: Leaving
1319903632 M * Guy- what's a good way of sharing the entire rootfs among several vservers, with one mounting it r/w and the others r/o?
1319903709 M * Guy- I can make the vdir symlink point to the same directory for all, but then all of them get r/w access; does it work as expected if I explicitly mount the rootfs as r/o from /etc/vservers/guest/fstab?
1319906963 J * bergerx ~bergerx@46.196.250.204
1319910351 M * daniel_hozac Bertl_oO: let me know when you have a few seconds for the CoW.
1319910763 Q * Rockj Quit: WeeChat 0.3.6
1319911852 M * sannes1 Guy- : Bind mount it r/o
1319912779 J * petzsch ~markus@p57B66DC4.dip.t-dialin.net
1319912832 M * Guy- sannes1: doesn't work
1319912859 M * Guy- more precisely, it's r/o when the mtab would be updated
1319912869 M * Guy- but it becomes r/w again sometime later in the boot process
1319914243 M * daniel_hozac hmm, what util-vserver version?
1319914248 M * daniel_hozac i thought that was fixed.
1319914375 M * Guy- 0.30.216-pre2982
1319914617 M * Guy- I'll upgrade and retry
1319914639 M * daniel_hozac hmm, doesn't look like it.
1319915103 Q * petzsch Quit: Leaving.
1319917010 J * petzsch ~markus@p57B66DC4.dip.t-dialin.net
1319917324 Q * petzsch Quit: Leaving.
1319917768 Q * hparker Ping timeout: 480 seconds
1319918691 J * hparker ~hparker@linux.homershut.net
1319919568 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1319919659 J * petzsch ~markus@p57B66DC4.dip.t-dialin.net
1319919930 J * petzsch1 ~markus@p57B65FE9.dip.t-dialin.net
1319920323 Q * petzsch Ping timeout: 480 seconds
1319921401 Q * cuba33ci Read error: Connection reset by peer
1319921403 N * nicholi Guest15169
1319921410 J * nicholi ~nicholi@rrcs-76-79-196-34.west.biz.rr.com
1319921442 J * cuba33ci ~cuba33ci@111-240-174-73.dynamic.hinet.net
1319921513 Q * Guest15169 Ping timeout: 480 seconds
1319922443 M * Guy- hmm, nfs weirdness
1319922454 M * Guy- I export a filesystem with no_squash_root on the host, to itself
1319922470 M * Guy- if I mount a subdir of that on the host, it works as expected
1319922488 M * Guy- if I mount it via fstab.remote in a guest, it acts as if squash_root were in effect
1319922592 M * Guy- *no_root_squash, whatever
1319923013 M * daniel_hozac do you have NFS tagging enabled?
1319923202 M * Guy- no
1319923223 M * Guy- (at least, I did nothing to enable it, so it's at its default)
1319923349 M * daniel_hozac zgrep TAG_NFSD /proc/config.gz
1319923457 M * Guy- # CONFIG_TAG_NFSD is not set
1319923470 M * Guy- I also don't use XID tagging on regular filesystems
1319923694 Q * petzsch1 Quit: Leaving.
1319923736 M * Guy- the kernel is 3.0.4-vs2.3.1-pre10.1, fwiw
1319924320 J * petzsch ~markus@p57B65FE9.dip.t-dialin.net
1319924475 Q * sannes1 Remote host closed the connection
1319926852 M * ccxCZ currently the only supported access control system is SELinux, right?
1319926910 M * daniel_hozac define supported.
1319927230 M * ccxCZ so what are my options? I have to host several PHP applications and I don't really trust the quality of code, so I want to lock it down as much as possible.
1319927283 J * petzsch1 ~markus@p57B65FE9.dip.t-dialin.net
1319927593 Q * petzsch Ping timeout: 480 seconds
1319927656 N * Bertl_oO Bertl
1319927660 M * Bertl back now ...
1319927676 M * Bertl daniel_hozac: I have now ... :)
1319927738 M * Bertl Guy-: what NFS version?
1319927780 M * Bertl ccxCZ: what kind of 'lock down' do you have in mind?
1319927901 M * daniel_hozac Bertl: well, it seems to be several issues. because of the do_last changes, where we expect a -EMLINK as a "try it again", we get the infinite loop when cow_break_link returns -EMLINK as an error code.
1319927940 M * daniel_hozac the reason we get the EEXIST from vfs_create is because the dentry in new_path is actually the directory.
1319928016 M * daniel_hozac after fixing those, we still seem to have a ref count bug...
1319928061 M * Bertl hmm, I was kind of expecting that, I presume we hold count on the dir dentry
1319928078 J * petzsch ~markus@p57B65FE9.dip.t-dialin.net
1319928088 M * Bertl but I'm confused that the create returns the directory?
1319928107 M * daniel_hozac the create returns the new dentry
1319928114 M * daniel_hozac but new_path will contain the directory.
1319928116 M * Bertl do you have a patch to get to the point where we have the refcount issue?
1319928120 M * daniel_hozac sure
1319928214 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-cow-tmp26.diff
1319928218 M * Bertl tx
1319928220 M * daniel_hozac also has quite a few debug printks.
1319928274 M * daniel_hozac the second to last hunk is the important part.
1319928308 Q * petzsch1 Ping timeout: 480 seconds
1319928396 M * Bertl okay, except for the excessivly long lines the debug printks already use vxdprintk, so I don't see a reason why we shouldn't keep them around (at least for now)
1319928429 M * daniel_hozac most of them will probably never be useful again :-)
1319928463 M * Bertl the interesting part is that the patch doesn't apply to my tree, I wonder why ...
1319928503 M * daniel_hozac hmm, that's odd...
1319928514 M * Bertl nevermind, my fault
1319928571 M * daniel_hozac the ret = -ELOOP should be something else. or we use something else to indicate that we should attempt to reopen the file...
1319928572 M * Bertl was in the wrong directory :)
1319928575 M * daniel_hozac hehe
1319928755 M * Bertl why doesn't EMLINK work there?
1319928804 M * daniel_hozac right now, EMLINK from the layer above that (do_last) tells path_openat that it should retry.
1319928827 M * daniel_hozac so if cow_break_link returns it as an error code, path_openat is just going to try again.
1319928853 M * daniel_hozac we should probably just use a different one in do_last/path_openat.
1319928866 M * Bertl hmm, let me check the changes first
1319929192 M * Bertl okay ,so kern_path_create returns the directory in new_path?
1319929207 M * Bertl or just in den dentry in 'res'?
1319929236 M * Bertl (or did I misunderstand the comment about the dir?)
1319929245 M * daniel_hozac the directory is in new_path.dentry
1319929251 M * daniel_hozac res is the new entry
1319929270 M * Bertl so res is the 'to' file/entry
1319929280 M * Bertl but new_path is the directory
1319929296 M * daniel_hozac right
1319929308 M * Bertl that's a little strange, but okay
1319929312 M * daniel_hozac i agree.
1319929322 M * Bertl so we basically can put the new_path immediately
1319929341 M * Bertl all we need to keep is the dentry returned (res)
1319929361 M * daniel_hozac yeah.
1319929398 M * daniel_hozac although we should likely keep the mnt around, for good measure...
1319929418 M * Bertl shouldn't we have that in dir_nd?
1319929433 M * Bertl (from the do_path_lookup)
1319929462 M * daniel_hozac yeah, we already have references to it, but without it we can't do things like path_put(&new_path);
1319929477 M * Bertl which, btw, should be freed when we fail on the kern_path_create
1319929522 M * daniel_hozac yep
1319929587 M * Bertl so, my first suggestion is to change the new_path in dir_path and immediately path_put that after kern_path_create
1319929694 Q * petzsch Read error: Connection reset by peer
1319929695 M * Bertl we have the same dir/mnt in dir_nd anyways, as far as I can tell
1319929699 M * daniel_hozac yeah
1319929827 M * Bertl what I don't understand is, why do we have/need vfs_create after kern_path_create()?
1319929861 M * daniel_hozac vfs_create creates the inode.
1319929879 M * daniel_hozac kern_path_create just creates the dentry.
1319929921 M * Bertl okay, but a dentry means there is something there, unless it is a negative dentry
1319929949 M * Bertl which in turn means, that the dentry we get from that must be a negative one, yes?
1319929959 M * daniel_hozac well, there are hashed dentries before there is something connected to it.
1319930037 M * daniel_hozac i suppose it is negative.
1319930068 M * Bertl okay, why don't we ever put dir_nd?
1319930093 M * Bertl is that an old bug? or a new one? or not a bug at all?
1319930149 M * daniel_hozac i don't know. it has to be a bug for sure...
1319930185 M * daniel_hozac why it hasn't shown up before i can't really explain.
1319930193 M * Bertl okay, so, to properly get rid of dir_nd, all we need to do is to put the path in it, yes?
1319930208 M * daniel_hozac yep
1319930339 M * Bertl okay, the dentry we get in 'res' do we need to retain that?
1319930351 M * daniel_hozac yes, that is the new_path.dentry we will be operating on.
1319930374 M * daniel_hozac do you understand the redo stuff at all?
1319930376 M * Bertl yeah, but let me rephrase the question, do we need a dget on that?
1319930403 M * Bertl currently we dget(res) after the kern_path_create
1319930419 M * Bertl I'm not sure we actually need that ...
1319930430 M * daniel_hozac probably not.
1319930509 M * Bertl now, on the vfs_create() returns with EEXIST
1319930546 M * Bertl we currently mutex_unlock the dir mutex, I presume that is correct because vfs_create locks it?
1319930555 M * daniel_hozac kern_path_create locks it
1319930589 M * daniel_hozac the EEXIST is because the dentry we give it in 2.3.1-rc1 is the directory, which obviously does exist.
1319930782 M * Bertl okay, why do we have the out_redo: code?
1319930795 M * Bertl (sorry for jumping back and forth)
1319930795 M * daniel_hozac i have no idea.
1319930803 M * daniel_hozac the redo stuff makes no sense to me.
1319930877 M * daniel_hozac it should only run in the rare error case that the original file has been removed since we first looked it up.
1319930880 M * Bertl okay, let me upload the code as far as I got right now:
1319930917 M * daniel_hozac i guess the idea is that we are racing with another cow_break_link?
1319930945 M * ccxCZ Bertl: essentially probably just limiting filesystem access to certain directories and limiting network activity, that can be done with iptables though
1319930976 M * Bertl daniel_hozac: http://paste.linux-vserver.org/20657
1319931035 M * Bertl ignoring the last goto out_unlock_new; we should be in a consistant state and if successful, have the dentry with inode in res, yes?
1319931039 M * daniel_hozac did that get cut off, or was it intentionally short?
1319931049 M * Bertl yes, I stopped there
1319931068 M * Bertl i.e. that's how far I got till I got confused by the redo stuff :)
1319931069 M * daniel_hozac okay.
1319931071 M * daniel_hozac hehe.
1319931077 M * daniel_hozac yes.
1319931098 M * daniel_hozac line 58 and 78 are missing a &
1319931139 M * Bertl ah, right, tx
1319931170 M * Bertl do we agree that this doesn't hold any references in the retry case and only has references to old_path and res in the case of success?
1319931217 M * daniel_hozac and dir_nd.
1319931228 M * Bertl ccxCZ: so you should be fine with SElinux or even with 'normal' unix permissions
1319931250 M * Bertl daniel_hozac: yep, correct
1319931301 M * Bertl so, the out_unlock_new has to do:
1319931310 M * Bertl mutex_unlock(&dir->d_inode->i_mutex);
1319931317 M * Bertl path_put(&dir_nd.path);
1319931334 M * Bertl path_put(&old_path);
1319931341 M * Bertl dput(res);
1319931358 M * daniel_hozac yes
1319931499 M * Bertl as we recreate the dir_nd on every retry
1319931542 M * Bertl we could basically use that for the new dentry (res)
1319931587 M * Bertl i.e. dput(dir) after vfs_create() and put the res there
1319931598 M * daniel_hozac hmm, i suppose.
1319931611 M * daniel_hozac we don't really need it though, do we?
1319931639 M * Bertl we probably want the new_path later
1319931646 M * daniel_hozac and we need the dir for vfs_rename
1319931650 M * daniel_hozac we don't actually.
1319931655 M * Bertl ah, good
1319931658 M * daniel_hozac we just use new_path.dentry everywhere
1319931668 M * daniel_hozac one place uses new_path, but that's just a path_get.
1319931680 M * Bertl excellent, then let's rename the 'res' to new_dentry, shall we?
1319931683 M * daniel_hozac yeah
1319931742 M * Bertl okay, done
1319931768 M * Bertl so out_rel_both: changes to
1319931780 M * Bertl dput(new_dentry);
1319931796 M * daniel_hozac yeah
1319931810 M * Bertl and we still have the dir there
1319931826 M * Bertl i.e. the dir_nd.path
1319931830 M * daniel_hozac right
1319931840 M * Bertl so we want to put that as well
1319931887 M * daniel_hozac indeed.
1319931949 M * Bertl now I'm a little confused by the /error path cleanup/ path
1319931974 M * Bertl we do the unlink there, because the inode was created already
1319931979 M * daniel_hozac right
1319932022 M * daniel_hozac the path_put looks bogus though.
1319932025 M * Bertl but we do not need to put the path/dentry there
1319932046 M * Bertl yep, unless we didn't get a dentry in the first place, which should have been covered already
1319932101 M * Bertl now the out_redo: gets even weirder, we do a path_put(old_path) there
1319932104 M * daniel_hozac in which case doing unlink on it seems strange :)
1319932115 M * Bertl which schould be handled in the out_rel_old
1319932140 M * daniel_hozac yes
1319932148 M * daniel_hozac nothing seems to put old_nd.path either.
1319932172 M * Bertl instead it looks like we wanted to put the old_nd there
1319932188 M * Bertl (because we re lookup it)
1319932188 M * daniel_hozac well, the two are the same at that point.
1319932198 M * daniel_hozac so i think we can leave that alone
1319932210 M * daniel_hozac we need to do a path_put(&old_nd.path); after the dget though
1319932228 M * Bertl well, for readability IMHO it makes more sense to use path_put(&old_nd.path)
1319932245 M * daniel_hozac i don't think we should be doing that at all though
1319932253 M * daniel_hozac since out_rel_old does that
1319932272 M * Bertl yeah, but the do_path_lookup replaces the old_nd.path, no?
1319932278 M * daniel_hozac yes, but not old_path :)
1319932292 M * Bertl correct, I'm not talking about old_path
1319932301 M * daniel_hozac old_path is just a copy of old_nd.path.
1319932308 M * daniel_hozac without extra references.
1319932338 M * Bertl okay, let me rephrase that, IMHO it should read:
1319932350 M * Bertl path_put(&old_nd.path);
1319932364 M * Bertl ret = do_path_lookup(AT_FDCWD, pathname, LOOKUP_FOLLOW, &old_nd);
1319932369 M * daniel_hozac that would mean we free it twice while only acquiring one reference.
1319932381 M * daniel_hozac since both out_redo would free it as well as out_rel_old
1319932424 M * Bertl should do_path_lookup get a reference?
1319932429 M * daniel_hozac yes.
1319932449 M * Bertl so we free the old, get a new one (which we need to free in out_rel_old later)
1319932467 M * Bertl just old_path is wrong at that point
1319932472 M * daniel_hozac right
1319932487 Q * ghislain Quit: Leaving.
1319932488 M * Bertl so the tricky part is the error case again
1319932496 M * daniel_hozac so we could skip messing with old_path, skip path_put before the new do_path_lookup, and then do path_put(&old_nd.path); after the dget
1319932552 M * Bertl okay, sounds like an option, but we should add a note for that
1319932581 M * Bertl basically something like old_nd.path is freed as old_path in out_rel_old
1319932590 M * daniel_hozac definitely
1319932637 M * Bertl okay, done
1319932657 M * Bertl now in out_redo, we do change the new_dentry, but we do not put the old one, yes?
1319932675 M * daniel_hozac yep.
1319932686 M * Bertl that's a bug, no?
1319932688 M * daniel_hozac indeed
1319932699 M * daniel_hozac i don't think this redo thing has ever triggered...
1319932749 M * Bertl and if it has, it could explain many many issues :)
1319932764 M * daniel_hozac hehe