Re: [PATCH 12/14] staging: binder: Fix ABI for 64bit Android

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Feb 18, 2014 at 04:08:20PM -0800, Arve Hjønnevåg wrote:
> On Tue, Feb 18, 2014 at 12:32 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Tue, Feb 18, 2014 at 12:02:07PM -0800, John Stultz wrote:
> >> On Tue, Feb 18, 2014 at 11:49 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> > On Tue, Feb 18, 2014 at 11:30:26AM -0800, John Stultz wrote:
> >> >> On Tue, Feb 18, 2014 at 11:08 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> > On Mon, Feb 17, 2014 at 01:58:40PM -0800, John Stultz wrote:
> >> >> >> From: Serban Constantinescu <serban.constantinescu@arm.com>
> >> >> >>
> >> >> >> This patch fixes the ABI for 64bit Android userspace.
> >> >> >> BC_REQUEST_DEATH_NOTIFICATION and BC_CLEAR_DEATH_NOTIFICATION claim
> >> >> >> to be using struct binder_ptr_cookie, but they are using a 32bit handle
> >> >> >> and a pointer.
> >> >> >>
> >> >> >> On 32bit systems the payload size is the same as the size of struct
> >> >> >> binder_ptr_cookie, however for 64bit systems this will differ. This
> >> >> >> patch adds struct binder_handle_cookie that fixes this issue for 64bit
> >> >> >> Android.
> >> >> >>
> >> >> >> Since there are no 64bit users of this interface that we know of this
> >> >> >> change should not affect any existing systems.
> >> >> >
> >> >> > But you are changing the ioctl structures here, what is that going to
> >> >> > cause with old programs?
> >> >>
> >> >> So I'd be glad for Serban or Arve to clarify, but my understanding
> >> >> (and as is described in the commit message) is that the assumption is
> >> >> there are no 64bit binder users at this point, and the ioctl structure
> >> >> changes are made such that existing 32bit applications are unaffected.
> >> >
> >> > How does changing the structure size, and contents, not affect any
> >> > applications or the kernel code?  What am I missing here?
> >>
> >> On 32bit pointers and ints are the same size? (Years ago I sat through
> >> your presentation on this, so I'm worried I'm missing something here
> >> :)
> >>
> >> struct binder_ptr_cookie {
> >> void *ptr;
> >> void *cookie;
> >> };
> >>
> >> struct binder_handle_cookie {
> >> __u32 handle;
> >> void *cookie;
> >> } __attribute__((packed));
> >>
> >>
> >> On 32bit systems these are the same size.  Now on 64bit systems, this
> >> changes things, and would break users, but the assumption here is
> >> there are no pre-existing 64bit binder users.
> >
> > But you added a field to the existing structure, right?  I don't really
> > remember the patch, it was a few hundred back in my review of stuff
> > today, sorry...
> >
> > greg k-h
> 
> The existing structure is not changed. These two commands were defined
> with wrong structure that did not match the code. Since a binder
> pointer and handle are the same size on 32 bit systems, this change
> does not affect them. On 64 bit systems, the ioctl number does change,
> but these systems need the next patch to run 32 bit processes anyway,
> so I don't expect anyone to ship a system without this change. The
> main purpose of this patch is to add the binder_handle_cookie struct
> so the service manager does not have to define its own version
> (libbinder writes one field at a time so it does not use the struct).

Ah, ok, that makes more sense, can someone put it in the changelog
information so that I don't have to reject the patch for the same reason
again?

thanks,

greg k-h