From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulrich Drepper Subject: Re: [PATCH 2/2] add f_flags to struct statfs(64) Date: Mon, 28 Jun 2010 12:52:56 -0700 Message-ID: <4C28FD98.1010300@redhat.com> References: <20100626093507.GB26371@lst.de> <60FB0305-A632-4A63-9BD8-DA07CC69B7D7@dilger.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Christoph Hellwig , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Andreas Dilger Return-path: Received: from mx1.redhat.com ([209.132.183.28]:16158 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035Ab0F1TxI (ORCPT ); Mon, 28 Jun 2010 15:53:08 -0400 In-Reply-To: <60FB0305-A632-4A63-9BD8-DA07CC69B7D7@dilger.ca> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/28/2010 11:43 AM, Andreas Dilger wrote: > I would advocate at least an 8-bit magic value, if there is a concern > about this field not always being 0-filled on older kernels, or not > using any ST_VALID flag at all, if it was always zero-filled in the > past. Did anyone go back and check which kernel versions didn't clear the spare fields (if any)? Instead of using a magic number which doesn't provide 100% security in that case and steals a number of bits which might be needed in future I rather see a new syscall. The new {,f}statfs would be an alias for the old one, exactly the same implementation. With this it is much safer t= o check for the new kernel behavior. In future this isn't necessary sinc= e from point on it is guaranteed that the spare bits are zeroed. - --=20 =E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro S= t =E2=9E=A7 Mountain View, CA =E2=9D=96 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwo/ZgACgkQ2ijCOnn/RHSdVQCgzgHQj5A3/MLSYMbxX2xotoye aPsAnRzGEK0pz7LYQ9mIYUHa/upoFuoS =3D3oan -----END PGP SIGNATURE----- -- 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