Re: [RFC PATCH 0/4] file: export functions for binder module

From: Christian Brauner <christian.brauner@canonical.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christian Brauner <christian@brauner.io>,
	Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	arve@android.com, tkjos@android.com, maco@android.com,
	rlove@google.com, ben@decadent.org.uk
Subject: Re: [RFC PATCH 0/4] file: export functions for binder module
Date: Thu, 2 Aug 2018 15:31:20 +0200	[thread overview]
Message-ID: <20180802133031.GA30612@gmail.com> (raw)
In-Reply-To: <20180730214108.GE30522@ZenIV.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

On Mon, Jul 30, 2018 at 10:41:09PM +0100, Al Viro wrote:
> On Mon, Jul 30, 2018 at 10:28:40PM +0200, Christian Brauner wrote:
> > On Mon, Jul 30, 2018 at 01:19:47PM -0700, Matthew Wilcox wrote:
> > > On Mon, Jul 30, 2018 at 10:12:24PM +0200, Christian Brauner wrote:
> > > > > I don't expect this patch to be mergeable but rather to kick-off a
> > > > > discussion if we can either simply export them as they are or how we can
> > > > > get supportable exports that allow access to struct files_struct.
> > > > 
> > > > Maybe that wasn't obvious from the first message. Is there any way we
> > > > can come up with a way to have versions of these functions that you
> > > > would be fine with exporting?
> > > > The point is that otherwise we would have to either duplicate the code
> > > > or come up with something way more complex. If you have any pointer that
> > > > would already help.
> > > 
> > > He said in the first reply this should probably be using an anonfd.
> > > If you do that, I think all four of these exports go away.
> > 
> > I try and see if that is possible.
> > 
> > > 
> > > And there was really no reason to post each of the four exports as
> > > separate patches.  That just makes review harder on everyone.
> > 
> > Sorry about that. It usually depends on the preferences of each
> > maintainer how fine-grained such minor changes should be.
> 
> The fundamental problem here (besides "who the hell thought that this Fine Piece
> Of Software belongs anywhere other than in /dev/null?") is that messing with
> other's descriptor table is Fucking Wrong(tm).  It's not going to become
> a general-purpose interface.  That kludge is just that - a kludge caused by
> atrocious API design.
> 
> Exports NAKed, and if brought again they'll get NAKed with extreme prejudice

That's fair. When this discussion of turning them into modules was
started it was expected that this would never fly as is. The question
was whether there's any way for binder to touch struct_files of another
process directly at all. Now we know, there isn't. What I was hoping for
is that this would cause a redesign that avoids touching these helpers.
There's an effort from the Android folks now, which is good!

Thanks!
Christian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]