Deprecate the BINDER_ENABLE_ONEWAY_SPAM_DETECTION ioctl in favor of the
new PF_SPAM_DETECTION flag. The ioctl can be lumped together with other
flags to avoid a separate system call. The driver still supports the old
ioctl for backwards compatibility.
Suggested-by: Arve Hjønnevåg <[email protected]>
Signed-off-by: Carlos Llamas <[email protected]>
---
drivers/android/binder.c | 7 ++++---
drivers/android/binder_internal.h | 1 -
include/uapi/linux/android/binder.h | 8 ++++++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index e0d193bfb237..54d27dbf1de2 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4486,8 +4486,8 @@ static int binder_thread_read(struct binder_proc *proc,
case BINDER_WORK_TRANSACTION_COMPLETE:
case BINDER_WORK_TRANSACTION_PENDING:
case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: {
- 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)
cmd = BR_ONEWAY_SPAM_SUSPECT;
else if (w->type == BINDER_WORK_TRANSACTION_PENDING)
cmd = BR_TRANSACTION_PENDING_FROZEN;
@@ -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;
binder_inner_proc_unlock(proc);
break;
}
diff --git a/drivers/android/binder_internal.h b/drivers/android/binder_internal.h
index a22e64cddbae..3312fe93a306 100644
--- a/drivers/android/binder_internal.h
+++ b/drivers/android/binder_internal.h
@@ -434,7 +434,6 @@ struct binder_proc {
spinlock_t inner_lock;
spinlock_t outer_lock;
struct dentry *binderfs_entry;
- bool oneway_spam_detection_enabled;
};
/**
diff --git a/include/uapi/linux/android/binder.h b/include/uapi/linux/android/binder.h
index 281a8e2e734e..972f402415c2 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -253,7 +253,9 @@ struct binder_extended_error {
/* Used with BINDER_SET_PROC_FLAGS ioctl */
enum proc_flags {
- PF_SUPPORTED_FLAGS_MASK,
+ PF_SPAM_DETECTION = (1 << 0), /* enable oneway spam detection */
+
+ PF_SUPPORTED_FLAGS_MASK = PF_SPAM_DETECTION,
};
enum {
@@ -269,9 +271,11 @@ enum {
BINDER_SET_CONTEXT_MGR_EXT = _IOW('b', 13, struct flat_binder_object),
BINDER_FREEZE = _IOW('b', 14, struct binder_freeze_info),
BINDER_GET_FROZEN_INFO = _IOWR('b', 15, struct binder_frozen_status_info),
- BINDER_ENABLE_ONEWAY_SPAM_DETECTION = _IOW('b', 16, __u32),
BINDER_GET_EXTENDED_ERROR = _IOWR('b', 17, struct binder_extended_error),
BINDER_SET_PROC_FLAGS = _IOWR('b', 18, __u32),
+
+ /* This is deprecated, use BINDER_SET_PROC_FLAGS instead. */
+ BINDER_ENABLE_ONEWAY_SPAM_DETECTION = _IOW('b', 16, __u32),
};
/*
--
2.44.0.683.g7961c838ac-goog
Carlos Llamas <[email protected]> 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;
Carlos Llamas <[email protected]> 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?
Alice
On Thu, Apr 18, 2024 at 08:12:22AM +0000, Alice Ryhl wrote:
> Carlos Llamas <[email protected]> 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!
>
> Carlos Llamas <[email protected]> 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.
--
Carlos Llamas
On Sun, Apr 21, 2024 at 1:49 AM Carlos Llamas <[email protected]> wrote:
>
> On Thu, Apr 18, 2024 at 08:12:22AM +0000, Alice Ryhl wrote:
> > Carlos Llamas <[email protected]> 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.
> > Carlos Llamas <[email protected]> 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 <[email protected]>
Alice
On Mon, Apr 22, 2024 at 10:52:57AM +0200, Alice Ryhl wrote:
> On Sun, Apr 21, 2024 at 1:49 AM Carlos Llamas <[email protected]> wrote:
> >
> > On Thu, Apr 18, 2024 at 08:12:22AM +0000, Alice Ryhl wrote:
> > > Carlos Llamas <[email protected]> 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 <[email protected]> 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 <[email protected]>
Done. Thanks!