From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls Date: Wed, 27 Nov 2013 02:15:36 -0800 Message-ID: <20131127101536.GA24697@infradead.org> References: <20131126200559.GH20559@hall.aurel32.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, Robert Edmonds , Rob Browning To: Aurelien Jarno Return-path: Received: from bombadil.infradead.org ([198.137.202.9]:43529 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752705Ab3K0KPj (ORCPT ); Wed, 27 Nov 2013 05:15:39 -0500 Content-Disposition: inline In-Reply-To: <20131126200559.GH20559@hall.aurel32.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Nov 26, 2013 at 09:05:59PM +0100, Aurelien Jarno wrote: > Most of the userland code seems to pass an int to this ioctl, but a few > others (e.g.: bup, libexplain) passes a long. While it doesn't make a > difference on little endian machines, it does make a difference on > 64-bit big endian machines. > > Could you please tell me if I am wrong in my analysis or if there is a > actually real problem? The problem is that as you indeed pointed out the ABI is that an int needs to be passed. The _IOR/_IOW generate a ioctl number based on a few inputs including the type of the argument, which is just passed to sizeof. So the supposedly self-documenting ioctl defintions disagree with the actual ABI. There's nothing that can be fixed in the kernel except for better documenting the actual ABI, and why the ioctl defintion is very misleading in this case. The userspace programs that were mislead by this will need to fixed.