Re: [PATCH v4] binder: tell userspace to dump current backtrace when detected oneway spamming
From: Hang Lu
Date: Fri Apr 09 2021 - 02:22:15 EST
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@xxxxxxxxxxxxxx>
>> ---
>> 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
2. char-misc-next HEAD --> BR_FROZEN_REPLY fix patch
\-----> new feature patch