int ret;
> + enum arm_smccc_conduit conduit;
> +
> + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
> + return 0;
> +
> + conduit = arm_smccc_1_1_get_conduit();
If you make this device a child device of the conduit, then you don't
need this here. Other conduits can be added to for instance support
other architectures without adding entries to this enum and modifying
this driver.
--
Arve Hjønnevåg
binder_alloc
> *alloc, int allocate,
> }
> err_no_vma:
> if (mm) {
> - up_write(>mmap_sem);
> + up_read(>mmap_sem);
> mmput(mm);
> }
> return vma ? -ENOMEM : -ESRCH;
> --
> 2.17.0.rc1.321.gba9d0f2565-goog
>
--
Arve Hjønnevåg
up_read(>mmap_sem);
> mmput(mm);
> }
> return 0;
> @@ -321,7 +321,7 @@ static int binder_update_page_range(struct binder_alloc
> *alloc, int allocate,
> }
> err_no_vma:
> if (mm) {
> - up_write(>mmap_sem);
> + up_read(>mmap_sem);
> mmput(mm);
> }
> return vma ? -ENOMEM : -ESRCH;
> --
> 2.17.0.rc1.321.gba9d0f2565-goog
>
--
Arve Hjønnevåg
>>> V2: update comments
>>> ---
>>> drivers/android/binder_alloc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Martijn and Todd, any objections to this patch?
>
> Looks fine to me. Arve, do you remember the rationale for using VM_IOREMAP?
>
I don't remember for sure, but I think it used alloc_vm_area at some
point, and that uses VM_IOREMAP.
--
Arve Hjønnevåg
binder_alloc: binder_alloc_mmap_handler: 15745
>>> 8ce67000-8cf65000 get_vm_area failed -12
>>>
>>> Signed-off-by: Ganesh Mahendran
>>>
>>> V3: update comments
>>> V2: update comments
>>> ---
>>> drivers/android/binder_allo
On Tue, Oct 24, 2017 at 12:28 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Mon, Oct 23, 2017 at 11:18:52AM -0700, Arve Hjønnevåg wrote:
>> On Sat, Oct 21, 2017 at 1:15 AM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On F
On Tue, Oct 24, 2017 at 12:28 AM, Greg Kroah-Hartman
wrote:
> On Mon, Oct 23, 2017 at 11:18:52AM -0700, Arve Hjønnevåg wrote:
>> On Sat, Oct 21, 2017 at 1:15 AM, Greg Kroah-Hartman
>> wrote:
>> > On Fri, Oct 20, 2017 at 08:58:58PM -0400, Sherry Yang wrote:
>>
avoid a potential deadlock between lru lock, task lock and
>> dentry lock, since a thread can be holding the task lock
>> and the dentry lock while trying to acquire the lru lock.
>>
>> Acked-by: Arve Hjønnevåg <a...@android.com>
>> Signed-off-by: Sherry Yang <s
n lru lock, task lock and
>> dentry lock, since a thread can be holding the task lock
>> and the dentry lock while trying to acquire the lru lock.
>>
>> Acked-by: Arve Hjønnevåg
>> Signed-off-by: Sherry Yang
>> ---
>> drivers/android/binder_alloc.c | 22
o.
>
> (Top-posting repaired. Please don't!)
>
> Is it necessary for binder_alloc_free_page() to take a ref on the mm?
> As long as alloc->tsk doesn't exit during binder_alloc_free_page()'s
> execution, that task's reference on the mm should be sufficient to keep
> the mm alive?
>
alloc->tsk can exit during binder_alloc_free_page. We don't hold a
reference to the task's mm struct while we don't actively use it, as
this would prevent the driver from getting closed when a process dies.
--
Arve Hjønnevåg
f on the mm?
> As long as alloc->tsk doesn't exit during binder_alloc_free_page()'s
> execution, that task's reference on the mm should be sufficient to keep
> the mm alive?
>
alloc->tsk can exit during binder_alloc_free_page. We don't hold a
reference to the task's mm struct while we don't actively use it, as
this would prevent the driver from getting closed when a process dies.
--
Arve Hjønnevåg
to
> kernel space?
>
The buffer headers have never been used by user-space. They are
readable by user-space because the content after the header has to be
readable from user-space (and only whole pages can be mapped). It was
simpler to have the header in the same shared region as wel
ever been used by user-space. They are
readable by user-space because the content after the header has to be
readable from user-space (and only whole pages can be mapped). It was
simpler to have the header in the same shared region as well. At the
time this code was written the content of kernel pointers where not
considered secret and available elsewhere anyway (e.g. kernel log,
/proc/kallsyms).
--
Arve Hjønnevåg
On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra <pet...@infradead.org> wrote:
> On Mon, Sep 12, 2016 at 08:44:09PM -0700, Arve Hjønnevåg wrote:
>
>> A previous attempt to fix this problem, changed the lock to use
>> rt_mutex instead of mutex, but this apparen
On Tue, Sep 13, 2016 at 12:32 AM, Peter Zijlstra wrote:
> On Mon, Sep 12, 2016 at 08:44:09PM -0700, Arve Hjønnevåg wrote:
>
>> A previous attempt to fix this problem, changed the lock to use
>> rt_mutex instead of mutex, but this apparently did not work as well as
>&g
On Mon, Sep 12, 2016 at 11:42 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Mon, Sep 12, 2016 at 08:44:09PM -0700, Arve Hjønnevåg wrote:
>> On Sat, Sep 10, 2016 at 10:28 AM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On S
On Mon, Sep 12, 2016 at 11:42 PM, Greg Kroah-Hartman
wrote:
> On Mon, Sep 12, 2016 at 08:44:09PM -0700, Arve Hjønnevåg wrote:
>> On Sat, Sep 10, 2016 at 10:28 AM, Greg Kroah-Hartman
>> wrote:
>> > On Sat, Sep 10, 2016 at 06:37:29PM +0200, Thomas Gleixner wrote:
>>
trigger
this problem, but there are processes that receive work from both high
and low priority threads and could still end up in the same situation.
A previous attempt to fix this problem, changed the lock to use
rt_mutex instead of mutex, but this apparently did not work as well as
this patch. I believe the added overhead was noticeable, and it did
not work when the preempted thread was in a different cgroup (I don't
know if this is still the case).
It would be useful to generic solution to this problem.
> So don't worry, I'm not taking this change :)
>
> thanks,
>
> greg k-h
--
Arve Hjønnevåg
ority threads and could still end up in the same situation.
A previous attempt to fix this problem, changed the lock to use
rt_mutex instead of mutex, but this apparently did not work as well as
this patch. I believe the added overhead was noticeable, and it did
not work when the preempted thread was in a different cgroup (I don't
know if this is still the case).
It would be useful to generic solution to this problem.
> So don't worry, I'm not taking this change :)
>
> thanks,
>
> greg k-h
--
Arve Hjønnevåg
total_swapcache_pages();
>> > + unsigned long nr_free = global_page_state(NR_FREE_PAGES);
>> > + unsigned long nr_file = global_node_page_state(NR_FILE_PAGES);
>> > + unsigned long nr_shmem = global_node_page_state(NR_SHMEM);
>> > + int other_free = nr_free - totalreserve_pages;
>> > + int other_file = nr_file - nr_shmem - total_swapcache_pages();
>> >
>> > if (lowmem_adj_size < array_size)
>> > array_size = lowmem_adj_size;
>> I like it, much easier to follow. Care to resend it in a patch form I
>> can apply it in?
>
> I think the android folk should figure out what the right thing
> to do with the int/unsigned long calculation is first.
>
> Arve? Riley?
>
I think the end result is the same if you store it in an int. If you
store the result in a long it will work better, but I don't know of
anyone using lowmemorykilller on a system with more than 8TB of
memory.
--
Arve Hjønnevåg
global_page_state(NR_FREE_PAGES) - totalreserve_pages;
>> > - int other_file = global_node_page_state(NR_FILE_PAGES) -
>> > -
>> > global_node_page_state(NR_SHMEM) -
>> > - t
out loads of
> testing having happened...
>
> thanks,
>
> greg k-h
There is no alignment requirement on this area unless
cache_is_vipt_aliasing returns true. In that case the area needs to be
aligned with vma->vm_start which is done manually in the code right
after this allocation. If there are no other side effects of changing
this flag this change should be safe, but please run all the tests at
https://android.googlesource.com/platform/frameworks/native/+/master/libs/binder/tests/
to test it.
--
Arve Hjønnevåg
;
> greg k-h
There is no alignment requirement on this area unless
cache_is_vipt_aliasing returns true. In that case the area needs to be
aligned with vma->vm_start which is done manually in the code right
after this allocation. If there are no other side effects of changing
this flag this change should be safe, but please run all the tests at
https://android.googlesource.com/platform/frameworks/native/+/master/libs/binder/tests/
to test it.
--
Arve Hjønnevåg
col and new linux clients use
your rpmb protocol.
>
> Second if it won’t be possible to use the current implementation if the
> storage type change UFS or NVMe anyhow and on the othernad
> I’m not suggesting to kill MMC ioctl, so this won’t be breackages of the
> existing software.
I don't think you need to be compatible with existing Linux user-space
code, but it would be possible by emulating the MMC_IOC_MULTI_CMD
command. You should try to be compatible with existing secure os
interfaces though, as there is no reason for this to be different for
ufs and emmc.
>
> In bottom line I will try to add raw read/write access to RPMB to support
> fine grained access and see if you can work with that.
>
Why not change your code to be compatible with code written against
the existing specs instead? I don't see a need for an interface where
the client has to prepare all the packets defined by the spec except
for one special packet that the kernel will inject.
>
> I really appreciate your feedback.
> Thanks
> Tomas
>
>
>
>
--
Arve Hjønnevåg
r rpmb protocol.
>
> Second if it won’t be possible to use the current implementation if the
> storage type change UFS or NVMe anyhow and on the othernad
> I’m not suggesting to kill MMC ioctl, so this won’t be breackages of the
> existing software.
I don't think you need to be compatible with existing Linux user-space
code, but it would be possible by emulating the MMC_IOC_MULTI_CMD
command. You should try to be compatible with existing secure os
interfaces though, as there is no reason for this to be different for
ufs and emmc.
>
> In bottom line I will try to add raw read/write access to RPMB to support
> fine grained access and see if you can work with that.
>
Why not change your code to be compatible with code written against
the existing specs instead? I don't see a need for an interface where
the client has to prepare all the packets defined by the spec except
for one special packet that the kernel will inject.
>
> I really appreciate your feedback.
> Thanks
> Tomas
>
>
>
>
--
Arve Hjønnevåg
emoving one set of buffer size. I will try to make that
> modification if it helps?
>
No I don't want you to modify the code that runs in the secure OS.
This would require additional code in boot loaders and proxy servers
using the existing MMC_IOC_MULTI_CMD command as they too would have to
interpret the packets to inject RESULT_READ packets.
> Thanks for interest and your review.
> Tomas
>
>
--
Arve Hjønnevåg
t; modification if it helps?
>
No I don't want you to modify the code that runs in the secure OS.
This would require additional code in boot loaders and proxy servers
using the existing MMC_IOC_MULTI_CMD command as they too would have to
interpret the packets to inject RESULT_READ packets.
> Thanks for interest and your review.
> Tomas
>
>
--
Arve Hjønnevåg
et the data it currently passes through
and remove all RESULT_READ packets.
--
Arve Hjønnevåg
tly passes through
and remove all RESULT_READ packets.
--
Arve Hjønnevåg
t at all.
> tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;
> ret = map_vm_area(_area, PAGE_KERNEL, page);
> if (ret) {
> -->8--
>
>
> Regards,
> Amit Pundir
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;
ret = map_vm_area(tmp_area, PAGE_KERNEL, page);
if (ret) {
--8--
Regards,
Amit Pundir
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
> I don't really understand when buffer->data has to be page aligned and
> when not. This code has very few comments.
>
buffer->data never needs to be page aligned. The code above rounds to
page boundaries to allocate new pages as needed.
>730
>731
.
Yes.
regards,
dan carpenter
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
LED_REPLY;
> goto err_binder_get_ref_for_node_failed;
> }
> ref = binder_get_ref_for_node(target_proc, node);
> --
> 1.9.1
Acked-by: Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
;
}
ref = binder_get_ref_for_node(target_proc, node);
--
1.9.1
Acked-by: Arve Hjønnevåg a...@android.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Fri, Feb 21, 2014 at 2:04 PM, John Stultz wrote:
> On 02/21/2014 01:56 PM, Arve Hjønnevåg wrote:
>> On Fri, Feb 21, 2014 at 1:29 PM, John Stultz wrote:
>>> On 02/21/2014 12:59 PM, Arve Hjønnevåg wrote:
>>>> On Fri, Feb 21, 2014 at 12:43 PM, John Stultz
>>
On Fri, Feb 21, 2014 at 1:29 PM, John Stultz wrote:
> On 02/21/2014 12:59 PM, Arve Hjønnevåg wrote:
>> On Fri, Feb 21, 2014 at 12:43 PM, John Stultz wrote:
>>> From: Arve Hjønnevåg
>>>
>>> For 64bit systems we want to use the same binder interface for
On Fri, Feb 21, 2014 at 12:43 PM, John Stultz wrote:
> From: Arve Hjønnevåg
>
> For 64bit systems we want to use the same binder interface for 32bit and
> 64bit processes. Thus the size and the layout of the structures passed
> between the kernel and the userspace has to be the s
On Fri, Feb 21, 2014 at 12:43 PM, John Stultz john.stu...@linaro.org wrote:
From: Arve Hjønnevåg a...@android.com
For 64bit systems we want to use the same binder interface for 32bit and
64bit processes. Thus the size and the layout of the structures passed
between the kernel
On Fri, Feb 21, 2014 at 1:29 PM, John Stultz john.stu...@linaro.org wrote:
On 02/21/2014 12:59 PM, Arve Hjønnevåg wrote:
On Fri, Feb 21, 2014 at 12:43 PM, John Stultz john.stu...@linaro.org wrote:
From: Arve Hjønnevåg a...@android.com
For 64bit systems we want to use the same binder interface
On Fri, Feb 21, 2014 at 2:04 PM, John Stultz john.stu...@linaro.org wrote:
On 02/21/2014 01:56 PM, Arve Hjønnevåg wrote:
On Fri, Feb 21, 2014 at 1:29 PM, John Stultz john.stu...@linaro.org wrote:
On 02/21/2014 12:59 PM, Arve Hjønnevåg wrote:
On Fri, Feb 21, 2014 at 12:43 PM, John Stultz
y. By the time this kernel
is used, the user-space default may have switched to using the 64 bit
interface by default. The android-3.10 kernel currently defaulting to
y since it may get used with a 4.4 android user-space, and because the
32 bit arm kernel is missing the 8 byte get_user variant that it
n
users.
>
> But you added a field to the existing structure, right? I don't really
> remember the patch, it was a few hundred back in my review of stuff
> today, sorry...
>
> greg k-h
The existing structure is not changed. These two commands were defined
with wrong structure t
the binder_handle_cookie struct
so the service manager does not have to define its own version
(libbinder writes one field at a time so it does not use the struct).
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
that it
needs.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Dec 12, 2013 at 12:45 AM, Octavian Purdila
wrote:
> On Thu, Dec 12, 2013 at 1:00 AM, Arve Hjønnevåg wrote:
>> On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
>> wrote:
>>> On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg wrote:
>>>>
>>>>
On Thu, Dec 12, 2013 at 12:45 AM, Octavian Purdila
octavian.purd...@intel.com wrote:
On Thu, Dec 12, 2013 at 1:00 AM, Arve Hjønnevåg a...@android.com wrote:
On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
octavian.purd...@intel.com wrote:
On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg
On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
wrote:
> On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg wrote:
>>
>> Assuming you are talking about a kernel compat layer that translates
>> the flat_binder_object structs as they pass between 32 bit an
On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila
octavian.purd...@intel.com wrote:
On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg a...@android.com wrote:
Assuming you are talking about a kernel compat layer that translates
the flat_binder_object structs as they pass between 32 bit and 64
On Mon, Dec 9, 2013 at 7:01 PM, Octavian Purdila wrote:
> On Thu, Dec 5, 2013 at 4:02 AM, Arve Hjønnevåg wrote:
>> On Wed, Dec 4, 2013 at 2:02 PM, Greg KH wrote:
>>> On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote:
>>>> On Wed, Dec 4, 2013 at 1:43 PM,
On Mon, Dec 9, 2013 at 7:01 PM, Octavian Purdila tavi.purd...@gmail.com wrote:
On Thu, Dec 5, 2013 at 4:02 AM, Arve Hjønnevåg a...@android.com wrote:
On Wed, Dec 4, 2013 at 2:02 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote:
On Wed
of the code
added in this patchset becomes useless (and probably harmful as it
appears to prevent 32 bit processes from communicating with 64 bit
processes).
> Or does this patch series mean that no userspace code is changed? Is
> that a "requirement" here?
>
I don't think we
old 32 bit userspace framework code
on a 64 bit system. I think it is more important to not prevent mixed
mode systems.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
gt;>staging: android: binder: fix binder interface for 64bit compat layer
>>
>> drivers/staging/android/binder.c | 32 -
>> drivers/staging/android/binder.h | 48
>> +++---
>> 2 files changed, 40 insertions(+), 40 deletions(-)
>>
>
>
> --
> Best Regards,
>
> Serban Constantinescu
> PDSW Engineer ARM Ltd.
>
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
__u32 handle; /* remote object */
> };
>
> /* extra data associated with local object */
> @@ -78,7 +78,7 @@ struct binder_write_read {
> /* Use with BINDER_VERSION, driver fills in fields. */
> struct binder_version {
> /*
gt;
> We use "userspace" types since this header will be exported and used by
> the Android filesystem.
>
> The patch does not change in any way the functionality of the binder driver.
>
> Signed-off-by: Serban Constantinescu
> Acked-by: Arve Hjønnevåg
>
id *))) {
> + !IS_ALIGNED(*offp, sizeof(u32))) {
> binder_user_error("%d:%d got transaction with invalid
> offset, %zd\n",
> proc->pid, thread->pid, *offp);
> return_error = BR_FAILED_REPLY;
&g
,
proc-pid, thread-pid, *offp);
return_error = BR_FAILED_REPLY;
--
1.7.9.5
Acked-by: Arve Hjønnevåg a...@android.com
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
interface.
We use userspace types since this header will be exported and used by
the Android filesystem.
The patch does not change in any way the functionality of the binder driver.
Signed-off-by: Serban Constantinescu serban.constantine...@arm.com
Acked-by: Arve Hjønnevåg a...@android.com
cookie */
--
1.7.9.5
Acked-by: Arve Hjønnevåg a...@android.com
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
-
drivers/staging/android/binder.h | 48
+++---
2 files changed, 40 insertions(+), 40 deletions(-)
--
Best Regards,
Serban Constantinescu
PDSW Engineer ARM Ltd.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe
select USB_LIBCOMPOSITE
endchoice
config CRC32
tristate "CRC32/CRC32c functions"
default y
choice
prompt "CRC32 implementation"
depends on CRC32
default CRC32_SLICEBY8
config CRC32_SLICEBY8
bool "Slice by 8 bytes"
endch
default y
choice
prompt CRC32 implementation
depends on CRC32
default CRC32_SLICEBY8
config CRC32_SLICEBY8
bool Slice by 8 bytes
endchoice
---
Signed-off-by: Arve Hjønnevåg a...@android.com
---
scripts/kconfig/confdata.c | 14 ++
scripts/kconfig/expr.h
On Tue, Jun 4, 2013 at 1:54 AM, Serban Constantinescu
wrote:
> On 03/06/13 22:41, Arve Hjønnevåg wrote:
>>
>> On Wed, May 22, 2013 at 3:12 AM, Serban Constantinescu
>> wrote:
>>>
>>> The changes in this patch will fix the binder interface for use on 6
On Tue, Jun 4, 2013 at 1:54 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
On 03/06/13 22:41, Arve Hjønnevåg wrote:
On Wed, May 22, 2013 at 3:12 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
The changes in this patch will fix the binder interface for use
On Mon, Jun 3, 2013 at 8:02 AM, Greg KH wrote:
> On Fri, May 31, 2013 at 04:17:34PM -0700, Arve Hjønnevåg wrote:
>> On Wed, May 22, 2013 at 3:12 AM, Serban Constantinescu
>> wrote:
>> > This change will fix the BINDER_SET_MAX_THREADS ioctl to use __u32
>> > inst
umed; /* 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 rea
*/
> + __s32 handle; /* remote object */
This should be unsigned to match the handle in binder_transaction_data
and other uses in the driver, but it is currently also used to pass
file descriptors. Perhaps this is better (if sou also change size of
the handle in binder_transaction_dat
.
That way you don't have to change the protocol version later.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
consumed by driver */
+ size_t read_size; /* bytes to read */
+ size_t read_consumed; /* bytes consumed by driver */
unsigned long read_buffer;
};
--
1.7.9.5
Acked-by: Arve Hjønnevåg a...@android.com
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line
On Mon, Jun 3, 2013 at 8:02 AM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, May 31, 2013 at 04:17:34PM -0700, Arve Hjønnevåg wrote:
On Wed, May 22, 2013 at 3:12 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
This change will fix the BINDER_SET_MAX_THREADS ioctl to use
t; @@ -2332,7 +2332,7 @@ retry:
> proc->user_buffer_offset;
> tr.data.ptr.offsets = tr.data.ptr.buffer +
> ALIGN(t->buffer->data_size,
> - sizeof(vo
er_driver_command_protocol {
> * void *: ptr to transaction data received on a read
> */
>
> - BC_INCREFS = _IOW('c', 4, int),
> - BC_ACQUIRE = _IOW('c', 5, int),
> - BC_RELEASE = _IOW('c', 6, int),
> - BC_DECREFS = _IOW('c', 7, int),
&
_IOW('b', 5, __u32)
> #defineBINDER_SET_IDLE_PRIORITY_IOW('b', 6, __s32)
> #defineBINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
> #define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
> --
> 1.7.9.5
>
Acked-by: Arve Hjøn
BINDER_SET_IDLE_PRIORITY_IOW('b', 6, __s32)
#defineBINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
#defineBINDER_THREAD_EXIT _IOW('b', 8, __s32)
--
1.7.9.5
Acked-by: Arve Hjønnevåg a...@android.com
--
Arve Hjønnevåg
--
To unsubscribe from this list: send
= _IOW('c', 4, __u32),
+ BC_ACQUIRE = _IOW('c', 5, __u32),
+ BC_RELEASE = _IOW('c', 6, __u32),
+ BC_DECREFS = _IOW('c', 7, __u32),
/*
* int: descriptor
*/
--
1.7.9.5
Acked-by: Arve Hjønnevåg a...@android.com
--
Arve Hjønnevåg
--
To unsubscribe
,
- sizeof(void *));
+ sizeof(u32));
This change should also be removed.
if (put_user(cmd, (uint32_t __user *)ptr))
return -EFAULT;
--
1.7.9.5
--
Arve Hjønnevåg
--
To unsubscribe from
On Tue, Apr 30, 2013 at 1:36 AM, Serban Constantinescu
wrote:
> Hi Arve,
>
>
> On 30/04/13 00:13, Arve Hjønnevåg wrote:
>>
>> On Mon, Apr 29, 2013 at 9:16 AM, Serban Constantinescu
>> wrote:
>>>
>>> Hi all,
>>>
>>> Any feedba
On Tue, Apr 30, 2013 at 1:36 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
Hi Arve,
On 30/04/13 00:13, Arve Hjønnevåg wrote:
On Mon, Apr 29, 2013 at 9:16 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
Hi all,
Any feedback or comments on this patch set
On Mon, Apr 29, 2013 at 9:16 AM, Serban Constantinescu
wrote:
> Hi all,
>
> Any feedback or comments on this patch set?
>
You don't seem to have addressed my feedback on the previous patch set.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubsc
On Mon, Apr 29, 2013 at 9:16 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
Hi all,
Any feedback or comments on this patch set?
You don't seem to have addressed my feedback on the previous patch set.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line
On Thu, Apr 11, 2013 at 12:02 PM, Serban Constantinescu
wrote:
> On 10/04/13 23:30, Arve Hjønnevåg wrote:
>>
>> On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
>> wrote:
>>>
>>> On 10/04/13 00:58, Arve Hjønnevåg wrote:
>>>>
>>>
n 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.
>
OK, but if you are using this change let a 64 bit user-space know that
the driver has been fixed, then this patch needs to go after the
patches that change the structures on 64 bit systems.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
are using this change let a 64 bit user-space know that
the driver has been fixed, then this patch needs to go after the
patches that change the structures on 64 bit systems.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Thu, Apr 11, 2013 at 12:02 PM, Serban Constantinescu
serban.constantine...@arm.com wrote:
On 10/04/13 23:30, Arve Hjønnevåg wrote:
On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
On 10/04/13 00:58, Arve Hjønnevåg wrote:
On Tue, Apr 9, 2013
On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
wrote:
> On 10/04/13 00:58, Arve Hjønnevåg wrote:
>>
>> On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
>> wrote:
>>>
>>> The Android userspace aligns the data written to the binder buffers
On Wed, Apr 10, 2013 at 6:01 AM, Serban Constantinescu
wrote:
> On 10/04/13 00:48, Arve Hjønnevåg wrote:
>>>
>>> diff --git a/drivers/staging/android/binder.c
>>> b/drivers/staging/android/binder.c
>>> index 5794cf6..a2cdd9e 100644
>>> --- a/dr
On Wed, Apr 10, 2013 at 5:37 AM, Serban Constantinescu
wrote:
> On 10/04/13 00:53, Arve Hjønnevåg wrote:
>>
>> On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
>> wrote:
>>>
>>> This change will fix the BINDER_SET_MAX_THREADS ioctl to use __s32
&g
On Wed, Apr 10, 2013 at 5:37 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
On 10/04/13 00:53, Arve Hjønnevåg wrote:
On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
This change will fix the BINDER_SET_MAX_THREADS ioctl to use __s32
On Wed, Apr 10, 2013 at 6:01 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
On 10/04/13 00:48, Arve Hjønnevåg wrote:
diff --git a/drivers/staging/android/binder.c
b/drivers/staging/android/binder.c
index 5794cf6..a2cdd9e 100644
--- a/drivers/staging/android/binder.c
+++ b
On Wed, Apr 10, 2013 at 9:39 AM, Serban Constantinescu
serban.constantine...@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.constantine...@arm.com wrote:
The Android userspace aligns the data written to the binder buffers
.
>
> Signed-off-by: Serban Constantinescu
Acked-by: Arve Hjønnevåg
> ---
> drivers/staging/android/binder.h |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/android/binder.h
> b/drivers/staging/android/bind
On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
wrote:
> uint32_t types are used inconsistently throughout the driver. This patch
> replaces "uint32_t" types with "unsigned int" ones.
>
I don't like this change. You fix the header in a later patch to use
explicit sizes, so it does not make
IOW('c', 7, int),
> + BC_INCREFS = _IOW('c', 4, __s32),
> + BC_ACQUIRE = _IOW('c', 5, __s32),
> + BC_RELEASE = _IOW('c', 6, __s32),
> + BC_DECREFS = _IOW('c', 7, __s32),
These four are actually read as unsigned values, so it would be better
to use __u32 here.
> /*
>
t 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?
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
((size) << _IOC_SIZESHIFT))
>
> and for a 32bit compiler BC_FREE_BUFFER will have the same computed
> value. This change will also ease our work in differentiating
> BC_FREE_BUFFER from COMPAT_BC_FREE_BUFFER.
>
> The change does not affect existing 32bit ABI.
>
> Signed
On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
wrote:
> This change will fix the BINDER_SET_MAX_THREADS ioctl to use __s32
> instead of size_t for setting the max threads. Thus using the same
> handler for 32 and 64bit kernels.
>
> This value is stored internally in struct binder_proc as
d_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
-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.
};
/* This is the current protocol version. */
--
1.7.9.5
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux
On Tue, Apr 9, 2013 at 3:00 AM, Serban Constantinescu
serban.constantine...@arm.com wrote:
This change will fix the BINDER_SET_MAX_THREADS ioctl to use __s32
instead of size_t for setting the max threads. Thus using the same
handler for 32 and 64bit kernels.
This value is stored internally in
1 - 100 of 185 matches
Mail list logo
