Re: [PATCH v2 0/7] rust_binder : Implement dynamic debug logging mask

[Alice Ryhl]

On Sat, Jul 11, 2026 at 12:29 PM Jahnavi Nitheesha Mandava
<jahnavimn@xxxxxxxxxx> wrote:
>
> On Fri, Jul 10, 2026 at 8:31 PM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jul 10, 2026 at 02:32:51PM +0000, Jahnavi MN via B4 Relay wrote:
> > > When a user-space application sends malformed data or makes a
> > > lifecycle mistake, the driver rejects it with a generic error code
> > > (like -EINVAL). Without internal logs, the driver acts as a
> > > "black box," forcing developers to guess which check failed.
> > >
> > > In the legacy C Binder driver, this issue is solved using a dynamic
> > > debug_mask module parameter that toggles verbose logs for specific
> > > subsystems. This series brings the same critical capability to the
> > > Rust Binder driver to provide developers with clear, real-time
> > > feedback.
> > >
> > > Instead of rebuilds, reboots, or guessing:
> > > - Developers can enable logs instantly on a running device by writing to
> > >   `/sys/module/rust_binder/parameters/debug_mask`.
> > > - It prints the exact reason for failures (such as alignment errors,
> > >   mismatched call stacks, or invalid handle references) directly into
> > >   `dmesg`, reducing debugging time from hours to seconds.
> > > - It protects system logs by keeping logging off by default and only
> > >   enabling it when developers are actively troubleshooting.
> > >
> > > Based on top of:
> > > https://lore.kernel.org/rust-for-linux/20260707-upgrade-poll-v6-0-4b8fae7bf1d9@xxxxxxxxxx/
> > >
> > > Signed-off-by: Jahnavi MN <jahnavimn@xxxxxxxxxx>
> >
> > Patches 5 and 7 did not apply to my tree, can you rebase against the
> > char-misc-testing branch and send just those?  Other ones are now all
> > queued up, nice work!
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Thanks! I will rebase and resubmit only patches 5 and 7 as a new
> version (v3) of this series shortly.
>
> Regarding the feedback I received on Patch 1 (using the BIT macro
> and Atomic<u32>), since Patch 1 is already queued, I will send those
> cleanups as a separate, follow-up patch. Does that sound good?

Since it's only queued in char-misc-testing and not char-misc-next, I
don't think it's too late to change the patches themselves. So I guess
you could also resend the entire series based on top of commit
f8d269390cd2 ("rust_binder: update Process::node_refs to use
SpinLock") from testing?

Alice