[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+xfxX4tD30BJLgwLAoiMzF7xTC-4q1i0A5Znp3tJzyi3ATLzQ@mail.gmail.com>
Date: Thu, 11 Mar 2021 01:36:26 -0800
From: Li Li <dualli@...omium.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Todd Kjos <tkjos@...gle.com>, christian@...uner.io,
arve@...roid.com, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org, Martijn Coenen <maco@...gle.com>,
hridya@...gle.com, surenb@...gle.com, joel@...lfernandes.org,
kernel-team@...roid.com
Subject: Re: [PATCH v1 1/3] binder: BINDER_FREEZE ioctl
On Wed, Mar 10, 2021 at 11:33 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Wed, Mar 10, 2021 at 02:52:49PM -0800, Li Li wrote:
> > if (target_proc) {
> > binder_inner_proc_lock(target_proc);
> > + target_proc->outstanding_txns--;
> > + WARN_ON(target_proc->outstanding_txns < 0);
>
> WARN_* is a huge crutch, please just handle stuff like this properly and
> if you really need to, warn userspace (but what can they do about it?)
>
> You also just rebooted all systems that have panic-on-warn set, so if
> this can be triggered by userspace, you caused a DoS of things :(
>
> So please remove all of the WARN_ON() you add in this patch series to
> properly handle the error conditions and deal with them correctly.
>
> And if these were here just for debugging, hopefully the code works
> properly now and you do not need debugging anymore so they can all just
> be dropped.
When the target_proc is freed, there's no outstanding transactions already.
The FREEZE ioctl from userspace won't trigger this. It's for debugging.
And I'll remove it in v2. Thanks for the suggestion!
Powered by blists - more mailing lists