All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.