Re: [PATCH 4/4] binder: fix BINDER_WORK_FROZEN_BINDER debug logs

[Carlos Llamas <cmllamas@google.com>]

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