linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 3/7] staging: android: binder: fix binder interface for 64bit compat layer
Date: Thu, 11 Apr 2013 16:13:24 +0100	[thread overview]
Message-ID: <5166D314.1090508@arm.com> (raw)
In-Reply-To: <CAMP5XgcvwxWkQV3BJyMz+JSSFRmMj_1a+q_t9htPZ6ZvGd5foQ@mail.gmail.com>

On 10/04/13 23:12, Arve Hjønnevåg wrote:
>>>> struct flat_binder_object {
>>>> /* 8 bytes for large_flat_header. */
>>>> - unsigned long type;
>>>> - unsigned long flags;
>>>> + __u32 type;
>>>> + __u32 flags;
>>>>
>>>> /* 8 bytes of data. */
>>>> union {
>>>> void __user *binder; /* local object */
>>>> - signed long handle; /* remote object */
>>>> + __s32 handle; /* remote object */
>>>
>>>
>>> Why limit the handle to 32 bits when the pointer that it shares
>>> storage with need to be 64 bit on 64 bit systems?
>>
>>
>> Here I have mirrored the type being passed in handle - a file
>> descriptor(when type == BINDER_TYPE_FD) or a handle - 32bit(when type ==
>> BINDER_TYPE_HANDLE). This will avoid some casting when handle is used inside
>> the kernel/userspace(as 32bit value on 64bit systems). However this change
>> does not limit the extension of the API since we can read the value as 64bit
>> - binder(on 64bit systems).
>>
>> I can remove this change if you consider that is the better solution.
>>
>
> I was asking if we should just use 64 bit handles on 64 bit systems,
> not adding casts. It would require another union member for a file
> descriptor however.

I will leave this handle as __s32 for this patch set but I will take a 
look into what and if we need to change this for a 64bit system. From a 
top level perspective(a look at binder_*_ref() functions and the 
userspace equivalent) this should work fine as 32bit.

>>
>>>> };
>>>>
>>>> /* extra data associated with local object */
>>>> @@ -67,18 +67,18 @@ struct flat_binder_object {
>>>> */
>>>>
>>>> struct binder_write_read {
>>>> - signed long write_size; /* bytes to write */
>>>> - signed long write_consumed; /* bytes consumed by driver */
>>>> + size_t write_size; /* bytes to write */
>>>> + size_t write_consumed; /* bytes consumed by driver */
>>>> unsigned long write_buffer;
>>>> - signed long read_size; /* bytes to read */
>>>> - signed long read_consumed; /* bytes consumed by driver */
>>>> + size_t read_size; /* bytes to read */
>>>> + size_t read_consumed; /* bytes consumed by driver */
>>>
>>>
>>> What is this change for? You changed from a signed type to an unsigned
>>> type which seems unrelated to adding 64 bit support.
>>
>>
>> See above explanation for binder_thread_write() change, I will break this
>> into its own patch.
>>
>>
>>>> unsigned long read_buffer;
>>>> };
>>>>
>>>> /* Use with BINDER_VERSION, driver fills in fields. */
>>>> struct binder_version {
>>>> /* driver protocol version -- increment with incompatible change */
>>>> - signed long protocol_version;
>>>> + __s32 protocol_version;
>>>
>>>
>>> How does user-space know if it should use 32 bit or 64 bit pointers.
>>> Without this change, the BINDER_VERSION ioctl would only match when
>>> the size of long matches.
>>
>>
>> The userspace can check the values returned by uname(). That will determine
>> if the kernel is 32 or 64bit and depending on this select what binder
>> structures to use. Next a BINDER_VERSION ioctl will fail on 64bit kernels
>> using protocol_version as 64bit signed long(that is old kernel versions with
>> no 64bit support).
>>
>> Leaving this value as signed long would mean that older versions of the
>> binder(without 64bit support) will pass the check. Furthermore the protocol
>> version will probably never exceed the values that could be represented on
>> 32bit. It will also mean that BINDER_VERSION will have a different
>> userspace/kernel handler for 64/32 systems.
>>
>> Let me know what are your thoughts related to these changes,
>> Thanks for your feedback,
>> Serban
>>
>
> I think user-space should get the binder pointer size from the binder
> driver, not elsewhere. Since the current driver does not appear to be
> functional on a 64 bit system, I think adding an ioctl to get the
> size, or encoding it into the binder version (use an unsigned type if
> you do this), would be best.

I will think about the best way of getting the pointer size and add it 
to the patch set for binder compat. For this patch set I will only 
modify the protocol_version from long to __s32.

Thanks for your feedback,
Serban


  reply	other threads:[~2013-04-11 15:13 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 [this message]
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
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=5166D314.1090508@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).