[00:16:30] --- weylan has become available [00:16:38] --- weylan has left [00:20:04] --- abo has become available [00:45:41] --- sxw has become available [00:51:09] --- sxw has left [01:17:36] --- shadow@gmail.com/owlB6691CF0 has left [01:27:39] --- Russ has left: Disconnected [01:31:27] --- sxw has become available [01:35:29] --- sxw has left [01:36:41] --- sxw has become available [01:45:39] --- sxw has left [02:25:16] --- SecureEndpoints has left: Replaced by new connection [02:40:54] --- dwbotsch is now known as RedBear [02:40:54] --- RedBear is now known as dwbotsch [02:41:08] --- dwbotsch has left [02:41:08] --- RedBear has become available [02:41:14] --- RedBear has left [02:41:36] --- RedBear has become available [02:43:09] --- dwbotsch has become available [03:03:16] --- sxw has become available [03:07:00] --- sxw has left [03:08:50] --- sxw has become available [04:54:17] --- weylan has become available [05:07:05] --- kula has become available [05:12:08] --- shadow@gmail.com/owl0C73EB9D has become available [05:13:26] --- sxw has left [05:27:42] --- sxw has become available [05:32:09] --- SecureEndpoints has become available [06:22:57] --- cg2v has become available [06:28:11] --- weylan has left [06:41:21] --- weylan has become available [06:41:52] --- weylan has left [06:41:55] --- weylan has become available [06:59:57] --- mmeffie has become available [07:00:21] --- dwbotsch has left [07:00:37] --- Rrrrred has become available [07:18:58] --- reuteras has left [07:19:12] --- weylan has left [07:29:20] --- dev-zero@jabber.org has become available [07:29:23] --- dev-zero@jabber.org has left: offline [07:45:27] --- weylan has become available [08:04:24] --- weylan has left [08:11:25] --- sxw has left [08:47:21] --- summatusmentis has left [09:30:39] --- stevenjenkins has left [09:31:27] --- stevenjenkins has become available [09:34:53] --- summatusmentis has become available [09:41:11] --- dev-zero@jabber.org has become available [09:41:15] --- dev-zero@jabber.org has left: offline [09:49:34] --- Russ has become available [10:38:24] --- mmeffie has left [12:01:31] --- dev-zero@jabber.org has become available [12:01:36] --- dev-zero@jabber.org has left: offline [13:47:07] --- cg2v has left [13:54:25] simon would you please review /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/xdr-free-1.patch ? [13:56:25] I think that's wrong. _len is the number of array elements, not the size in bytes of the array. [13:57:26] Also, whilst char * is consistent with the rest of the XDR code, personally I'd prefer void * for anonymous pointers in new functions. [14:01:11] SecureEndpoints - is that smb race condition you mentioned being found finally fixed in 1.5.58? [14:25:20] Simon: you are correct. len is number of elements. although on windows its going to be ignored. I could pass in 0 for all it would matter. I debated between char * and void *. I went with consistency on the grounds that eventually we should just fix all of it. [14:25:52] Rrrred: did you read the release announcement? [14:27:06] all known bugs as of 1.5.58 were fixed in 1.5.58 [14:27:06] We should just fix all of it :) I'm not bothered about the char * vs void * issue now, but it might help your 20,000 warnings not become 20,0001. [14:27:41] no warning produced [14:35:19] secureendpoints - I did... it was unclear if that fix made it in or not [14:35:28] especially from the description of the race condition in the change log [14:36:54] which part was unclear? [14:37:20] * [RT 124293] A race condition exists which permits the scp field of the an smb_fid_t object to become invalid after a request on the smb_fid_t has begun. Remove the race by protecting all access to the scp field with the smb_fid_t mx mutex and obtaining a local reference on the cm_scache_t object for the length of the request. [14:37:30] if the race condition mentioned was the smb race condition you and ms found [14:37:50] ms or msft ? [14:38:07] the race condition msft found is in msft's code [14:38:27] I can't fix msft's code [14:38:30] ah, so, we need a patch from msft for things to really be fixed [14:38:41] good luck with that [14:38:55] so, they were kind enough to find something they have broken but won't actually fix it [14:39:03] they fixed it. [14:39:06] you can't have it [14:39:12] so, what's the point, then? [14:39:28] fixing it is useless if they won't release said fix in a future update [14:39:42] XP is no longer a supported OS [14:39:59] what update are you going to be given it in? [14:40:03] so, why'd they bother supporting it by spending time with you, then? [14:40:20] because they support out of date OSs for customers with the right support agreements [14:40:30] I'm sure you do not have one [14:40:33] so, once again, what was the point? [14:40:48] why waste your time working with MS to fix something if no one can ever use said fix? [14:40:50] because a client that has such an agreement wanted it fixed [14:40:55] That those people spending the right kind of money with MSFT have the fix. [14:41:17] because more to the point, I was able to prove that the bug is not in afsd [14:41:29] so, basically, MSFT sucks, still [14:41:34] and therefore said mgmt won't get rid of afs [14:41:54] msft doesn't suck, use a currently supported release [14:41:55] --- summatusmentis has left: Lost connection [14:42:00] --- summatusmentis has become available [14:42:11] that's more broken than the old release? Uh, no [14:42:14] tell me you are using openafs 1.2 on your servers and I won't fix bugs for you either [14:42:18] Presumably all of this becomes moot with the native implementation? [14:42:28] --- stevenjenkins has left [14:42:30] if oafs 1.4 was broken in comparison to 1.2, yes, I would be [14:42:33] fortunately, it's not [14:42:38] vista is not broken [14:42:38] --- abo has left [14:42:44] neither is win2008 [14:42:54] Apple did a great PR job [14:43:05] Mac OS X is also quite broken [14:43:12] but less broken [14:43:23] --- abo has become available [14:43:26] shame their HW isn't worth the raw materials it's made out of [14:44:28] simon: once the native implementation has a year of real world usage under its belt I will tell you that it is stable [14:44:44] I'm not going to trust the native implementation for quite a while [14:44:51] SecureEndpoints: Understood. I feel much the same about disconnected. [14:44:55] too much spanking brand new code [14:45:05] 80,000+ lines [14:45:15] Ouch. That's ... scary. [14:45:28] --- stevenjenkins has become available [14:45:52] and the architectural lines are not all quite right yet [14:49:49] but the bug list is small [14:50:04] has it been used much, yet? [14:50:11] Is it all in RT? If so, it looks remarkably small for that much new code. [14:54:13] everything I know about is in RT. and no, it has not been used much. I expect the bug list to explode [14:54:56] its just that the existing bugs are serious enough that I don't want to waste people's time [15:00:20] /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/xdr-free-2.patch [15:06:24] I think that's fine. I'd rather not see the signed->unsigned conversion of j and k in the same patch, but that's the annoying pedant in me coming out. [15:07:27] Well, I've found the cause of my Linux kernel panic, now all I need to do is work out why. If DoBulkStat() returns -3, then kaboom. [15:11:24] for the patch is two parts when committed. add xdr_free to src/rx [15:14:04] then remove the warnings from windows [15:15:17] Cool. [15:20:17] if RXAFS_BulkStat returns -3 or the afs_DoBulkStat [15:20:55] or RXAFS_InlineBulkStat ? [15:23:25] shouldn't the inline case at the bottom before exiting not examine statsp if code != 0 ? [15:23:25] afs_DoBulkStat [15:24:00] The inline case is just bogus. WTF do we care what the errorCode from the first FID we decided to fetch is. [15:24:53] I think the fact that the OS gets to see the bulkstat error code at all is probably wrong. It only cares about the result of looking up the path that its requested - we shouldn't let it know about anything that went wrong whilst we tried to do a little extra work on the side. [15:25:49] you look at the return code because that is how you are able to return access denied errors [15:28:01] Hmmm. Actually, dirCookie means that the first FID we fetch is the one the OS asked us for, so that makes a little more sense. [15:28:47] Providing we haven't been raced, that is. [15:39:27] we are going to return success if the function really failed [15:40:32] how does afs_DoBulkStat return -3? [15:40:51] That's my current problem. It's what InlineBulkStatus seems to return on the wire. [15:41:05] (not confirmed through packet trace, but by printing out what its setting code to) [15:41:23] I can't for the life of me see where its coming from at the moment. [15:41:43] as far as I can tell it will always return 0, ENOENT, the return value of afs_VerifyVCache, or the value of the first FID in the array [15:42:07] even if RXAFS_??? returns -3 it can't be passed back to the caller [15:42:48] No, it's the errorCode in the first FID that seems to be -3 [15:57:53] that is timeout. why would it be -3 [15:58:22] darn those negative numbers [15:59:23] off to puppy school [15:59:36] Yeh - the negative numbers are the problem, we're then doing -(-3), getting a postive and calling ERR_PTR with it, which doesn't go so well. [15:59:53] good luck with leo [16:00:09] SecureEndpoints - we once had a dog which failed obedience traiing [16:00:39] so, signed/unsignededness error? [16:01:08] tho, that you can crash by giving ERR_PTR a non-negative number is interesting, too [16:01:39] I _think_ that's what's going on. I need to read more on ERR_PTR [16:01:51] that an afs fnct or a linux fnct? [16:01:59] Linux function. [16:02:55] I'd love to see linux not puke on things like null pointer derefs (or invalid mem accesses) [16:04:17] Well, at least they're at the point where there's a difference between an ooops and a panic [16:08:19] is there? [16:08:28] is one not fatal? [16:09:00] An oops will just cause the module its in pain. Providing that module isn't essential, you can stagger on. [16:09:05] A panic is kind of terminal. [16:09:11] interesting [16:09:27] so, the module has to be able to check for an "oops" somehow? [16:10:02] No. The kernel does that. The module gets upset because its data structures are almost certainly scrambled after an oops. [16:12:05] yeah [16:15:11] let's see if netflix sent the right dvd, this time [17:41:43] --- Russ has left: Disconnected [18:01:19] --- Russ has become available [18:01:47] --- mdionne has become available [18:37:27] --- mdionne has left [18:49:37] --- weylan has become available [19:05:47] --- weylan has left [19:09:35] --- weylan has become available [20:25:52] --- weylan has left [20:28:03] --- weylan has become available [20:31:17] --- weylan has left [20:32:22] --- weylan has become available [20:39:41] --- dev-zero@jabber.org has become available [20:39:45] --- dev-zero@jabber.org has left: offline [22:27:18] --- Russ has left: Disconnected [22:58:41] --- Simon Wilkinson has left [23:24:10] --- reuteras has become available [23:30:26] --- dev-zero@jabber.org has become available [23:30:32] --- dev-zero@jabber.org has left: offline [23:30:38] --- weylan has left [23:55:50] --- Simon Wilkinson has become available