[00:45:15] --- haba has left [00:57:38] --- dev-zero@jabber.org has become available [02:46:31] --- Jeffrey Altman has left: Replaced by new connection [02:46:32] --- Jeffrey Altman has become available [04:24:46] --- haba has become available [04:26:58] --- Simon Wilkinson has left [05:48:47] --- Simon Wilkinson has become available [06:29:43] I think it would be useful to apply simon's krb5 error message hack to translate_et but translate_et is just a wrapper around util_AdminErrorCodeTranslate() from src/libadmin/adminutil/afs_utilAdmin.c. The problem is that on Windows at least, the functions to initialize the error tables are not available outside the various DLLs. That means that afsadminutil.dll must be linked to krb5_32.dll. The kerberos error tables are initialized during DLL load on Windows (or when the first krb5_init_context() call occurs on Unix.) My thought (and I think this is true for aklog as well) is that instead of calling error_message() for the translation we should be using krb5_get_error_message() on platforms where that is available. Simon, do you have any thoughts on this? [06:52:44] --- deason has become available [06:56:14] Yes. We should. [06:56:28] Russ pointed that out a while back, actually. [06:57:00] The problem is that it requires someone to go through and identify which aklog functions are returning Kerberos errors, and which are returning AFS errors. [06:58:29] --- reuteras has left [07:04:24] unless you use your strcmp("unknown", str) hack. then you always call into one or the other [07:09:15] --- Simon Wilkinson has left [07:09:51] --- Simon Wilkinson has become available [07:12:48] Yeh, but it would be nice to not be that nasty. [07:37:26] Now you should have something in RT about the hang on the vldb yesterday. [07:49:46] --- haba has left [07:57:08] --- Kevin Sumner has left [08:10:28] --- meffie has become available [08:10:48] --- jaltman has left: Disconnected [08:10:57] --- jaltman has become available [08:11:09] My thought is that you should use more line breaks. [08:44:20] --- kaj has left [09:29:31] --- dev-zero@jabber.org has left [09:52:53] --- Russ has become available [11:06:27] I think to make our PAG usage entirely safe, we'd need to lock afs_user using a Linux spinlock, rather than an AFS lock. [11:16:47] Uh... why? [11:17:08] Because pag_destroy is called with a spinlock held [11:17:34] So, getting the GLOCK is a pretty bad idea. [11:17:53] doing anything resembling blocking is a bad idea while holding a spinlock. Including acquiring a spinlock. [11:18:23] Providing your lock order is sound, you can get a spinlock whilst holding another spinlock. The kernel does that all the time. [11:18:53] The problem is doing anything that causes your process to be rescheduled whilst holding a spinlock. [11:19:07] You _can_, but it's a bad idea if you're likely to block for any length of time, because if you do, anyone trying to acquire the spinlock you're holding spins (not blocks), which is bad for power and performance. [11:19:35] Oh, you certainly can't do something that causes rescheduling, since that would violate the locking order [11:19:41] Yes - spinlocks should only be used for operations that take very small amounts of time (for varying definitions of very small, in different parts of the kernel) [11:20:13] If we can see a way to avoid holding a spinlock for long in favor of, say, introducing a mutex, we should probably take it. [11:20:35] Well, we don't have a choice. [11:20:46] For example, perhaps we give afs_user a "destroyed" bit that is protected by a spinlock, and move the actual destroying into a thread that can examine that bit and take a mutex. [11:20:47] The kernel gets a spinlock, then calls into our keyring destructor function. [11:20:55] Ah, yes. That works. [11:21:15] The current problem is that we have to walk the user list to work out what was destroyed. [11:57:04] --- meffie has left [12:06:58] Although, in Eric's case, I suspect we're not actually destroying anything. His problem looks a lot like our destructor isn't firing, or is firing but then can't find the associated user object. [12:39:11] --- kaj has become available [13:46:39] --- mdionne has become available [14:27:16] --- kula has left [14:30:58] --- kaj has left [14:32:42] --- summatusmentis has left [14:50:39] --- phalenor has left [14:51:32] --- kula has become available [15:00:42] --- phalenor has become available [15:15:34] --- deason has left [15:17:54] --- shadow@gmail.com/owl8B3EC998 has left [17:32:01] --- Russ has left: Disconnected [17:49:28] --- Russ has become available [18:48:50] --- mdionne has left [22:18:36] --- shadow@gmail.com/owl95560A96 has become available