All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Llamas <cmllamas@google.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: arve@android.com, brauner@kernel.org, gregkh@linuxfoundation.org,
	joel@joelfernandes.org, kernel-team@android.com,
	linux-kernel@vger.kernel.org, maco@android.com,
	surenb@google.com, tkjos@android.com
Subject: Re: [PATCH 2/4] binder: migrate ioctl to new PF_SPAM_DETECTION
Date: Mon, 22 Apr 2024 22:24:17 +0000	[thread overview]
Message-ID: <ZibjkV3aweBq4uVB@google.com> (raw)
In-Reply-To: <CAH5fLgi96g-vQY-kzEZtkjgidqLy5dOSyFS=8dTE_QtQcpu4=Q@mail.gmail.com>

On Mon, Apr 22, 2024 at 10:52:57AM +0200, Alice Ryhl wrote:
> On Sun, Apr 21, 2024 at 1:49 AM Carlos Llamas <cmllamas@google.com> wrote:
> >
> > On Thu, Apr 18, 2024 at 08:12:22AM +0000, Alice Ryhl wrote:
> > > Carlos Llamas <cmllamas@google.com> writes:
> > > > @@ -5553,7 +5553,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> > > >                     goto err;
> > > >             }
> > > >             binder_inner_proc_lock(proc);
> > > > -           proc->oneway_spam_detection_enabled = (bool)enable;
> > > > +           proc->flags &= ~PF_SPAM_DETECTION;
> > > > +           proc->flags |= enable & PF_SPAM_DETECTION;
> > >
> > > The bitwise and in `enable & PF_SPAM_DETECTION` only works because
> > > PF_SPAM_DETECTION happens to be equal to 1. This seems pretty fragile to
> > > me. Would you be willing to do this instead?
> > >
> > > proc->flags &= ~PF_SPAM_DETECTION;
> > > if (enable)
> > >       proc->flags |= PF_SPAM_DETECTION;
> > >
> >
> > I don't think it is fragile since PF_SPAM_DETECTION is fixed. However,
> > I agree the code is missing context about the flag being bit 0 and your
> > version addresses this problem. So I'll take it for v2, thanks!
> 
> Thanks! By fragile I mean that it could result in future mistakes,
> e.g. somebody could copy this code and use it elsewhere with a
> different bit flag that might not be bit 0.

Oh, I see. Yeah that would be a problem.

> 
> > > Carlos Llamas <cmllamas@google.com> writes:
> > > > -                   if (proc->oneway_spam_detection_enabled &&
> > > > -                              w->type == BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT)
> > > > +                   if (proc->flags & PF_SPAM_DETECTION &&
> > > > +                       w->type == BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT)
> > >
> > > Maybe I am just not sufficiently familiar with C, but I had to look up
> > > the operator precedence rules for this one. Could we add parenthesises
> > > around `proc->flags & PF_SPAM_DETECTION`? Or even define a macro for it?
> >
> > I think this is fairly common in C but I can definitly add the extra
> > paranthesis if it helps.
> 
> Yeah, makes sense. Thanks!
> 
> With the mentioned changes, you may add:
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Done. Thanks!

  reply	other threads:[~2024-04-22 22:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 19:13 [PATCH 0/4] binder: optimize handle generation logic Carlos Llamas
2024-04-17 19:13 ` [PATCH 1/4] binder: introduce BINDER_SET_PROC_FLAGS ioctl Carlos Llamas
2024-04-18  8:34   ` Alice Ryhl
2024-04-20 23:39     ` Carlos Llamas
2024-04-22  8:56       ` Alice Ryhl
2024-04-22 22:48         ` Carlos Llamas
2024-04-23  8:18           ` Alice Ryhl
2024-04-17 19:13 ` [PATCH 2/4] binder: migrate ioctl to new PF_SPAM_DETECTION Carlos Llamas
2024-04-18  8:12   ` Alice Ryhl
2024-04-20 23:49     ` Carlos Llamas
2024-04-22  8:52       ` Alice Ryhl
2024-04-22 22:24         ` Carlos Llamas [this message]
2024-04-17 19:13 ` [PATCH 3/4] binder: add support for PF_LARGE_HANDLES Carlos Llamas
2024-04-18  8:21   ` Alice Ryhl
2024-04-17 19:13 ` [PATCH 4/4] binder: fix max_thread type inconsistency Carlos Llamas
2024-04-18  4:40   ` Greg Kroah-Hartman
2024-04-21  0:00     ` Carlos Llamas
2024-04-21  6:39       ` Greg Kroah-Hartman
2024-04-21 17:48         ` Carlos Llamas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZibjkV3aweBq4uVB@google.com \
    --to=cmllamas@google.com \
    --cc=aliceryhl@google.com \
    --cc=arve@android.com \
    --cc=brauner@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@joelfernandes.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=surenb@google.com \
    --cc=tkjos@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.