Re: [PATCH 2/2] add f_flags to struct statfs(64)

[Nick Piggin <npiggin@suse.de>]

On Wed, Jul 07, 2010 at 11:06:29AM -0700, Linus Torvalds wrote:
> On Wed, Jul 7, 2010 at 10:55 AM, Miklos Szeredi <miklos@szeredi.hu> 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.

Well we do want to be simple I think, but it's not *totally* just
for dbench performance :) Actually dbench is supposed to be an fs
syscall reply of samba running a file server workload. For one
reason or another, it calls statvfs a lot.

Not sure if anything else is remotely performance critical, but statvfs
is preferred these days for portability, so proper atomicity of f_flags is
nice too.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html