From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [PATCH 2/2] add f_flags to struct statfs(64) Date: Thu, 8 Jul 2010 04:50:32 +1000 Message-ID: <20100707185032.GH9263@laptop> References: <20100707165325.GB12557@lst.de> <4C34B53A.6060408@redhat.com> <20100707173311.GA14608@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Miklos Szeredi , Christoph Hellwig , drepper@redhat.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Linus Torvalds Return-path: Received: from cantor2.suse.de ([195.135.220.15]:33829 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753746Ab0GGSuh (ORCPT ); Wed, 7 Jul 2010 14:50:37 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jul 07, 2010 at 11:06:29AM -0700, Linus Torvalds wrote: > On Wed, Jul 7, 2010 at 10:55 AM, Miklos Szeredi w= rote: > > > > 1.0 =A0 =A0 - doesn't touch spare fields > > 1.2.13 =A0- doesn't touch spare fields > > 2.0.40 =A0- copies spare fields from uninitialized kernel stack > > 2.2.26 =A0- copies spare fields from uninitialized kernel stack > > 2.4 onward - zeroes spare fields >=20 > 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). >=20 > 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 wa= y > smaller than the "leaks kernel data" problem. >=20 > 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. >=20 > In other words: NOBODY CARES. It's that simple. So please, guys - jus= t > 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