[01:17:02] --- stevenjenkins has left [01:20:02] --- stevenjenkins has become available [02:49:12] --- Rrrrred has left [02:49:40] --- dwbotsch has become available [03:10:07] --- shadow@gmail.com/owl6E01F1CD has left [04:24:39] --- shadow@gmail.com/owl34C82CC9 has become available [05:30:52] --- Jeffrey Altman has left: Replaced by new connection [06:06:01] --- dev-zero@jabber.org has become available [06:06:02] --- dev-zero@jabber.org has left: offline [07:02:38] --- deason has become available [07:07:01] --- mmeffie has become available [07:08:49] The School of Informatics at the University of Edinburgh will be hosting an AFS hackathon from 22-24 September this year. Announcement just sent to the usual places, please spread the word! [07:27:47] --- Jeffrey Altman has become available [08:31:23] Is it just me, or does AFS_GCPAGs, on a machine with key ring support, guarantee that all of your PAGs get stomped on the first time that it is run? [08:32:52] Ah no, missed a bit. That's not my problem, then. [08:34:36] --- dlc has left [08:54:08] --- kula has left [08:55:52] --- cclausen has become available [08:57:26] Hmmm. Whilst, again, it's not the cause of my problem, the fact that afs_pag_destroy holds the GLOCK is rather antisocial, given that it may well end up causing a sleep whilst the caller is holding spinlocks. [08:58:08] --- Jeffrey Altman has left [09:00:30] --- rra has become available [09:03:08] --- deason has left [09:03:23] --- deason has become available [09:10:59] --- Jeffrey Altman has become available [10:20:28] --- kula has become available [11:02:49] --- mdionne has become available [11:30:07] Speaking of GCPAGs, looks like we have more people with problems with kernel configs where rcu_read_* is GPL [11:31:58] CONFIG_PREEMPT_RCU makes rcu_read_(un)lock GPL only. Also, with the credentials change with 2.6.29, some credential operations (ex: task_uid()) now use rcu_read_* [11:32:30] Gah. [11:32:39] I take it those functions are inline? [11:33:12] inline or macros, yes [11:35:12] Can you have a look at http://pastebin.ca/1472972 - an attempt to work around all this [11:36:47] I take it we already have a test for EXPORTED_RCU_READ_LOCK somewhere? [11:37:46] It's defined by a configure test. We use it in some places, but not everywhere where rcu_read_lock is used, or where task_uid is used [11:37:51] I'm not a great fan of that change to proc2cred - it means it never sets its return value. [11:40:25] I suspect, actually, in that situation you should just remove the function entirely. It's only used by the GCPAGs code, which doesn't run if keyrings are enabled, (and can't run if we can't get a rcu lock, because then we can't lock the tasklist) [11:40:39] With the new credentials stuff, looks like you can't safely get another task's credentials without using RCU [11:41:00] I think we should just give up and force everyone to use keyrings if they want PAGs. [11:41:11] The current ifdef maze isn't maintainable in the long term. [11:41:24] Sure, but I'm not sure everyone enables keyrings [11:41:42] I think that means that they only get to have per-UID credentials in that case. [11:42:06] Although, given that we don't support setpag() changing the parent's PAG, do we need to get another task's credentials? [11:43:03] Outside of GCPAG I don't think we need to, no [11:43:37] GCPAG is dangerous, anyway. It doesn't lock properly on some kernel versions. [11:44:54] I'd be happy with that patch, if the proc2cred bit got changed. I do think we should have a serious look at rationalising this whole bit of code. [11:46:26] So I should make it return some value, or remove the function completely? Given that many people are having this issue (Gentoo, Debian) I think ideally we'd include a fix in 1.4.11 [11:47:17] We know CONFIG_PREEMPT_RCU introduces problems. Don't do that. [11:48:33] mdionne: Remove it completely, and fix the call site. [11:48:41] > I think we should just give up and force everyone to use keyrings if > they want PAGs. I think we agreed that on kernels which were new enough to use keyrings for PAG's, that was reasonable. But I also think we need to keep working on kernels which are not that new. [11:49:19] Yeh. My problem is with continuing to try and support new kernels that don't have keyrings enabled. That's what's causing some of the pain. [11:49:52] if we could blow the non-keyring case out the airlock this would be much simpler. [11:50:17] yeah. agree. [11:50:42] at some point new kernels become a lost cause due to gplonly [11:52:41] Hmm, the only call site for proc2cred is afs_GCPAGs_perproc_func, and that never gets called anyway if keyrings are enabled [11:53:25] yes, I believe that was mentioned [12:12:50] The contents of http://lists.infradead.org/pipermail/linux-afs/2009-June/ make for depressing reading, in terms of kAFS's ability to get us out of this mess ... [12:13:33] Ok here's a slightly different version - http://pastebin.ca/1473016 [12:16:20] They're right, pioctl is a bad design. [12:16:24] Not that that helps us very much. [12:16:56] mdionne: I suspect that will fail to build in cases where !defined(EXPORTED_RCU_READ_LOCK) && !defined(LINUX_KEYRING_SUPPORT) [12:17:26] Just change the #ifdef inside afs_osi_TraverseProcTable() in afs_osi_gcpags.c [12:17:37] ... to include the EXPORTED_RCU_READ_LOCK. [12:17:45] pioctl is the same bad design as ioctl. i understand the objection, i'm just not very sympathetic to it [12:18:07] Oh, and check what happens with pre-rcu kernels. jhutz will grumble if we break them ... [12:18:35] Linus's argument is that he's stuck with ioctl but he isn't stuck with pioctl and accepting the same mistake again would be dumb. [12:18:41] From his perspective, he's got a good point. [12:18:50] Just because we're already using it doesn't mean he thinks of it as an existing interface. [12:18:53] that's true. [12:19:34] basically it depends whether you view it as something new or more of the same [12:19:44] my view is apparently the minority [12:20:20] * rra finds the typeless arguments to pioctl kind of terrifying, so I'm sympathetic. I don't know what the better solution is, though. [12:20:23] --- deason has left [12:20:38] --- deason has become available [12:32:19] --- cclausen has left [12:40:36] my take on it is that the use of pioctls for both path and non-path operations hurts us. [12:40:40] --- dev-zero@jabber.org has become available [12:41:45] in particular, it prevents (or at least makes really hard) the use of both the openafs and kafs kernel modules at the same time [12:41:52] --- dev-zero@jabber.org has left: offline [12:43:20] I assumed that a new interface would have to be developed in order for it to be accepted by the Linux kernel developers and that we would have to adjust to whatever is agreed upon. [12:43:55] xattrs are mentioned in that thread; what's the feasibility of using those instead? [12:45:02] you could use them for path based operations. I do not see how you would use them for pathless operations. [12:45:55] it would essentially require the kernel module to produce the xattr values on the fly when xattrs are queried and filter out the values when actual xattrs are being stored into the file system. [12:45:58] it would be ugly [12:46:24] "pass in the mount point" is what I would think, but that may be hard to do [12:46:56] There's been more discussion in this thread: http://lkml.org/lkml/2009/6/18/47 [12:54:42] --- asedeno has left [12:55:13] --- kaduk@mit.edu/owl has left [12:55:59] --- broder@mit.edu/dr-wily has left [12:56:09] Ok here's one more version - http://pastebin.ca/1473108 - should address both the (!rcu and !keyring) case and the older kernel case (don't have one to test though). [13:03:26] I take it find_task_by_vpid is no longer available to us? [13:05:07] Although, I'd be tempted to say we should just disable keyring support entirely when we can't get key_type_keyring. That code is a horrible hack. [13:06:10] I'd like to have a conversation at some point about 1.6, and to what extent we can tidy up some of the more unmaintainable bits of cache manager code, without having to support every possible variant out there. [13:09:51] find_task_by_vpid: yes, just noticed that one today [13:12:41] we need to use pid_task() and make up a struct pid for it. and add yet another configure test and #ifdefs... :) [13:19:03] Do we? [13:19:39] Or can we guarantee that key_type_keyring is available in all kernel versions that break find_task_by_vpid? [13:22:13] --- cclausen has become available [13:23:26] --- asedeno has become available [13:24:10] --- kaduk@mit.edu/owl has become available [13:24:57] xattr on the mount point: lord forbid you want to configure pre-mount. and that's mentioned in the thread. [13:27:34] you could still configure pre-mount via module parameters, but... yeah [13:30:20] Simon: well that's certainly the case for current kernels. Actually there's probably not many kernel versions where key_type_keyring is available but not exported. [13:37:18] One possibility would be to do a configure-time check to see if key_type_keyring is exported, and use #ifdefs instead of the runtime test. [13:41:30] That would be much nicer, I think. [13:42:06] In 1.6, I suspect we could just say we won't do keyring support without key_type_keyring, and get rid of all of that code. [13:42:53] Although, I seem to recall a big debate a while back about how it was impossible to test for export status in a configure test, and that's why we ended up using weak attributes for this. [13:43:25] it's been exported since 2.6.22. We have many configure tests now that check for exported symbols [13:43:59] Actually, the arguments to pioctl are more typeful than to ioctl. But again, I don't see much of an alternative. Eventually, at some point, you need a typed hole. Using some file in /proc and parsing what people write to it is not a better interface to pioctl; in fact, it's essentially the same interface. [13:45:35] xattrs are not the panacea that you think they are. In particular, when I was talking to David about pioctl, I pointed out that part of the nature of the operation is that it must be up to the individual pioctl handler to decide whether an how to resolve the last path component. [13:45:40] Yeh, Linus thought that was terrible too. [13:47:05] Terrible though it may be, it's essential for some operations. [13:47:46] Frankly, Linux has much worse interfaces than pioctl. [13:50:40] And note that this is the same Linus who thinks it's terrible to change not just undocumented but explicitly undefined semantics of a kernel/user interface (like "no really, if you didn't sync, you don't know your data was written") but refuses to admit that there even is such a thing as an in-kernel interface. In other words, not the world's foremost expert on abstraction. [13:51:24] forgot linux [13:51:30] just write something that RedHat accepts [13:53:34] Unfortunately, that doesn't help people who aren't running RHEL, and it doesn't help David Howell, who works for Red Hat, get kafs-related stuff accepted upstream. [14:01:18] And it especially doesn't help him in his plan to be able to use the OpenAFS userspace with his kernel module. [14:06:26] The openafs userspace already supports interacting with the kernel by operating on a file in /proc. I suppose if Linus is feeling particuarly anti-compatibility we can add an interface based on read/write instead of ioctl and David's thing can work only with clients using the new interface. But really, I don't want to change that interface again for no good reason. [14:07:19] If Linux doesn't want to be the first to adopt an obvious and useful system call interface, I won't be surprised. After all, no other operating system in the last 20 years has done it either, and most of them were a lot friendlier to us than Linux is. [14:07:46] --- mdionne has left [14:08:47] It's a shame when the best level of support and openness a cross-platform open-source filesystem project gets is not from the most populare and well-known open source operating system, but from the most universally despised proprietary one. [14:09:22] --- mmeffie has left [15:12:00] --- shadow@gmail.com/owl34C82CC9 has left [16:03:15] --- dev-zero@jabber.org has become available [16:09:19] --- dev-zero@jabber.org has left: offline [16:09:26] --- shadow@gmail.com/owl0D13C6CD has become available [16:13:35] that certainly did not use to be the case [16:15:02] if redhat accepts whatever it is, perhaps they can help push for mainstream kernel adoption [16:30:11] Linux has been one of the least cooperative platforms for OpenAFS for almost as long as I've been involved in OpenAFS development. [16:31:26] The licensing has been a problem since nearly the beginning, although it was mostly just a words and argument thing until the GPL symbol tagging was introduced. [16:32:37] The kAFS stuff, though, I'm relatively okay with. That's pushback about interface design, which is just something that Linux does. I sometimes would like it to be done more consistently, but I think by and large, while that process is painful, the results at the end are better than they were at the start. [16:33:08] It's a lot better than the GPL arguments. It's at least an argument over a tractable problem and one with a technical basis in design principles. [16:33:33] Hopefully David won't get too upset or frustrated by it. [16:37:57] yeah... the GPL stuff is interesting... though, I guess that extremist view is necessary to end up w. a good middle ground [16:38:04] > Linux has been one of the least cooperative platforms for OpenAFS because open source is better, right? [16:41:16] I think the problem is that the Linux kernel developers really, really hate portable software that wants to interface with the kernel while staying the way it was. [16:41:42] They would really prefer that everything be redesigned with clean, modern interfaces that they like when integrated with the kernel and don't care how much work that is for portability. [16:41:57] Whereas all the commercial UNIXes deal with that scenario all the time and have processes to deal with it. [16:42:23] In other words, it's basically a Not Invented Here syndrome. [16:42:29] i should stop talking as i am sure to put my foot in it [16:43:02] in a related note, i love troegs sunshine pils. [16:43:20] Yeah, it's one of those things where regardless of the reasons, it is the way it is and we get to cope with it. [17:31:46] --- RedBear has left [17:34:03] --- summatusmentis has left [17:51:53] --- deason has left [17:55:49] --- deason has become available [18:41:15] --- kula has left [18:45:04] --- kula has become available [19:12:14] --- RedBear has become available [19:43:17] --- summatusmentis has become available [20:02:45] this is a stupid question, is there a way to use one cvs checkout tree to build on two different platforms without doing 'make clean' ? [22:45:40] --- dev-zero@jabber.org has become available [22:57:40] --- deason has left [23:26:07] There should be, but its currently broken. [23:37:23] --- rra has left: Disconnected [23:39:37] --- dev-zero@jabber.org has left: offline [23:47:18] simon, so I'm pretty much stuck keeping either 3 trees, or running 'make clean' every time [23:47:27] s/3/2/ [23:47:57] Or fixing our bug. [23:48:03] Or nagging Derrick until he fixes it :) [23:48:09] heh [23:48:28] What you _should_ be able to do is to be in a different path, and do ../../path/to/afs/configure [23:49:04] You'll then get an object directory build where all of the build products are placed in the directory you're in, whilst the source remains in your original location. That lets you do multiple builds from the same place. [23:49:24] Sadly, the changes to add versioning information to the XML documentation broke this. [23:50:13] heh, I see [23:50:15] ok, hrm [23:51:04] I think it still works for kernel modules, though. We use it in the RPM builds. [23:51:08] I'm pushing right up to the edge of my internal disk, and so the theory was I could point my linux and my windows VM to a "shared" source tree, and then build on whatever platform I wanted, or code on whatever platform I wanted [23:51:36] without needing to worry about patching source trees, etc. [23:51:45] I don't know if Windows will support object directory builds. That's autoconf magic, which I suspect that windows doesn't have. [23:52:20] well, if it's all broken anyway, I don't immediately care :) [23:52:44] You might be able to do something clever on the Unix side with a tree of symbolic links. [23:53:59] I can re-run regen.sh, configure and make clean everytime, thought maybe I could reduce build time this way though