linux-kernel - Re: [PATCH v4] binder: tell userspace to dump current backtrace when detected oneway spamming

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 9 Apr 2021 08:25:35 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Hang Lu <hangl@...eaurora.org>
Cc:     tkjos@...gle.com, tkjos@...roid.com, maco@...roid.com,
        arve@...roid.com, joel@...lfernandes.org, christian@...uner.io,
        hridya@...gle.com, surenb@...gle.com, rdunlap@...radead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] binder: tell userspace to dump current backtrace when
 detected oneway spamming

On Fri, Apr 09, 2021 at 02:21:58PM +0800, Hang Lu wrote:
> On 4/9/2021 2:08 PM, Greg KH wrote:
> > On Fri, Apr 09, 2021 at 11:40:57AM +0800, Hang Lu wrote:
> >> When async binder buffer got exhausted, some normal oneway transactions
> >> will also be discarded and may cause system or application failures. By
> >> that time, the binder debug information we dump may not be relevant to
> >> the root cause. And this issue is difficult to debug if without the
> >> backtrace of the thread sending spam.
> >>
> >> This change will send BR_ONEWAY_SPAM_SUSPECT to userspace when oneway
> >> spamming is detected, request to dump current backtrace. Oneway spamming
> >> will be reported only once when exceeding the threshold (target process
> >> dips below 80% of its oneway space, and current process is responsible for
> >> either more than 50 transactions, or more than 50% of the oneway space).
> >> And the detection will restart when the async buffer has returned to a
> >> healthy state.
> >>
> >> Signed-off-by: Hang Lu <hangl@...eaurora.org>
> >> ---
> >> v4: add missing BR_FROZEN_REPLY in binder_return_strings and change the size of binder_stats.br array
> > 
> > Should the BR_FROZEN_REPLY string be a separate patch as it's a fix for
> > the "binder frozen feature", not this new feature, right?  Or does this
> > patch require that change and the frozen patch did not?
> 
> Yes, BR_FROZEN_REPLY string is a fix and seems should to be separated from this new feature. But I'm still wondering how to submit these 2 separate patches as they edit the same place(maybe merge conflict). Do you know which of the following two commit methods is more suitable? Thanks!
> 
> 1. char-misc-next HEAD --> BR_FROZEN_REPLY fix patch --> new feature patch

Yes, do it this way, a 2 patch series is fine.

thanks,

greg k-h