From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Browning Subject: Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls Date: Mon, 30 Jun 2014 17:51:08 -0500 Message-ID: <87simm2eqr.fsf@trouble.defaultvalue.org> References: <20131126200559.GH20559@hall.aurel32.net> <20131127101536.GA24697@infradead.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, Robert Edmonds , daryl5@arcor.de To: Christoph Hellwig , Aurelien Jarno Return-path: Received: from defaultvalue.org ([70.85.129.156]:54900 "EHLO defaultvalue.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbaF3W7V (ORCPT ); Mon, 30 Jun 2014 18:59:21 -0400 In-Reply-To: <20131127101536.GA24697@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Christoph Hellwig writes: > 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. So we haven't delved deeply yet, but here's a presumably little-endian, 64-bit system where using an int with FS_IOC_GETFLAGS appears to corrupt the stack: https://groups.google.com/d/msg/bup-list/y4CW6Ib7XUk/sCy7AUHhiKYJ and here's the relevant call: https://github.com/bup/bup/blob/0e0b5324699342601ce1b9a97c0a2e1faf6fe7ff/lib/bup/_helpers.c#L830 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4