On 3/31/2021 3:44 PM, Greg KH wrote: > On Wed, Mar 31, 2021 at 03:34:16PM +0800, Hang Lu wrote: >> When async binder buffer got exhausted, some normal oneway transaction >> will also be discarded and finally caused system/app stop. By that time, >> the binder debug information we dump may not relevant to the root cause. >> And this issue is difficult to debug if without the backtrace of thread >> sending spam. >> >> This change will send BR_ONEWAY_SPAM_SUSPECT to userspace when detecting >> oneway spamming, request to dump current backtrace. The detection will >> happened 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 <[email protected]> >> --- >> drivers/android/binder.c | 25 ++++++++++++++++++++++--- >> drivers/android/binder_alloc.c | 15 ++++++++++++--- >> drivers/android/binder_alloc.h | 8 +++++++- >> drivers/android/binder_internal.h | 1 + >> include/uapi/linux/android/binder.h | 8 ++++++++ >> 5 files changed, 50 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/android/binder.c b/drivers/android/binder.c >> index c119736..28ceaf9 100644 >> --- a/drivers/android/binder.c >> +++ b/drivers/android/binder.c >> @@ -87,6 +87,7 @@ static DEFINE_SPINLOCK(binder_dead_nodes_lock); >> static struct dentry *binder_debugfs_dir_entry_root; >> static struct dentry *binder_debugfs_dir_entry_proc; >> static atomic_t binder_last_id; >> +static bool oneway_spam_detection_enabled; > > Why is this a "whole system" value and not a "per binder instance" > value? You just allowed one binder instance to affect another one, > which does not seem like a good idea to me :(
Sorry for the late reply. Actually I add this as it needs to be enabled to protect against user-space that doesn't understand the new command, so I make it a global setting. But making this flag per-proc will gain a finer control granularity, so I'll follow your suggestion and submit a v2 patch, thanks! Regards, Hang Lu
