From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls Date: Fri, 30 Jan 2009 17:14:23 -0800 Message-ID: <20090130171423.f99c88d0.akpm@linux-foundation.org> References: <4980C71F.1010804@ankitjain.org> <20090130162252.7bf9c1f4.akpm@linux-foundation.org> <200901310138.34164.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ankit Jain , viro@zeniv.linux.org.uk, hch@infradead.org, linux-fsdevel@vger.kernel.org, mfasheh@suse.com, joel.becker@oracle.com, ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com To: Arnd Bergmann Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:37225 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbZAaBO5 (ORCPT ); Fri, 30 Jan 2009 20:14:57 -0500 In-Reply-To: <200901310138.34164.arnd@arndb.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, 31 Jan 2009 01:38:32 +0100 Arnd Bergmann wrote: > On Saturday 31 January 2009, Andrew Morton wrote: > > On Thu, 29 Jan 2009 02:29:11 +0530 Ankit Jain wrote: > > > +struct space_resv { > > > + __s16 l_type; > > > + __s16 l_whence; > > > + __s64 l_start; > > > + __s64 l_len; /* len == 0 means until end of file */ > > > + __s32 l_sysid; > > > + __u32 l_pid; > > > + __s32 l_pad[4]; /* reserve area */ > > > +}; > > > + > > > +#define F_IOC_RESVSP _IOW('X', 40, struct space_resv) > > > +#define F_IOC_RESVSP64 _IOW('X', 42, struct space_resv) > > > > Are we sure that the aligment of l_start will be reliably the same > > across all compilers and versions thereof for all time? > > On x86, the alignment differs between 32 and 64 bit, otherwise it's ok. Is this written in a standard somewhere? Is it guaranteed? If some (perhaps non-gcc) compiler were to lay this out differently (perhaps with suitable command-line options) then that's liveable with - as long as the kernel never changes the layout. Of course it would be better to avoid this if poss. The other potential issue with a structure like this is that there's a risk that it will lead us to copy four bytes of uninitialised kernel memory out to userspace. IOW, it seems a generally bad idea to rely upon compiler-added padding for this sort of thing. > XFS handles the conversion for compat_ioctl in > fs/xfs/linux-2.6/xfs_ioctl32.c. If this becomes a generic file ioctl, > the conversion code should be moved to fs/compat_ioctl.c.