On Wed, Sep 25, 2024 at 05:25:42PM +0000, Carlos Llamas wrote:
On Wed, Sep 25, 2024 at 09:36:10AM +0200, 'Alice Ryhl' via kernel-team wrote:
On Tue, Sep 24, 2024 at 8:44 PM Carlos Llamas cmllamas@google.com wrote:
The BINDER_WORK_FROZEN_BINDER type is not handled in the binder_logs entries and it shows up as "unknown work" when logged:
proc 649 context binder-test thread 649: l 00 need_return 0 tr 0 ref 13: desc 1 node 8 s 1 w 0 d 0000000053c4c0c3 unknown work: type 10
This patch add the freeze work type and is now logged as such:
proc 637 context binder-test thread 637: l 00 need_return 0 tr 0 ref 8: desc 1 node 3 s 1 w 0 d 00000000dc39e9c6 has frozen binder
Fixes: d579b04a52a1 ("binder: frozen notification") Cc: stable@vger.kernel.org Signed-off-by: Carlos Llamas cmllamas@google.com
drivers/android/binder.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c index d955135ee37a..2be9f3559ed7 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -6408,6 +6408,9 @@ static void print_binder_work_ilocked(struct seq_file *m, case BINDER_WORK_CLEAR_DEATH_NOTIFICATION: seq_printf(m, "%shas cleared death notification\n", prefix); break;
case BINDER_WORK_FROZEN_BINDER:seq_printf(m, "%shas frozen binder\n", prefix);break;What about BINDER_WORK_CLEAR_FREEZE_NOTIFICATION?
Oh, you are right! We also need this type here. I haven't played with the clear notification path just yet (as you can tell). Thanks for pointing it out though, I'll send a v2.
Looking closer, I see that BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT is also missing, so I'll send a separate patch for that too.
After playing with clear-freeze I've also found a memleak. This work is not being released unless it is processed. I'll add one more patch to the v2 series fixing it (tomorrow).
unreferenced object 0xffff03ced63cd280 (size 64): comm "binder-util", pid 947, jiffies 4295183379 hex dump (first 32 bytes): 80 d2 3c d6 ce 03 ff ff 80 d2 3c d6 ce 03 ff ff ..<.......<..... 0b 00 00 00 00 00 00 00 3c 1f 4a 00 00 00 00 00 ........<.J..... backtrace (crc 718d20df): [<00000000188a0477>] kmemleak_alloc+0x34/0x40 [<00000000fe1c45bc>] __kmalloc_cache_noprof+0x208/0x280 [<000000005ebe1c53>] binder_thread_write+0xdec/0x439c [<000000004b0e4ffa>] binder_ioctl+0x1b68/0x22cc [<000000001786d65d>] __arm64_sys_ioctl+0x124/0x190 [<00000000fb1e34f9>] invoke_syscall+0x6c/0x254 [<00000000826a09b6>] el0_svc_common.constprop.0+0xac/0x230 [<000000004389c74d>] do_el0_svc+0x40/0x58 [<000000008b9dd949>] el0_svc+0x38/0x78 [<00000000c66f77b2>] el0t_64_sync_handler+0x120/0x12c [<00000000a4cd389b>] el0t_64_sync+0x190/0x194>
-- Carlos Llamas