From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f193.google.com ([74.125.82.193]:46893 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754120AbeFKHTC (ORCPT ); Mon, 11 Jun 2018 03:19:02 -0400 Received: by mail-ot0-f193.google.com with SMTP id q1-v6so22580888oth.13 for ; Mon, 11 Jun 2018 00:19:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180610045657.GM30522@ZenIV.linux.org.uk> References: <20180529144339.16538-1-mszeredi@redhat.com> <20180529144339.16538-8-mszeredi@redhat.com> <20180604084904.GF11333@infradead.org> <20180610045657.GM30522@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Mon, 11 Jun 2018 09:19:01 +0200 Message-ID: Subject: Re: [PATCH 07/39] vfs: export vfs_ioctl() to modules To: Al Viro Cc: Christoph Hellwig , Miklos Szeredi , overlayfs , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jun 10, 2018 at 6:57 AM, Al Viro wrote: > On Mon, Jun 04, 2018 at 01:49:04AM -0700, Christoph Hellwig wrote: >> On Tue, May 29, 2018 at 04:43:07PM +0200, Miklos Szeredi wrote: >> > This is needed by the stacked ioctl implementation in overlayfs. >> >> EXPORT_SYMBOL_GPL for exporting random internals, please. Same >> for any following patches. > > *blink* > > Christoph, get real and RTFS - vfs_ioctl() simply calls ->unlocked_ioctl(); > all there is to it. > > This isn't even a case of "using that function establishes that the > caller is a derived work" - *anyone* who can see definition of > file_operations can bloody well open-code it. There isn't anything > establishing derivation here. > > Hell, it could've been a static inline in include/linux/fs.h and it would > neither differ from many other inlines in there nor need an export at all. > > This is really getting close to lxo-worthy levels of bogosity... > > More interesting question is why do we want to pass those ioctls to layers > in the first place, especially if it's something with different availability > (or, worse yet, argument layouts) before and after copyup. We don't. Obviously need to make sure to only ever do ioctl's in overlayfs that have a common definition across filesystems. Not a lot of those, luckily... Thanks, Miklos