Re: [PATCH] android: binder: fix type mismatch warning
From: Arnd Bergmann
Date: Mon Sep 18 2017 - 15:49:11 EST
On Mon, Sep 18, 2017 at 6:23 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Mon, Sep 18, 2017 at 05:53:47PM +0200, Greg Kroah-Hartman wrote:
>> > It seems like a legitimate use case of the binder modules, but
>> > now there is a kernel Kconfig option that has to match a user
>> > space binary.
>>
>> So, should we revert that?
>>
>> I don't really know what to suggest here, sorry...
>
> Keep it as is for now, and encourage people to fix it. But we should
> reject any new patch that makes this worse or adds additional ioctls
> that don't follow our normal model.
I would argue we should leave it as non-configurable, but make
a conscious decision which ABI to use for 4.14, as that is going
to be in a the next generation of Android devices:
a) leave the BINDER_CURRENT_PROTOCOL_VERSION==7
interface supported in all 32-bit builds forever, remaining compatible
the ABI that was supported in mainline Linux in all versions until v4.13.
The version 7 interface is incompatible between 32-bit and 64-bit user
space, and there is no compat_ioctl implementation for it, so someone
should fix it by implementing a proper compat_ioctl function.
The current Kconfig comment says that v7 of the ABI is also
incompatible with Android 4.5 and later user space. Can someone
confirm that? The code looks like it's written under the assumption
that user space would dynamically pick between v7 and v8 based
on the return value of ioctl(..., BINDER_VERSION).
We could also add support for switching the ABI dynamically in the
kernel module based on either a module parameter or an ioctl
that a future version of the binder user space can call, to add optional
support for the v8 ABI on 64-bit.
b) Treat the fact that we implemented the v7 binder ABI as a bug,
since real Android uses v8, removing all traces of the v7 code from
the kernel, and requiring users of Android 4.4 and earlier to upgrade
their binder to a version that runs on modern kernels. We can
probably get away with that because
- Neither arm64 nor x86_64 are affected by this change.
- "anbox" would normally only be used on x86_64, but not i386
or arm32
- we probably already lost support for Android 4.4 and earlier due
to other kernel changes
- any arm32 user space that people actually try to run with a
mainline kernel should already support the v8 ABI, and might not
support the v7 ABI at all.
- we don't support v1 through v6 of the interface either.
Arnd