[00:02:17] --- haba has become available [00:13:38] --- abo has left [00:14:21] --- abo has become available [00:44:42] --- haba has left [00:49:22] --- abo has left [00:49:41] --- abo has become available [01:17:01] --- dev-zero@jabber.org has become available [01:18:42] --- abo has left [01:18:53] --- abo has become available [01:57:24] --- abo has left [01:57:47] --- abo has become available [02:03:13] --- haba has become available [02:53:47] --- abo has left [02:54:23] --- abo has become available [03:17:24] --- abo has left [03:17:49] --- abo has become available [03:42:19] --- abo has left [03:43:13] --- abo has become available [03:58:44] --- abo has left [03:59:10] --- abo has become available [04:58:19] --- kaj has left [05:00:41] --- abo has left [05:00:51] --- haba has left [05:01:30] --- abo has become available [05:06:20] --- haba has become available [05:09:30] --- abo has left [05:09:42] --- abo has become available [06:59:51] --- deason has become available [07:10:32] --- jaltman has left: Disconnected [07:27:43] --- abo has left [07:28:31] --- abo has become available [07:29:09] --- meffie has become available [07:48:14] --- haba has left [07:49:14] --- Russ has become available [09:02:40] --- reuteras has left [09:50:52] --- jaltman has become available [10:08:24] --- Russ has left: Disconnected [10:25:37] --- Russ has become available [10:32:25] If anyone wants OpenAFS 1.4.12 packages for Ubuntu (8.04 through 10.04): https://launchpad.net/~anders-kaseorg/+archive/openafs [10:33:06] should they do on openafs.org? does it make more sense for them to go into ubuntu's repo? [10:34:00] They’ll probably be in Ubuntu’s repo for lucid eventually. Getting them into older releases or backports is more difficult. [10:36:14] They could go in openafs.org, but a PPA is much more convenient to maintain. [10:37:28] Also more convenient to use: you run sudo add-apt-repository ppa:anders-kaseorg/openafs and then run an upgrade. [10:38:51] If we wanted, we could register an OpenAFS team on Launchpad and give it a more official-looking PPA. [10:39:06] that sounds like a good idea [10:39:15] It usually mostly matters around releases; the rest of the time, syncing from Debian does the right thing. [10:39:23] But there are a lot of releases. [10:39:32] Also, it would let us maintain backports more easily. [10:49:39] I should kick off some RPM builds. [10:49:53] good idea [10:58:02] --- abo has left [10:58:35] --- abo has become available [11:15:50] --- kaj has become available [11:37:33] --- kaj has left [11:37:34] --- kaj has become available [11:48:54] --- dev-zero@jabber.org has left [11:53:06] --- abo has left [11:53:26] --- abo has become available [11:53:45] So Derrick: in FBSD/osi_sleep.c, if I drop the glock and msleep with the event lock, afsd deadlocks with everything waiting on the glock. If I drop the event lock and msleep with the glock, then afsd doesn't crash immediately on startup. (This is in the memcache case; there is still some bad locking in the ufs-cache case.) It's not immediately clear to me that this latter locking is wrong; do you have any thoughts? [11:55:02] um. i think you're solving the wrong problem. lemme look [11:55:31] Well, if you drop the glock, sleep, and then wake up and try to reacquire it, you are violating the lock order [11:55:51] Well, if you try to reacquire it while already holding something else [11:55:57] Right, and it bites me. [11:56:31] OTOH, you should be trying to avoid sleeping with the glock held. [11:57:01] ... because that means all of AFS sleeps with you [11:57:05] try this: change osi_Wait to never call the code ifdef'd AFS_FBSD50_ENV. [11:57:08] You should try to avoid sleeping with any lock held. [11:57:14] change both those to if 0 [11:57:53] that's not the "real fix", but it will tell me if i have the right idea [11:59:16] well, yes [12:08:42] > Well, if you drop the glock, sleep, and then wake up and try to reacquire it, you are violating the lock order [12:08:52] Hang on, is that not exactly what Linux does? [12:09:20] Sorry; if you do that while holding another lock which is ordinarly acquired with the glock already held. [12:09:34] a real lock, not an AFS lock [12:10:01] Do the BSDs have real locks? [12:10:19] Define "real lock" [12:10:22] a kernel lock, he means [12:10:24] I think most things have at least some real locks [12:10:40] We have more real locks than we know how to count. [12:10:47] basically, i am pretty sure what i told kaduk to do will fix it. [12:10:56] actual syncronization primitives implemented by the kernel. every platform must have something like this, because the glock is one. [12:11:00] i incompletely ported the macos event lock support [12:11:04] Also, I don't have my laptop with me, so I can't actually test that right now (lunch break). [12:11:30] a lunch what? [12:12:57] --- abo has left [12:13:40] --- abo has become available [12:14:28] some people stop working while they eat lunch [12:15:43] they what working while they eat what? [12:16:05] your strange alien language confuses and infuriates me [12:17:01] they eat food, sort of in the middle of the day [12:17:19] instead of working [12:17:23] I know; it's confusing [12:17:32] it'll never catch on [12:21:30] Working doesn't interact very well with hands covered in grease. [12:21:47] can i suggest grazing? [12:23:05] No; he said hands covered in @b(grease), not grass. [12:24:37] Also, I tend to need to go to someplace that is not my office in order to acquire food. [12:24:52] oh. wifi ftw [12:24:55] Of course you do. That's what laptops are for. [12:26:11] --- abo has left [12:26:30] --- abo has become available [12:26:44] >sorry; if you do [drop the glock, sleep, then try to reacquire it] while > holding another lock which is ordinarily acquired with the glock > already held This is the scenario I described that deadlocked. (msleep() takes a mutex argument, and drops the mutex before sleeping and reacquires it upon waking, but the caller must re-verify all checks made before sleeping upon return from msleep.) [12:27:15] > laptops I thought that's what the SIPB office was for [12:27:38] that works, too, if one is sufficiently close to it. I find it's a bit of a walk from my house. [12:29:02] Well, yes, some people are at a bit of a disadvantage on that front. [13:34:29] --- jaltman has left: Replaced by new connection [13:34:30] --- jaltman has become available [13:45:36] --- haba has become available [13:56:57] --- jaltman has left: Disconnected [13:57:05] --- jaltman has become available [14:38:19] --- Kevin Sumner has left [14:49:39] --- meffie has left [15:30:27] --- mdionne has become available [15:38:49] --- deason has left [15:56:12] --- jaltman has left: Disconnected [16:15:23] --- deason has become available [17:27:27] --- Russ has left: Disconnected [17:48:57] --- Russ has become available [18:30:39] --- shadow@gmail.com/owl95560A96 has left [19:11:51] --- mdionne has left [20:18:09] --- Born Fool has become available [20:22:00] --- jaltman has become available [20:35:19] is the usenix bit still the best way to donate to oafs? [20:39:47] best is relative. [20:41:04] well, ideally, I'd like to do a PO or a credit card [20:41:29] cutting an actual check is going to cause enough pain that my req to donate any money will most likely get a no from the getgo [20:57:29] starking, the else clause of the FBSD50_ENV conditionals in osi_Wait fail to compile due to structure layout changes. Did you mean that I should compile with neither branch of the conditional? [21:23:08] Does this look familiar to anyone? [16529.889547] openafs: getvolslot none<0>------------[ cut here ]------------ [16529.889643] kernel BUG at /var/lib/dkms/openafs/1.4.12/build/src/libafs/MODLOAD-2.6.24-27-server-MP/afs_volume.c:133! http://pastebin.com/nxDhBzmY [21:26:16] In retrospect unsurprisingly, the version compiled with neither branch panics because it's sleeping with the event lock held. [21:37:05] --- steven.jenkins has left [21:47:00] Derrick? [22:07:57] --- steven.jenkins has become available [22:08:32] I’m going to go ahead and create an openafs team on Launchpad so we can set up some official-ish Ubuntu PPAs, since it sounded like everyone thinks this is a good idea. [22:10:36] --- Born Fool has left [22:10:38] If you send me Launchpad usernames I’ll make you administrators. [22:12:40] --- reuteras has become available [22:32:46] --- shadow@gmail.com/owl7F31A9A2 has become available [22:45:29] --- deason has left [22:57:10] msleep called with the event lock as the lock in question and held should dtrt. that's the point. The parameter mtx is a mutex which will be released before sleeping and reacquired before msleep() returns. [23:01:33] But then how does the glock fit in? [23:01:44] why does the glock fit in at all? [23:02:12] The glock is currently the mtx argument to msleep() in osi_Sleep [23:02:36] andersk: rra-debian is my Launchpad username. [23:02:36] hang on [23:04:31] try gerrit 1554 [23:05:57] achandle->proc is not defined in the FBSD50 case. [23:07:44] hey, a freebsd-only "special" version. yeah, let's fix that [23:08:21] (and might want to be a thread anyway) [23:08:33] Should I comment on 1554 on gerrit? [23:08:39] won't actually matter. it's debug info [23:09:05] 1554. second patch [23:10:59] comment if you so desire [23:11:08] that's the point of gerrit: anyone can [23:20:02] Haha, that !FBSD50 code must be really old ... waitV is undeclared. [23:21:51] i pushed that like 5 minutes ago [23:21:57] (patch 3) [23:23:15] --- kaj has left [23:23:20] the !FBSD50 code was the original code. the other stuff was newer but not done for all of the stuff in the sleep set. the macos stuff uses the same locking and sleep stuff and was universal. we don't really need 2 sets of the same functions. [23:23:40] really the mac and fbsd versions of osi_sleep.c should be merged [23:32:35] Russ: you’re an administrator now. [23:32:49] I created a PPA at https://launchpad.net/~openafs/+archive/stable (ppa:openafs/stable). It’s currently building 1.4.12 packages for hardy through lucid that should be the same as the ones in ppa:anders-kaseorg/stable. [23:34:39] The lucid package is unmodified from 1.4.12+dfsg-1 and built against dkms 2.1.1.2-2 (which should shortly be synced into lucid main), and the hardy through karmic packages have commit 5055569 “Use dh_dkms for DKMS maintainer script handling” reverted. [23:35:05] (er, by ppa:anders-kaseorg/stable I mean ppa:anders-kaseorg/openafs) [23:36:10] Cool, thanks. That sounds great. [23:36:14] When you have 1.5.x packages ready we should put them in another ppa (ppa:openafs/master or something) so that it’s easy for Ubuntu users to test them. [23:36:25] Yup. [23:36:31] Should be ready shortly after 1.5.73 is out.