From: Serban Constantinescu <Serban.Constantinescu@arm.com>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
Android Kernel Team <kernel-team@android.com>,
John Stultz <john.stultz@linaro.org>,
Dave Butcher <Dave.Butcher@arm.com>
Subject: Re: [PATCH v2 6/7] staging: android: binder: fix alignment issues
Date: Thu, 11 Apr 2013 20:02:21 +0100 [thread overview]
Message-ID: <516708BD.3050804@arm.com> (raw)
In-Reply-To: <CAMP5XgdrAkt72Ra8J2ecHexo+UcF7eGiLTj2gEL0mOoxHgL_ig@mail.gmail.com>
On 10/04/13 23:30, Arve Hjønnevåg wrote:
> On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
> <Serban.Constantinescu@arm.com> 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@arm.com> 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.
Most of 64bit compilers will try to align pointers within a structure to
natural boundaries. However all 64bit variants of currently supported
Android architectures can service unaligned accesses(possibly with a
performance degradation compared to an aligned access).
You can take a look at alignment requirements for AArch64 here
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055a/IHI0055A_aapcs64.pdf
chapter 4.
What we are modifying in this patch is the alignment requirements on the
buffer size(as seen above - arbitrary size 4byte aligned) and the
alignment check on offp.
Let's take a look at what offp does. The userspace will write object
references to a buffer using:
>> 820 status_t Parcel::writeObject(const flat_binder_object& val, bool nullMetaData)
>> ...
>> 826 *reinterpret_cast<flat_binder_object*>(mData+mDataPos) = val;
Buffer
|---------------------------------------|val
| |
|->mData |->mDataPos
where mData is the start of the buffer and mDataPos the current position
within the buffer(equivalent to offp in the kernel space). Since the
buffer is guaranteed to be u32 aligned but not u64 aligned the pointer
to flat_binder_object might live on a unaligned boundary(offp will
always be aligned to sizeof(u32) - see Parcel::writeAligned()).
However this will happen only on buffers where at the time we write the
next object reference(val) the buffer cursor(mDataPos) happens not to be
on a multiple of sizeof(void *).
Adding an alignment check in the userspace might be more costly than
servicing the unaligned access(for AArch64 serviced in hardware). Also
we will save some memory by not adding the padding.
On the other hand if instead of writing a pointer we write a 64bit mutex
lock to an unaligned address and than try to read it in the kernel side
things are not guaranteed to be sane. The compiler could make the
assumption that the lock is natural aligned and use load/store exclusive
that will fail on an unaligned address. However for this situation we
can extend the userspace API and add a mutex write primitive like:
> status_t Parcel::writeMutex(mutex lock)
> ...
> *reinterpret_cast<mutex>(ALIGN_CHECK_AND_PAD(mData+mDataPos)) = lock;
I am not aware of any situation where you will have 64bit mutexes passed
in a binder buffer but you would probably know more about this. Since
all writes to the buffer are 32bit aligned a 32bit mutex would not
suffer any alignment issues.
Let me know what are your thoughts about this.
>> 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?
See above.
Thanks for your feedback,
Serban
next prev parent reply other threads:[~2013-04-11 19:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 10:00 [PATCH v2 0/7] Android Binder IPC Fixes Serban Constantinescu
2013-04-09 10:00 ` [PATCH v2 1/7] staging: android: binder: clean-up uint32_t types Serban Constantinescu
2013-04-10 0:11 ` Arve Hjønnevåg
2013-04-10 8:40 ` Serban Constantinescu
2013-04-09 10:00 ` [PATCH v2 2/7] staging: android: binder: replace IOCTL types with user-exportable types Serban Constantinescu
2013-04-10 0:17 ` Arve Hjønnevåg
2013-04-09 10:00 ` [PATCH v2 3/7] staging: android: binder: fix binder interface for 64bit compat layer Serban Constantinescu
2013-04-09 23:48 ` Arve Hjønnevåg
2013-04-10 13:01 ` Serban Constantinescu
2013-04-10 22:12 ` Arve Hjønnevåg
2013-04-11 15:13 ` Serban Constantinescu
2013-04-11 20:38 ` Arve Hjønnevåg
2013-04-09 10:00 ` [PATCH v2 4/7] staging: android: binder: fix BINDER_SET_MAX_THREADS declaration Serban Constantinescu
2013-04-09 23:53 ` Arve Hjønnevåg
2013-04-10 12:37 ` Serban Constantinescu
2013-04-10 21:50 ` Arve Hjønnevåg
2013-04-09 10:00 ` [PATCH v2 5/7] staging: android: binder: fix BC_FREE_BUFFER ioctl declaration Serban Constantinescu
2013-04-09 23:55 ` Arve Hjønnevåg
2013-04-09 10:00 ` [PATCH v2 6/7] staging: android: binder: fix alignment issues Serban Constantinescu
2013-04-09 23:58 ` Arve Hjønnevåg
2013-04-10 16:39 ` Serban Constantinescu
2013-04-10 22:30 ` Arve Hjønnevåg
2013-04-11 19:02 ` Serban Constantinescu [this message]
2013-04-11 21:40 ` Arve Hjønnevåg
2013-04-09 10:00 ` [PATCH v2 7/7] staging: android: binder: replace types with portable ones Serban Constantinescu
2013-04-10 0:09 ` Arve Hjønnevåg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=516708BD.3050804@arm.com \
--to=serban.constantinescu@arm.com \
--cc=Dave.Butcher@arm.com \
--cc=arve@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).