[05:15:17] --- meffie has become available [06:02:43] 3423 looks plausible. I may get to test tonight. [07:00:20] --- deason has become available [07:16:42] --- sxw has become available [07:33:52] --- mho has become available [07:40:28] --- sxw has left [07:42:20] --- Russ has become available [08:06:16] --- Russ has left: Disconnected [08:11:08] could someone clarify for me... has the unix cm never (previously) had code to call RXAFS_GiveUpAllCallBacks ? [08:19:49] correct [08:34:19] but, there was a bug in the server? [08:38:44] yes [08:39:10] from 1.3.50-1.4.5 iirc [08:55:44] I believe the history is that the RPC was implemented at the request of Arla. OpenAFS never implemented the client side. We only ever implemented the server but the server implementation had two bugs. The first was fixed as part of (6c7a2901b00ae2f7df0bdff23b19fdd3b7f35156, viced-fix-check-rights-race-20060213, RT 25869) in which core dumps of the file server were being generated due to unsafe invalidation of the client's prlist. DeleteAllCallbacks_r() was being called even if GetClient() failed. The second fix which resulted in the security advisory was (b0b3565b69b0b8fda46b25e7bd73c5116b32d83e, giveupallcallbacks-locking-20071121, RT 74708). This is where it was noticed that the H_LOCK was not properly held. All Windows clients from 1.5.21 to 1.5.27 issue the RXAFS_GiveUpAllCallBacks RPC unconditionally. Based upon the Windows Error Reporting statistics these clients still make up a significant percentage of deployed clients for which error reports are being generated. [08:57:02] thank you. [09:00:53] Those Windows clients were distributed from 2007-07-10 to 2007-12-09. 1.5.21 was bundled by many universities as part of their Fall semester distribution. [09:14:47] --- sxw has become available [09:15:02] --- sxw has left [09:18:53] --- mlane has become available [09:24:38] --- mlane has left [09:28:25] What OS functionality is needed for dynamic vcaches, again? Is it just sleepless memory allocation in a particular path? [09:29:11] the reason we have them only on linux was that linux needed them. not a condition of vice versa [09:29:25] e.g. we had no way to deal with inotify using up all our vcaches [09:30:15] (I wanted to look and see the behavior of afs_vcount with dymic vcaches, but don't have a good linux scratch box at the moment.) [09:36:28] --- sxw has become available [10:01:04] --- jaltman/FrogsLeap has left: Disconnected [10:02:57] --- jaltman/FrogsLeap has become available [10:09:33] --- sxw has left [10:11:10] --- jaltman/FrogsLeap has left: Replaced by new connection [10:11:11] --- jaltman/FrogsLeap has become available [10:34:26] --- jaltman/FrogsLeap has left: Disconnected [10:50:41] --- jaltman/FrogsLeap has become available [12:15:05] Andrew, do you have any packet traces you can share for 128671? [12:17:09] I assume you want pre-gerrit 3425... I think so, let me find them [12:17:33] or actually, I have traces of artificially-induced RX_PACKET_TYPE_BUSY responses, which I don't know if you want [12:17:47] the real-world ones aren't mine, so I need to ask if I can [12:18:08] if you want to know what the extant call is that I'm colliding with, I don't know [12:21:31] I'm not as interested in why the server things the call slot is busy. I think the client (if it has a free call slot) should give up the call and retry the call with a different call slot after waiting some period of time. However, that will require failing the call up the the application to permit the application to retry. [12:22:16] At the moment call structures are exposed so I do not think it would not be safe to start swapping them around. [12:23:17] well, if someone's looking at them without holding locks I'd be concerned anyway, but if someone remembers the channel number or cid for later, yes, I can see the concern [12:24:14] with the multi rx connection patch that went into to master today from matt, only the application will know if there are free call slots [13:54:09] --- jaltman/FrogsLeap has left: Disconnected [13:57:42] --- jaltman/FrogsLeap has become available [15:15:12] --- deason has left [15:38:28] --- mdionne has become available [15:53:14] --- jaltman/FrogsLeap has left: Disconnected [15:54:27] --- deason has become available [16:10:36] --- jaltman/FrogsLeap has become available [16:54:17] --- Russ has become available [16:54:32] --- shadow has become available [16:55:51] --- shadow has left [19:27:54] --- mdionne has left [21:16:56] --- Russ has left: Disconnected [21:27:09] --- deason has left