[00:46:04] --- haba has become available [02:38:55] --- Simon Wilkinson has left [03:10:09] --- reuteras has left [03:13:47] --- reuteras has become available [04:08:16] --- reuteras has left [05:07:43] --- Simon Wilkinson has become available [05:27:26] --- Simon Wilkinson has left [05:27:26] --- Simon Wilkinson has become available [06:03:58] --- Simon Wilkinson has left [06:04:05] --- Simon Wilkinson has become available [07:24:45] --- Simon Wilkinson has left [07:24:46] --- Simon Wilkinson has become available [07:26:17] --- deason has become available [07:36:30] --- Simon Wilkinson has left [07:36:31] --- Simon Wilkinson has become available [08:30:31] --- Jeffrey Altman has left [09:37:44] --- haba has left [10:23:21] I don't know if this new LINUX_STATFS_TAKES_DENTRY test works properly... [10:23:39] it seems to be saying statfs does take a dentry on this 2.6.9 kernel, when it does not [10:24:06] I presume this is because passing incompatible pointers to the statfs function pointer is just a warning, not a build error, so we don't notice [10:25:05] I thought that that test checked for a changed number of arguments. [10:25:57] That's how such tests usually work. Testing for a changed artument pointer type is much more perilous. [10:26:04] doesn't look like it, afs_statfs is either afs_statfs(struct dentry *dentry, struct kstatfs *statp) or afs_statfs(struct super_block *sbp, struct kstatfs *statp) [10:26:55] Gah. I suspect you're going to have to enable warning-as-errors in that test. Which is always fragile. [10:28:07] the thing that does the actual compiling is our own autoconf code, though; maybe we could have a way of specifying a warning to look for in the output or something.... [10:33:24] I'm also not sure how a statfs() into AFS is not panic'ing the machine if this is wrong... but there is at least a warning about it when building [10:38:28] hah, it looks like we just get lucky... f_bsize=488917820 when that happens, so it looks like we get garbage, but at it's dereferencable [10:50:40] --- Simon Wilkinson has left [11:39:37] --- Russ has become available [15:10:08] --- mdionne has become available [15:27:50] that's actually an old configure test, it's been there since 2006. the only thing that changed recently is the function that is tested. for 2.6.9 it wouldn't change the result [15:37:48] --- jaltman has left: Replaced by new connection [15:37:49] --- jaltman has become available [15:39:06] it was changed from declaring a function to calling a function; decl'ing a function with different arguments will cause an error and thus works [15:39:19] but just calling it is just a warning so it doesn't [15:47:47] Hrm, tricky. [15:49:54] so, part of the answer here is that we really should be doing affirmative tests for both possibilities, rather than assuming that success in one case means failure in the other and vice versa. That wouldn't "fix" the problem, but it would make configure fail instead of proceeding with wrong test results. [15:50:08] hmm, ok. I had to change that since the op is not an actual function [15:50:39] So, the next question is, can we get away with continuing to test vfs_statfs by (a different) declaration, rather than moving to testing a function pointer for which there is no sure way to do this test. [15:50:48] yeah, I mean, we certainly had a good reason for changing it [15:51:02] jhutz: afaik, the answer to that is "no" [15:51:04] the problem is that with 2.6.36 the function and the op have different signatures [15:52:42] vfs_statfs now has a struct path * as its first argument. the statfs op stays the same [15:53:48] I don't care that the function and the op have different signatures. The important thing is to tightly bind the behavior we care about to something we can actually test. [15:54:25] If the changes happened at the same time and are sufficiently interdependent, then it's OK to test the "wrong" thing. [15:55:17] I don't suppose anyone's statfs op is exported (well, declared in a header) ? [15:55:32] they didn't happen at the same time.... so, check for a new vfs_statfs, and if we have an old vfs_statfs we can do the old STATFS_TAKES_DENTRY check, right? [15:56:37] hmm, there's a simple_statfs in the current kernel [15:57:13] What do you mean by "old" ? Do the check we were doing before, and do it again with the new declaration; if either passes, we're happy. [15:57:48] That's been there at least since 2.6.10 [15:58:01] and there's alsoa simple_statfs in 2.6.9 So it looks like it might do [15:58:45] I'm not sure I see the need; doing what jhutz describes sounds safer... [15:59:58] I think the best thing to do is go back to a test like the one we had before, but test simple_statfs instead of vfs_statfs. [16:01:14] okay okay [16:01:22] lxr says simple_statfs existed in 2.6.0 [16:01:24] do you disagree? [16:02:29] it looks as good as any other test we do since it existed in 2.6.0 [16:03:00] that's simple enough - seems like the simplest solution. [16:06:13] i can do a patch, unless you were already doing so [16:07:10] if you're talking to me, I'm kinda concentrating on something else at the moment... [16:07:35] if you write something, I can test against the machine I saw the original warning on a little later [16:07:49] ok, i'll push something in a few minutes [16:15:24] change 2975 [17:25:35] --- deason has left [17:26:46] --- deason has become available [19:01:55] --- mdionne has left [20:08:53] --- jaltman has left: Disconnected [20:09:06] --- jaltman has become available [20:23:20] --- abo has left [20:23:39] --- abo has become available [20:44:59] --- deason has left [21:14:04] --- deason has become available [22:00:42] --- deason has left [22:17:11] --- reuteras has become available [23:09:14] --- Russ has left: Disconnected [23:11:55] --- jaltman has left: Disconnected