On Wed, Jul 7, 2010 at 10:55 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> 1.0 - doesn't touch spare fields
> 1.2.13 - doesn't touch spare fields
> 2.0.40 - copies spare fields from uninitialized kernel stack
> 2.2.26 - copies spare fields from uninitialized kernel stack
> 2.4 onward - zeroes spare fields
I think at least some of the compat_ functions don't zero the fields
even now (the kstatfs struct, yes, but then don't copy them to user
space).
As to any uninitialized kernel stack copying, we really don't even
want to care. Not only are those ancient kernels (and nobody is going
to upgrade glibc if they haven't upgraded the kernel), but it's
clearly a kernel bug, and the potential "wrong f_flags" problem is way
smaller than the "leaks kernel data" problem.
Not that anybody even uses statvfs(). The first google hit on
statvfs() I found was somebody implementing a compatibility statfs()
on top of it, and obviously ignoring any f_flags field. So the only
reason this is even an issue in the first place is just the tbench
performance issue.
In other words: NOBODY CARES. It's that simple. So please, guys - just
do the obvious thing, or shut the h*ll up about it. There is _no_
reason to care in the least about any of this.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
