In the current Rust Binder driver, internal state variables (thread
looper states, deferred work, and transaction configurations) are
represented as raw integers and manipulated using manual bitwise
operations.

This approach lacks type safety. Because the compiler treats all
integers identically, it is possible to pass a thread looper flag
into a function expecting a transaction flag without triggering
compile-time warnings. These cross-contamination errors compile
cleanly but can cause runtime bugs or undefined behavior.

This patch series resolves this issue by migrating these raw integer
bitmaps (`defer_work`, `looper_flags`, `flags`) to strongly-typed
bitmasks using the `kernel::impl_flags!` macro. Functions now accept
specific, distinct types rather than generic integers, preventing
flags from being mixed up. This transition also replaces manual
bitwise arithmetic with readable, safe methods.

Based on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git

Signed-off-by: Jahnavi MN <jahnavimn@google.com>
---
Jahnavi MN (3):
      rust_binder: Update defer_work bitmaps to use kernel::impl_flags!
      rust_binder: Update looper_flags bitmaps to use kernel::impl_flags!
      rust_binder: Update transaction flags to use kernel::impl_flags!

 drivers/android/binder/process.rs     | 34 +++++++++++------
 drivers/android/binder/thread.rs      | 69 +++++++++++++++++++++--------------
 drivers/android/binder/transaction.rs | 56 +++++++++++++++++++++-------
 3 files changed, 105 insertions(+), 54 deletions(-)
---
base-commit: 775553d19b163446c38c5ff24dd0a01065376932
change-id: 20260715-b4-rust_binder_impl_flags-e53b4ebca85d

Best regards,
-- 
Jahnavi MN <jahnavimn@google.com>

On Thu, Jul 16, 2026 at 01:02:33PM +0000, Jahnavi MN via B4 Relay wrote:
> In the current Rust Binder driver, internal state variables (thread
> looper states, deferred work, and transaction configurations) are
> represented as raw integers and manipulated using manual bitwise
> operations.
> 
> This approach lacks type safety. Because the compiler treats all
> integers identically, it is possible to pass a thread looper flag
> into a function expecting a transaction flag without triggering
> compile-time warnings. These cross-contamination errors compile
> cleanly but can cause runtime bugs or undefined behavior.
> 
> This patch series resolves this issue by migrating these raw integer
> bitmaps (`defer_work`, `looper_flags`, `flags`) to strongly-typed
> bitmasks using the `kernel::impl_flags!` macro. Functions now accept
> specific, distinct types rather than generic integers, preventing
> flags from being mixed up. This transition also replaces manual
> bitwise arithmetic with readable, safe methods.
> 
> Based on top of:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> 
> Signed-off-by: Jahnavi MN <jahnavimn@google.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

It would be nice if our impl_flags! macro could allow us to omit the
right-hand-side that's saying `= bit_u8(i)` here:

    /// Represents a single deferred work category.
    #[derive(Debug, Clone, Copy, PartialEq, Eq)]
    pub enum DeferWork {
        Flush = bit_u8(0),
        Release = bit_u8(1),
    }

After all, if we don't care what values the bits take, the macro could
just assign them for us.

Alice