I took the time to look at what else is different between common and
upstream, and just sent 3 patches to LKML to reconcile. One of the 3
fixes this particular problem.
On Thu, Jul 27, 2017 at 3:42 PM, Amit Pundir wrote:
> On 27 July 2017 at 18:53, Greg Kroah-Hartman
I took the time to look at what else is different between common and
upstream, and just sent 3 patches to LKML to reconcile. One of the 3
fixes this particular problem.
On Thu, Jul 27, 2017 at 3:42 PM, Amit Pundir wrote:
> On 27 July 2017 at 18:53, Greg Kroah-Hartman
> wrote:
>> On Thu, Jul
On 27 July 2017 at 18:53, Greg Kroah-Hartman wrote:
> On Thu, Jul 27, 2017 at 02:38:30PM +0530, Amit Pundir wrote:
>> Hi,
>>
>> On 25 July 2017 at 14:43, Martijn Coenen wrote:
>> > Hi John,
>> >
>> > On Mon, Jul 24, 2017 at 11:07 PM, John Stultz
On 27 July 2017 at 18:53, Greg Kroah-Hartman wrote:
> On Thu, Jul 27, 2017 at 02:38:30PM +0530, Amit Pundir wrote:
>> Hi,
>>
>> On 25 July 2017 at 14:43, Martijn Coenen wrote:
>> > Hi John,
>> >
>> > On Mon, Jul 24, 2017 at 11:07 PM, John Stultz
>> > wrote:
>> >>
>> >> 12-31 16:00:36.632 2518
Looks like this assignment somehow went missing in the upstream version:
proc->vma_vm_mm = current->group_leader->mm;
which probably causes us to bail out here in
binder_update_page_range() because proc->vma_vm_mm is NULL:
if (vma && mm != proc->vma_vm_mm) {
pr_err("%d:
Looks like this assignment somehow went missing in the upstream version:
proc->vma_vm_mm = current->group_leader->mm;
which probably causes us to bail out here in
binder_update_page_range() because proc->vma_vm_mm is NULL:
if (vma && mm != proc->vma_vm_mm) {
pr_err("%d:
On Thu, Jul 27, 2017 at 02:38:30PM +0530, Amit Pundir wrote:
> Hi,
>
> On 25 July 2017 at 14:43, Martijn Coenen wrote:
> > Hi John,
> >
> > On Mon, Jul 24, 2017 at 11:07 PM, John Stultz
> > wrote:
> >>
> >> 12-31 16:00:36.632 2518 2584 E
On Thu, Jul 27, 2017 at 02:38:30PM +0530, Amit Pundir wrote:
> Hi,
>
> On 25 July 2017 at 14:43, Martijn Coenen wrote:
> > Hi John,
> >
> > On Mon, Jul 24, 2017 at 11:07 PM, John Stultz
> > wrote:
> >>
> >> 12-31 16:00:36.632 2518 2584 E hw-ProcessState: Using /dev/hwbinder
> >> failed:
Hi,
On 25 July 2017 at 14:43, Martijn Coenen wrote:
> Hi John,
>
> On Mon, Jul 24, 2017 at 11:07 PM, John Stultz wrote:
>>
>> 12-31 16:00:36.632 2518 2584 E hw-ProcessState: Using /dev/hwbinder
>> failed: unable to mmap transaction memory.
>
> This
Hi,
On 25 July 2017 at 14:43, Martijn Coenen wrote:
> Hi John,
>
> On Mon, Jul 24, 2017 at 11:07 PM, John Stultz wrote:
>>
>> 12-31 16:00:36.632 2518 2584 E hw-ProcessState: Using /dev/hwbinder
>> failed: unable to mmap transaction memory.
>
> This doesn't look right. Is there anything in the
Hi John,
On Mon, Jul 24, 2017 at 11:07 PM, John Stultz wrote:
>
> 12-31 16:00:36.632 2518 2584 E hw-ProcessState: Using /dev/hwbinder
> failed: unable to mmap transaction memory.
This doesn't look right. Is there anything in the kernel log?
> 12-31 16:00:36.632 2518
Hi John,
On Mon, Jul 24, 2017 at 11:07 PM, John Stultz wrote:
>
> 12-31 16:00:36.632 2518 2584 E hw-ProcessState: Using /dev/hwbinder
> failed: unable to mmap transaction memory.
This doesn't look right. Is there anything in the kernel log?
> 12-31 16:00:36.632 2518 2566 D bt_hci :
On Mon, Jul 24, 2017 at 2:23 PM, Greg Kroah-Hartman
wrote:
> On Mon, Jul 24, 2017 at 02:00:45PM -0700, John Stultz wrote:
>> On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
>> > The binder allocator assumes that the thread that
>> > called
On Mon, Jul 24, 2017 at 2:23 PM, Greg Kroah-Hartman
wrote:
> On Mon, Jul 24, 2017 at 02:00:45PM -0700, John Stultz wrote:
>> On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
>> > The binder allocator assumes that the thread that
>> > called binder_open will never die for the lifetime of
>> >
On Mon, Jul 24, 2017 at 02:00:45PM -0700, John Stultz wrote:
> On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
> > The binder allocator assumes that the thread that
> > called binder_open will never die for the lifetime of
> > that proc. That thread is normally the
On Mon, Jul 24, 2017 at 02:00:45PM -0700, John Stultz wrote:
> On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
> > The binder allocator assumes that the thread that
> > called binder_open will never die for the lifetime of
> > that proc. That thread is normally the group_leader,
> > however it
On Mon, Jul 24, 2017 at 2:00 PM, John Stultz wrote:
> On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
>> The binder allocator assumes that the thread that
>> called binder_open will never die for the lifetime of
>> that proc. That thread is normally
On Mon, Jul 24, 2017 at 2:00 PM, John Stultz wrote:
> On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
>> The binder allocator assumes that the thread that
>> called binder_open will never die for the lifetime of
>> that proc. That thread is normally the group_leader,
>> however it may not be.
On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
> The binder allocator assumes that the thread that
> called binder_open will never die for the lifetime of
> that proc. That thread is normally the group_leader,
> however it may not be. Use the group_leader instead
> of
On Thu, Jun 29, 2017 at 12:01 PM, Todd Kjos wrote:
> The binder allocator assumes that the thread that
> called binder_open will never die for the lifetime of
> that proc. That thread is normally the group_leader,
> however it may not be. Use the group_leader instead
> of current.
>
>
On Fri, Jul 07, 2017 at 11:23:16AM -0700, Todd Kjos wrote:
> I suspect there won't be a respin. I'll ping you later if you don't
> remember it yourself ;)
Ok, not a problem, I can't do anything with these until after 4.13-rc1
is out, so it will be at least a week or so until I get to them...
On Fri, Jul 07, 2017 at 11:23:16AM -0700, Todd Kjos wrote:
> I suspect there won't be a respin. I'll ping you later if you don't
> remember it yourself ;)
Ok, not a problem, I can't do anything with these until after 4.13-rc1
is out, so it will be at least a week or so until I get to them...
I suspect there won't be a respin. I'll ping you later if you don't
remember it yourself ;)
On Wed, Jul 5, 2017 at 11:47 AM, Greg KH wrote:
> On Wed, Jul 05, 2017 at 09:13:16AM -0700, Todd Kjos wrote:
>> Yes, this one back to 4.4. 01/37 should go to 4.9 (its not in
I suspect there won't be a respin. I'll ping you later if you don't
remember it yourself ;)
On Wed, Jul 5, 2017 at 11:47 AM, Greg KH wrote:
> On Wed, Jul 05, 2017 at 09:13:16AM -0700, Todd Kjos wrote:
>> Yes, this one back to 4.4. 01/37 should go to 4.9 (its not in 4.4).
>
> Great, if this gets
On Wed, Jul 05, 2017 at 09:13:16AM -0700, Todd Kjos wrote:
> Yes, this one back to 4.4. 01/37 should go to 4.9 (its not in 4.4).
Great, if this gets a respin, can you add it? If not, I'll try to
remember it :)
thanks,
greg k-h
On Wed, Jul 05, 2017 at 09:13:16AM -0700, Todd Kjos wrote:
> Yes, this one back to 4.4. 01/37 should go to 4.9 (its not in 4.4).
Great, if this gets a respin, can you add it? If not, I'll try to
remember it :)
thanks,
greg k-h
On Thu, Jun 29, 2017 at 12:01:36PM -0700, Todd Kjos wrote:
> The binder allocator assumes that the thread that
> called binder_open will never die for the lifetime of
> that proc. That thread is normally the group_leader,
> however it may not be. Use the group_leader instead
> of current.
>
>
On Thu, Jun 29, 2017 at 12:01:36PM -0700, Todd Kjos wrote:
> The binder allocator assumes that the thread that
> called binder_open will never die for the lifetime of
> that proc. That thread is normally the group_leader,
> however it may not be. Use the group_leader instead
> of current.
>
>
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Signed-off-by: Todd Kjos
---
drivers/android/binder.c |
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Signed-off-by: Todd Kjos
---
drivers/android/binder.c | 4 ++--
1 file
30 matches
Mail list logo