[00:27:48] --- abo has become available [02:38:38] --- sxw has become available [02:40:05] --- sxw has left: Replaced by new connection [02:40:05] --- sxw has become available [02:41:18] --- sxw has left [02:53:44] --- sxw has become available [04:44:25] Bah. We fail the connectathon locking test suite. [04:44:43] which test suite is that? [04:45:25] http://www.connectathon.org/nfstests.html [04:45:49] In particular, their lock tests, which just check for correct POSIX locking semantics. [04:46:26] On Linux, we should pass them all, providing all of the locks are acquired locally. We don't... [04:48:57] (Aside: I've got a user who's seeing data corruption on files held in AFS, but only accesses those files from processes running on a single machine. He's maintaining that this is because locking is broken, an opinion he initially formed due to the contents of dmesg) [04:50:05] which tests fail? [04:52:13] Well, it stops after the first failure (which I'm about to fix), but currently test 3.3 [04:52:49] (Parent locks bytes 0->1, child tests bytes 1->1, child gets EACCESS ) [04:57:08] that test looks wrong to me [04:57:28] Wrong in what way? [04:58:54] 3.0 is parent locks the file and it should succeed 3.1 is child locks the file and it should fail 3.2 is child locks the file and it should fail 3.3 is child locks the file and it should succeed but the parent was not released so it could unlock the file between 3.2 and 3.3 [04:59:34] I guess the test is right. [04:59:38] Is the child not locking a different byte range than the parent holds, though? [05:00:17] 0->1 and 1->1 are overlapping ranges [05:01:19] I need to look at the posix specifications to see whether the upper bound is considered part of the locked range or not [05:01:48] if not, I would like to know what locking the range n->n is supposed to mean [05:02:01] What's interesting is that Linux passes all these tests for a file held locally. [05:02:29] And yet, with byte range locks, we just defer all of our testing to the VFS - so we should be using exactly the same routines as ext2 does. [05:02:43] that is what I would assume [05:02:56] And yet one passes, and we fail. So, I'm a little confused, and fstrace isn't helping. I guess I need to go instrument the kernel module a bit more ... [05:04:43] Turns out those test parameters are offset, and length. [05:04:54] So the parent has byte 0 locked (offset 0, length 1) [05:05:10] The child tries to lock byte 1 (offset 1, length 1), and gets EACCESS [05:06:22] perhaps VFS thinks we have a minimum range length? [05:08:29] It's also interesting that we're getting EACCESS, and not EAGAIN. [05:09:37] afs_linux_lock() passes in the pid of the requestor. [05:10:50] and not the pid that opened the file descriptor which was inherited by the child process [05:12:11] I think that's correct. The lock is owned by the process requesting it, not the process which opened the file. [05:13:27] In any case, as len is not 0, lock_ctl should just return success. [05:23:45] afs_lockctl() does not have any special processing for F_TEST [05:23:49] Although, linux-posix-lock-file-has-wait-arg-now-20070517 (with the inspiring comment "hopefully this works, i can't actually try it now") is rather bogus. [05:25:17] the child's F_TEST, offset 1, len END (if END matches OFFSET_MAX will cause len to be reset to 0 [05:26:38] --- SecureEndpoints has left: Replaced by new connection [05:26:51] --- SecureEndpoints has become available [05:27:53] But in order to stop looking like a byte range lock, we need offset ==0 and len ==0. So, we'll always go down the fast path. [05:28:13] I guess the question is, what are we doing in the F_TEST case, given we don't explicitly handle it? [05:28:25] looks like we return EINVAL [05:30:57] Bear in mind that F_TEST is the lockf() interface, and Linux uses the fcntl() interface natively. I suspect F_TEST is getting mapped to F_GETLCK [05:31:38] does the user have 'k' permission? [05:31:44] Yes. [05:31:56] is a lock request being sent to the file server? [05:32:09] For this test, no. [05:32:26] (Which is what we'd expect, because byte range locks don't involve the file server) [05:34:21] if F_TEST is being converted to F_GETLCK then I would expect the F_TEST, 1, END test to obtain a full file lock [05:35:09] since the logic in afs_lockctl() does not verify that offset is 0 before resetting len to 0 [05:35:26] But F_GETLCK doesn't go near that logic. [05:35:27] --- sxw has left [05:36:37] --- sxw has become available [05:37:12] If we have F_GETLCK, we call HandleGetLock, which always returns 0, and then exit afs_lockctl [05:38:03] linux defines AFS_OSF_ENV ? [05:38:27] sorry, misread that #ifndef [05:39:37] the indenting in afs_lockctl() leaves a lot to be desired [05:40:13] --- sxw has left [05:40:14] --- sxw has become available [05:40:32] can you verify that F_TEST is being converted to F_GETLCK ? [05:40:42] Yes. The test suite actually does it. [05:40:53] (If you build without USE_LOCKF, which I've just done) [05:44:00] And, actually, the EACCESS is coming because we're making no changes to the fcntl structure before we return it. [05:44:19] So, the problem is entirely that we need to let the kernel get a look in on getlocks, as well as on setlocks. [05:44:22] Patch coming up. [05:50:36] At some point, we're going to have to just bite the bullet and maintain all of the byte range lock information ourselves. But that's complex, because Unix's byte range semantics are somewhat trickier than Windows (on Unix, you can unlock a range from within an already held lock) [05:53:44] We're going to have no choice if we're going to maintain byte-range locks on the server someday. [05:54:21] Indeed.. [06:16:50] And, there's another bug. In some cases, we end up just taking a whole file lock anyway. I suspect that the Java VM check is being miscompiled. [06:45:03] RT should get a ticket of "things which are open for future 1.4.x needs" we can link to. in fact, maybe i should just do that now [08:25:09] Well, I think byte range locking has been hosed on Linux for ~forever. We miscalculate the lock range by 1 byte (a Linux lock from byte 0 to byte 0, is a fcntl lock of offset 0 and size 1, _not_ one of offset 0 and size 0) [08:27:51] Well, that explains why locking might not have effect. It doesn't explain why that test failed. [08:28:54] Because if we're going from offset 0, with a size of 0, we get a whole file lock. So trying to lock byte 1 should actually fail. [08:29:37] The second issue is that our getlock code path never actually looks at the byte range locks ... [08:32:57] --- dev-zero@jabber.org has become available [08:33:08] --- dev-zero@jabber.org has left: offline [08:36:28] --- reuteras has left [08:44:46] Oh, duh. [09:40:37] --- Russ has become available [09:42:25] Turns out that when someone re-extracts the afs@REALM principal, you lose quite painfully ... [09:47:39] Only when using an "extract" that is actually "generate a new random key". [09:48:12] Yes. Fun, fun, fun. [09:50:56] Thankfully, we also have afs/cell@REALM, so it's only certain things that are losing. [10:12:26] sxw - so, your error return code patch does not appear to have broken anything, so far [10:21:39] --- dwbotsch has left [10:21:57] --- Rrrrred has become available [10:56:41] --- dev-zero@jabber.org has become available [10:56:45] --- dev-zero@jabber.org has left: offline [11:44:42] --- dev-zero@jabber.org has become available [11:44:47] --- dev-zero@jabber.org has left: offline [12:04:44] --- mmeffie has become available [12:17:02] Well, I'm now past the lock tests that just fail, and now onto the ones that make the kernel BUG(). Fun fun fun. [12:55:18] Woot. We now pass the NFS lock tests ... [13:00:56] --- sxw has left [13:53:18] --- dlc has left [13:53:34] --- dlc has become available [14:59:53] --- matt has become available [15:46:28] It's been a few months on my submission to the registrar. [15:51:58] what ticket #? [15:57:15] 124161 [16:08:52] --- sxw has become available [16:11:58] --- sxw has left [16:11:58] --- sxw has become available [16:12:55] What happened with getting Kula onboard to help clear the back log? [16:13:17] I'm working on it. [16:13:39] It would be good to have more than one person - helps smooth out the bumps somewhat! [16:14:02] This week, in fact. It's just that first I'm unburying myself from F10 port work that was supposed to be in alpha test a couple of weeks ago. [16:14:36] I know that feeling. I have an identity management system that was supposed to have shipped by now ... [16:14:45] anyway... looks like matt is looking for an RXAFSCB procedure number and a couple of capability numbers. [16:15:28] right [16:15:43] Is there anything that can be sent to afs3-standardisation ? [16:15:54] (with or without the z :)) [16:16:08] what do you mean? [16:16:39] In terms of descriptions of what the new items are? Or is it for something you've already sent there? [16:16:50] Not interested in sending it for discussion, just so there's a record. [16:17:01] Yes, for that request, I am requesting stable numbers for extended callbacks. [16:17:40] (I will likely request same for locking in the next while, but xcb is fully implemented, and shouldn't be shipped around with bogus numbers.) [16:17:49] Indeed. [16:18:06] What are you doing for security with xcb? Or is it in an environment where that isn't a concern? [16:19:11] Well, I would pretend the latter. What I'm doing really is trying to herd along a well-defined proposal to secure the callback channel. [16:20:18] Okay. Is it deployable into the world at large with our current security model? [16:22:15] I've discussed this with jeff altman a bit. I'm of the opinion that -parts- (range invalidates, plus cancel) would be legit to enable at large, and a closed environment could consider doing more of it. I think there's gatekeeper support for merging with the current security model, but I don't think it could be enabled by default until a viable security mechanism is also. [16:23:16] Jeff felt that enabling part of the messages was just extra complexity, and I am not proposing it unless someone surfaces to request it. [16:23:56] All that sounds reasonable. I think that's something that we could do with actually engaging with the community about, though, rather than making decisions on their behalf. [16:24:17] I agree. [16:24:23] Have you considered writing something brief (a paragraph or so) about extended callbacks for the newsletter that Jason is putting together? [16:24:51] matt's has summarized my comments well. I also would like to get the code into the code base so that it can be properly exercised. [16:25:45] Yes, he emailed me, and I sent a short blurb about its status (what Jason asked for). It doesn't describe the features. I'm prepping a full writeup for the afsbpw. I think Jason might just mention the afs3-standardisation draft. [16:26:05] 65539..65542 are taken, though it looks possible that the same procedure may have been allocated two numbers. You'll get 65543. [16:26:28] Excellent. I think short is good, just to let people know what's happening. Not everyone will make it to the workshop, or read the talks from it. [16:26:56] jhutz: excellent [16:27:37] It seems that we are treating capabilities as a bitmask. That's going to get interesting once we have more than 32 of them, since the wire protocol represents them as a vector of 32-bit integers [16:28:06] I assumed the idea is it would become an array of bitmasks? [16:28:46] --- stevenjenkins has left [16:28:49] --- abo has left [16:28:50] Or some general bitfield, if someone got carried away... [16:29:00] --- abo has become available [16:29:54] Well, yes, I believe that is what we decided when we defined them. It's just that the table is going to get interesting. I can't really say that VICED_CAPABILITY_WALK_DOG is 0x20000000000000000000000000000000 and expect code to have a preprocessor macro like that. [16:30:19] No, it's already represented as a vector of 32-bit bitmasks. [16:31:30] Yeh. Code wise (and spec wise) we're going to need to come up with a way of expressing them that makes sense. [16:31:37] --- stevenjenkins has become available [16:31:44] (Possibly as bit shifts?) [16:32:03] Yeah, probably. [16:32:45] we are reading/writing bitmasks in an array. They should most likely be allocated as {VECTOR, BIT} pairs [16:35:52] I'm not sure what you mean. We do allocate bits separately for each capability vector (client, viced, etc). I don't think it makes sense to describe VICED_CAPABILITY_WALK_DOG as { 3, 0x20000000 } [16:37:09] why not? that is how they will be processed. Especially if we move beyond the native integral size of the device. [16:40:17] I'm inclined to just call it bit #125. [16:40:27] I would be too. [16:40:45] I think that's _much_ clearer from an allocation standpoint. And from a development standpoint too. [16:41:21] Then you just need to write a few functions to test, set and clear an arbitrary bit number in an array of ints. [16:42:00] For one thing, it's easy to define a macro whose value is 125, and a pair of macros that turn that into the vecror index and mask. Or ==sxw. It's harder to define a macro whose value is { 3, 0x20000000 } and do anything useful with it (not impossible, but harder) [16:44:23] --- dlc has left [16:49:58] --- sxw has left [17:36:25] I would like to bring the NFSv4 Federated File System Requirements Internet Draft to everyone's attention http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-02.txt [17:48:07] oh, nfsv4 [17:51:26] --- matt has left [18:00:38] --- Russ has left: Disconnected [18:16:36] --- Russ has become available [19:06:03] --- mmeffie has left [20:35:34] > It seems that we are treating capabilities as a bitmask. [20:35:40] that was how they were proposed. [21:09:05] --- dev-zero@jabber.org has become available [21:09:08] --- dev-zero@jabber.org has left: offline [22:04:51] --- dev-zero@jabber.org has become available [22:04:55] --- dev-zero@jabber.org has left: offline [22:07:44] oafw works quite nicely on win7 [23:39:01] --- kula has left [23:39:01] --- Rrrrred has left [23:41:15] --- kula has become available [23:44:02] --- Rrrrred has become available