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@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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
