Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 13 Sep 2018 03:07:57 +0100
From:   Al Viro <viro@ZenIV.linux.org.uk>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 01/17] compat_ioctl: add generic_compat_ioctl_ptrarg()
Message-ID: <20180913020757.GP19965@ZenIV.linux.org.uk>
References: <20180912150142.157913-1-arnd@arndb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180912150142.157913-1-arnd@arndb.de>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Sep 12, 2018 at 05:01:02PM +0200, Arnd Bergmann wrote:
> Many drivers have ioctl() handlers that are completely compatible
> between 32-bit and 64-bit architectures, except for the argument
> that is passed down from user space and may have to be passed
> through compat_ptr() in order to become a valid 64-bit pointer.
> 
> Using ".compat_ptr=generic_compat_ioctl_ptrarg" in file operations
> should let us simplify a lot of those drivers to avoid #ifdef
> checks, and convert additional drivers that don't have proper
> compat handling yet.

Just keep in mind that this should *only* be used when all
ioctls implemented in a given instance do take pointers.
Because otherwise you are asking for trouble - e.g. if one of
them takes an u32 used as a bitmap, this will run into trouble
as soon as somebody uses bit 31.  With no visible warnings.

IOW, it shouldn't be used blindly and it should come with big
fat warning.