Re: [PATCH v3 3/3] rust_binder: handle PID namespace conversion for freeze operation

[Alice Ryhl <aliceryhl@google.com>]

On Wed, Feb 04, 2026 at 06:11:47PM +0900, jongan.kim@lge.com wrote:
> On Tue Feb 3, 2026 at 12:59:45PM +0000, Gary Guo wrote:
> > On Tue Feb 3, 2026 at 6:59 AM GMT, jongan.kim wrote:
> > I think this function already has `ARef<Task>` for all the process, so it feels
> > to me that the search should be simply based on task, rather than PID.
> > 
> > I.e. instead of pid_t -> struct pid -> struct tasks -> pid_t and then search
> > with it, we first get `Task` from VPID, and then search directly with it. This
> > would also make it no longer necessary to have the init namespace check.
> > 
> > (BTW, the current impl looks quite inefficient, get_procs_with_pid returns a vec
> > which is pushed again to a vec, perhaps using a callback or simply passing in a
> > `&mut Vec` is better?)
> > 
> > Best,
> > Gary
> > 
> > >              procs.push(proc, GFP_KERNEL)?;
> > >          }
> > >      }
> 
> Thank you for the suggestions for more efficient structure.
> 
> Your proposal to use task-based search instead of PID-based search
> could simplify the logic.
> 
> However, I have a few considerations:
> 1. The current implementation maintains consistency with the existing
> C binder implementation. Any structural change here would ideally be
> reflected in the  C code as well to keep both implementations aligned.

Yes, the drivers should match.

> 2. Since the majority of binder usage occurs in the init namespace, the
> current early return (checking task_is_in_init_pid_ns) avoids the overhead
> of find_vpid() and pid_task() calls in the common case. If we always go
> through the task lookup path, this optimization would be lost.

Well, I suggested this approach too on the previous version:
https://lore.kernel.org/lkml/20260130015427.83556-1-jongan.kim@lge.com/
(I mentioned it on C Binder, but they should of course match.)

I'm not necessarily that concerned about the optimization. Freezing is
already a bit expensive to begin with.

> 3. Regarding the search mechanism and vec efficiency improvements you
> mentioned, these seem like valuable optimizations but would represent
> a broader architectural change to the binder driver.

Improving get_procs_with_pid() seems like a separate thing. Perhaps it
could be part of this other series:
https://lore.kernel.org/all/20260201000817.275382-1-shivamklr@cock.li/

Improving it here should only happen if you need to rewrite said
function *anyway*.

> I'd like to get input from the binder driver maintainers on whether:
> - This kind of structural change is desired for the binder driver
> - If so, whether it should be done as part of this PID namespace fix or
> as a separate refactoring effort

See above.

> - Whether both C and Rust implementations should be updated together
> 
> Alice, could you please advise on the preferred approach here?

Both implementations should be updated together.

Alice