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:
>>
en 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
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
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
>> t
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:
>>
t 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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
dj);
>> > - int other_free = global_page_state(NR_FREE_PAGES) - totalreserve_pages;
>> > - int other_file = global_node_page_state(NR_FILE_PAGES) -
>> > -
>> > global_node_page_state(NR_SHMEM) -
>> > -
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 fl
On Wed, Aug 31, 2016 at 6:22 AM, Greg Kroah-Hartman
wrote:
> On Thu, Aug 18, 2016 at 08:00:59PM -0700, Arve Hjønnevåg wrote:
>> On Thu, Aug 18, 2016 at 7:30 PM, ZhaoJunmin Zhao(Junmin)
>> wrote:
>> >
>> >
>> > 在 2016/8/18 23:23, Greg Kroah-Hartman 写道:
On Thu, Aug 18, 2016 at 7:30 PM, ZhaoJunmin Zhao(Junmin)
wrote:
>
>
> 在 2016/8/18 23:23, Greg Kroah-Hartman 写道:
>>
>> On Tue, Aug 16, 2016 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
>>>
>>> On Mon, Aug 15, 2016 at 7:58 AM, Greg Kroah-Hartman
>>>
iption here is accurate. If a process calls execve,
the old vma should be closed (and vma_vm_mm cleared) before the
mm_struct that it belongs too is freed.
--
Arve Hjønnevåg
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
r);
> }
>
> + mmput(proc->vma_vm_mm);
> put_task_struct(proc->tsk);
>
> binder_debug(BINDER_DEBUG_OPEN_CLOSE,
> --
> 2.8.0.rc3.226.g39d4020
>
Does this work? In the past, holding a reference to a task's mm while
the driver is open would
>
> 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
r = BR_FAILED_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
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 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 and 64 bit
>&g
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,
it system, then much 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
18 matches
Mail list logo
