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 <arve@android.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
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-googCarlos 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; 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? Alice
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! > > 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. -- Carlos Llamas
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. > > 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> 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 <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!
© 2016 - 2026 Red Hat, Inc.