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 <ha...@codeaurora.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
