[01:24:51] --- Russ has left: Disconnected [01:25:13] --- Russ has become available [01:26:26] --- Russ has left: Disconnected [01:28:07] --- Russ has become available [01:44:27] --- Russ has left: Disconnected [01:44:51] --- Russ has become available [03:12:58] --- Russ has left: Disconnected [09:02:24] --- mdionne has become available [12:29:19] --- Russ has become available [12:34:23] --- Russ has left [12:36:13] --- Russ has become available [12:36:28] --- Russ has left: Disconnected [12:39:32] --- Russ has become available [12:44:33] --- Russ has left: Disconnected [13:39:46] --- Russ has become available [14:08:25] --- Russ has left: Disconnected [14:09:23] --- Russ has become available [18:39:44] --- jaltman/FrogsLeap has left: Disconnected [18:41:32] --- jaltman/FrogsLeap has become available [18:41:48] --- deason has become available [18:42:11] so, I thought 1.7 was just going to be 1.6 + windows; apparently that changed? [18:42:59] windows builds the file servers, ukernel, etc [18:43:07] its roughly tracking master [18:43:15] 1.7 is not meant for unix builds [18:43:43] "Did you just rebase master onto 1.7, though?" [18:44:06] no. we use a cherry pick model [18:45:24] I am aware. But a rebase is essentially a stream of cherry-picks. I didn't bother to go through and look if the new commits on 1.7 comprise ~all work that has been done on master or only some select subset, which is what I was trying to ask. [18:45:35] it is not all [18:45:42] Okay. [18:57:22] Hmm, have we seen this one? lock order reversal: 1st 0xfffffe00aa779060 call lock (call lock) @ /usr/ports/net/openafs-devel/work/openafs/src/rx/rx.c:6898 2nd 0xfffffe00aa019210 conn call lock (conn call lock) @ /usr/ports/net/openafs-devel/work/openafs/src/rx/rx.c:2705 [19:05:11] --- jaltman/FrogsLeap has left: Replaced by new connection [19:05:12] --- jaltman/FrogsLeap has become available [19:09:50] I don't see what the three lines following my question have anything to do with my question... [19:11:01] Well, they are tangentially related, but not really a direct answer. [19:13:33] But anyway, master seems to have fixed my "all buffers locked" issues. Now, on to issues with VOP_LOOKUP ... [19:38:24] deason: the purpose of 1.7 has not changed since the discussions in late August. at that time we decided 1.7 would not be a branch to which windows changes would be initially pushed and then cherry-picked back to master. Instead all changes would go to master and be cherry-picked to 1.7 for releases. 1.7 is only for the windows releases. the windows releases include more than just the cache manager. I'm picking to 1.7 all of the commits that (a) are directly windows; (b) impact the windows servers or any support libraries; (c) might have an impact on the ability of other patch sets to apply going forward. This is a rehash of what I have said previously. If this is not an answer to your question, could you try rephrasing it? [19:46:14] kaduk: the rx lock ordering issue looks familiar. I'm sure we have discussed it in the past. [19:51:35] jaltman: okay, I couldn't remember. I only remember filing a ticket for a slightly different one. [19:52:26] have you experienced an actual deadlock or is it just detection of the lock order violation? [19:55:52] --- mdionne has left [20:00:56] It's just a detection of the lock order violation. [20:01:18] (And there can be cases when such LORs are guaranteed to never deadlock, of course.) [20:10:00] Hmm, suppose I wanted to make an afs_lookup() call return an error. Do I have an easy way to do so? [20:43:41] --- deason has left [20:47:48] --- deason has become available [21:26:07] --- jaltman/FrogsLeap has left [21:26:29] --- jaltman/FrogsLeap has become available [21:30:32] --- deason has left [21:48:13] we don't have any hooks in place to permit injecting errors but I think you knew that. what kind of error do you want to return? [21:56:43] I don't particularly care. (I mean, I could recompile and test the error case of afs_vop_lookup every 1/100 entries if I really wanted.) I believe I fixed a locking bug that causes a recursive mutex lock --> panic every time that error branch is taken. [22:01:00] I would attach a kernel debugger, place a breakpoint, force the branch to be taken and let it go [23:04:59] --- jaltman/FrogsLeap has left: Replaced by new connection [23:05:00] --- jaltman/FrogsLeap has become available [23:15:14] --- jaltman/FrogsLeap has left: Replaced by new connection [23:15:31] --- jaltman/FrogsLeap has become available [23:17:29] --- jaltman/FrogsLeap has left: Replaced by new connection [23:17:30] --- jaltman/FrogsLeap has become available [23:20:43] --- jaltman/FrogsLeap has left: Replaced by new connection [23:20:44] --- jaltman/FrogsLeap has become available