Android Binder Issue

Android Binder Issue

[David Legault]

Hello,

I'm trying to debug an issue I'm encountering on kernel 3.4 in the android
binder.
Basically in the function binder_update_page_range it allocates a page. If
I
understand correctly the next part, it maps this page_addr to the page in
kernel
space and then maps the user process addr to the same page.

http://lxr.free-electrons.com/source/drivers/staging/android/binder.c?v=3.4#L611

If I attempt to use virt_to_head_page(page_addr) after all this is
accomplished, I
should get back the page that was just allocated and mapped, but that's not
what
I observe on my system as seen in the log below.

[   20.960786] (   25.557586) binder_open: 219:219
[   20.960827] (   25.557617) binder_ioctl: 219:219 c0046209 be9a7938
[   20.960841] (   25.557617) binder_ioctl: 219:219 40046205 be9a793c
[   20.960857] (   25.557647) binder_mmap: 219 b6c02000-b6d00000 (1016 K)
vma 200071 pagep 79f
[   20.960907] (   25.557708) binder: 219: allocate pages cb300000-cb301000
*** binder allocated page here (nil == first_page value)
[   20.960922] (   25.557708) binder: page_alloc cd958238    (nil)
*** dump of the page
[   20.960931] (   25.557708) page:cd958238 count:1 mapcount:0 mapping:
(nil) index:0x0
[   20.960939] (   25.557739) page flags: 0x0()
*** first attempt of virt_to_head_page(page_addr) before kernel mapping +
dump of returned page
*** which shows it's uninitialized  (aaaaaaaa = first_page value)
[   20.960947] (   25.557739) virt_to_head_page cd392c00
[   20.960955] (   25.557739) compound_head_by_tail cd392c00 aaaaaaaa
[   20.960965] (   25.557769) page:cd392c00 count:-1431655766
mapcount:-1431655765 mapping:aaaaaaaa index:0xaaaaaaaa
[   20.960973] (   25.557769) page flags:
0xaaaaaaaa(error|uptodate|lru|slab|arch_1|private|writeback|tail|mappedtodisk|swapbacked|mlocked)
[   20.960981] (   25.557769) virt_to_head_page cd9681bc
[   20.960997] (   25.557800) virt_to_head_page cd967c1c
*** before kernel + user space mapping calls
[   20.961551] (   25.558349) binder: addr cb300000 page aaaaaaaa
*** after kernel + user space mapping calls - dump allocated page again
[   20.961566] (   25.558349) page:cd958238 count:2 mapcount:1 mapping:
(nil) index:0x0
[   20.961574] (   25.558380) page flags: 0x200(arch_1)
*** second attempt of virt_to_head_page(page_addr) expecting
*** that allocated page above would be mapped to this address
[   20.961584] (   25.558380) binder: addr cb300000 page aaaaaaaa
[   20.961595] (   25.558380) binder: 219: add free buffer, size 1040344,
at cb300000
[   20.961605] (   25.558410) binder_mmap: 219 b6c02000-b6d00000 maps
cb300000
?
Blows up on invalid page access 'aaaaaaaa' a while later.

Thanks

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150317/41a7e7a0/attachment.html 

Android Binder Issue

[Greg KH]

On Tue, Mar 17, 2015 at 01:04:40PM -0400, David Legault wrote:
> Hello,
> 
> I'm trying to debug an issue I'm encountering on kernel 3.4 in the android
> binder.?
> Basically in the function binder_update_page_range it allocates a page. If I?
> understand correctly the next part, it maps this page_addr to the page in
> kernel?
> space and then maps the user process addr to the same page.
> 
> http://lxr.free-electrons.com/source/drivers/staging/android/binder.c?v=3.4#
> L611
> 
> If I attempt to use virt_to_head_page(page_addr) after all this is
> accomplished, I
> should get back the page that was just allocated and mapped, but that's not
> what
> I observe on my system as seen in the log below.
> 
> [ ? 20.960786] ( ? 25.557586) binder_open: 219:219
> [ ? 20.960827] ( ? 25.557617) binder_ioctl: 219:219 c0046209 be9a7938
> [ ? 20.960841] ( ? 25.557617) binder_ioctl: 219:219 40046205 be9a793c
> [ ? 20.960857] ( ? 25.557647) binder_mmap: 219 b6c02000-b6d00000 (1016 K) vma
> 200071 pagep 79f
> [ ? 20.960907] ( ? 25.557708) binder: 219: allocate pages cb300000-cb301000
> *** binder allocated page here (nil == first_page value)
> [ ? 20.960922] ( ? 25.557708) binder: page_alloc cd958238 ? ?(nil)
> *** dump of the page
> [ ? 20.960931] ( ? 25.557708) page:cd958238 count:1 mapcount:0 mapping: ? (nil)
> index:0x0
> [ ? 20.960939] ( ? 25.557739) page flags: 0x0()
> *** first attempt of virt_to_head_page(page_addr) before kernel mapping + dump
> of returned page
> *** which shows it's uninitialized ?(aaaaaaaa = first_page value)
> [ ? 20.960947] ( ? 25.557739) virt_to_head_page cd392c00
> [ ? 20.960955] ( ? 25.557739) compound_head_by_tail cd392c00 aaaaaaaa
> [ ? 20.960965] ( ? 25.557769) page:cd392c00 count:-1431655766
> mapcount:-1431655765 mapping:aaaaaaaa index:0xaaaaaaaa
> [ ? 20.960973] ( ? 25.557769) page flags: 0xaaaaaaaa(error|uptodate|lru|slab|
> arch_1|private|writeback|tail|mappedtodisk|swapbacked|mlocked)
> [ ? 20.960981] ( ? 25.557769) virt_to_head_page cd9681bc
> [ ? 20.960997] ( ? 25.557800) virt_to_head_page cd967c1c
> *** before kernel + user space mapping calls
> [ ? 20.961551] ( ? 25.558349) binder: addr cb300000 page aaaaaaaa
> *** after kernel + user space mapping calls - dump allocated page again
> [ ? 20.961566] ( ? 25.558349) page:cd958238 count:2 mapcount:1 mapping: ? (nil)
> index:0x0
> [ ? 20.961574] ( ? 25.558380) page flags: 0x200(arch_1)
> *** second attempt of virt_to_head_page(page_addr) expecting
> *** that allocated page above would be mapped to this address
> [ ? 20.961584] ( ? 25.558380) binder: addr cb300000 page aaaaaaaa
> [ ? 20.961595] ( ? 25.558380) binder: 219: add free buffer, size 1040344, at
> cb300000
> [ ? 20.961605] ( ? 25.558410) binder_mmap: 219 b6c02000-b6d00000 maps cb300000
> ?
> Blows up on invalid page access 'aaaaaaaa' a while later.

Never use binder on it's "own" always use the Android binder library
instead, otherwise bad things will happen.  Trust me, very bad things...

Also, 3.4 is really old, try a "modern" kernel please :)

good luck,

greg k-h