[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <510BF365.2010609@arm.com>
Date: Fri, 01 Feb 2013 16:55:01 +0000
From: Serban Constantinescu <Serban.Constantinescu@....com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel-team@...roid.com" <kernel-team@...roid.com>,
"arve@...roid.com" <arve@...roid.com>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
Dave Butcher <Dave.Butcher@....com>
Subject: Re: [PATCH 1/2] staging: android: ashmem: fix ashmem pin/unpin interface
Hi Greg,
On 01/02/13 16:18, Greg KH wrote:
> On Fri, Feb 01, 2013 at 04:08:00PM +0000, Serban Constantinescu wrote:
>> The values exchanged between kernel and userspace through struct
>> ashmem_pin should be of type size_t. This change won't affect the
>> existing interface but will stand as the basis of 64bit compat layer.
>
> How do you define size_t with a 64bit kernel and a 32bit userspace
> properly? Doesn't this change open up a bunch of problems?
The current ashmem pin/unpin kernel interface uses __u32 to specify the
memory region and length in bytes. However these values should be of
type size_t so that they are able to represent the whole range of
possible values when compiled for a 64bit platform.
Android API uses ashmem driver through libcutils, from where I attach
the following snippet:
<aosp>/system/core/libcutils/ashmem-dev.c
75 int ashmem_pin_region(int fd, size_t offset, size_t len)
76 {
77 struct ashmem_pin pin = { offset, len };
78 return ioctl(fd, ASHMEM_PIN, &pin);
79 }
The kernel changes inline with the userspace usage and do not affect
existing 32bit Android (we have exported the new kernel header, rebuilt
and tested the interface with success).
However this change will affect any 64bit userspace using the current
faulty interface, but there is none that we know of.
Thanks,
Serban Constantinescu
`
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists