Re: [PATCH v2 6/7] staging: android: binder: fix alignment issues

[Arve Hjønnevåg]

On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
<Serban.Constantinescu@xxxxxxx> wrote:
> On 10/04/13 00:58, Arve Hjønnevåg wrote:
>>
>> On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
>> <serban.constantinescu@xxxxxxx> wrote:
>>>
>>> The Android userspace aligns the data written to the binder buffers to
>>> 4bytes. Thus for 32bit platforms or 64bit platforms running an 32bit
>>> Android userspace we can have a buffer looking like this:
>>>
>>> platform    buffer(binder_cmd   pointer)      size
>>> 32/32                 32b         32b          8B
>>> 64/32                 32b         64b          12B
>>> 64/64                 32b         64b          12B
>>>
>>> Thus the kernel needs to check that the buffer size is aligned to 4bytes
>>> not to (void *) that will be 8bytes on 64bit machines.
>>>
>>> The change does not affect existing 32bit ABI.
>>>
>>
>> Do we not want the pointers to be 8 byte aligned on 64bit platforms?
>
>
> No since here we do not align pointers we align binder_buffers and offsets
> in a buffer.
>

Do any 64 bit systems align pointers in a struct to 8 bytes? If so, we
should keep the start address of the struct 8 byte aligned as well.

> Let's assume that from the userspace we receive a sequence of BC_INCREFS and
> BC_FREE_BUFFER. According to their definitions the buffer would look like:
>
> Buffer:
> [addr]          [element]
> 0               BC_INCREFS
> 4               __u32
> 8               BC_FREE_BUFFER
> 12              void *        //(8 bytes for 64bit or 4 bytes for 32bit)
>
> Thus the data_size(sizeof(Buffer)) will be 20 bytes for 64bit systems(4bytes
> aligned). Same explanation for offp where it represents the offset form the
> start of the buffer to a flat_binder_object(for example here the offset to
> void* - 12bytes).
>

Does this work on every 64 bit system?

--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/