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;
From:   Christian Brauner <christian.brauner@canonical.com>
Date:   Thu, 2 Aug 2018 15:31:20 +0200
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
Message-ID: <20180802133031.GA30612@gmail.com>
References: <20180730143710.14413-1-christian@brauner.io>
 <20180730163452.GE27761@infradead.org>
 <20180730201224.GA1081@mailbox.org>
 <20180730201947.GB12962@bombadil.infradead.org>
 <20180730202840.GA14693@mailbox.org>
 <20180730214108.GE30522@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye"
Content-Disposition: inline
In-Reply-To: <20180730214108.GE30522@ZenIV.linux.org.uk>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--tsOsTdHNUZQcU9Ye
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> > > >=20
> > > > 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 c=
ode
> > > > or come up with something way more complex. If you have any pointer=
 that
> > > > would already help.
> > >=20
> > > 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.
> >=20
> > I try and see if that is possible.
> >=20
> > >=20
> > > And there was really no reason to post each of the four exports as
> > > separate patches.  That just makes review harder on everyone.
> >=20
> > Sorry about that. It usually depends on the preferences of each
> > maintainer how fine-grained such minor changes should be.
>=20
> The fundamental problem here (besides "who the hell thought that this Fin=
e Piece
> Of Software belongs anywhere other than in /dev/null?") is that messing w=
ith
> 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.
>=20
> Exports NAKed, and if brought again they'll get NAKed with extreme prejud=
ice

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

--tsOsTdHNUZQcU9Ye
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE7btrcuORLb1XUhEwjrBW1T7ssS0FAltjB6YACgkQjrBW1T7s
sS0TKRAAk9pHBArc7WIIxgcjZYOnNWp2bef8R3bY31tdoFj8FSjTwxMrc8y3816r
DFLv+JJXN8MNSF3f7O4us3Vcgwg3/OtkDpyhFfAJijk3wco3j01Czp8MCbUjBmlv
MS7t1MGwekjelpjIpZ/e2SbbD3OPXdCHUP+FCL8CTIPFPkzfr47LiL9EdGtfeVDb
cunRAeyLg/SFCRJAA6EeDvLjl4lZIqeWVw+MaJPG7lbbQ4KoXX0H7gVUgWLNj4eu
LjpU7J0MV97WOjuASDEyL4k+Gf6jD8ix0DlpqqaEW+eK9xJouryitZb71dV5Q1wJ
V0Z+WNE7/uls5x4GMC4C+wOK3T6L4VnIN/kZ8uljjfvax+d47xDGbBPokLLcwrF7
HFnD9RDLkiTwMrCp7OQR8x0Q3c+Ch6EhaEFCWfKiCnwqi5GFk8EX/Cd481xCs5+6
1IV471jkwMOEFsdQ1TCREpCiIwEkTnxCkokz9tEkG8F4F2zqal22B9KKYQkDL/Ht
MDm5xTg2XcnbFcnQwZuQmH2y4t1Ylk1g1plnK5/6D6g11VmNi66TrKE150C21fB2
fELDrkNhjVLBcU/b/Z3OU0Os8+id60wG+4NBk5hH9HQNtl1Jy5SBkCKpGQyjTmcc
fWAXOXmcIthocltP8h6do/T3qcdyyHWApyhp2xtlWRSmDYjR1Ek=
=rah/
-----END PGP SIGNATURE-----

--tsOsTdHNUZQcU9Ye--