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

[jongan.kim@lge.com]

On Wed, Feb 04 2026 10:50:31AM +0000, Alice Ryhl wrote:
> 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.

Sorry, I misunderstood your intention before. I will update the new patch
to apply your recommendations for both the Rust and C. Thank you for the
review and suggestions.

> > 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*.

Since we're changing the implementation to use task-based comparison instead
of PID-based comparison, we won't be using get_procs_with_pid() anymore and
will need to write a new function (e.g., get_procs_with_task()).

Would this approach align with the Rust binder development direction?

> > 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.

We will update both the Rust and C implementations together.

Thanks.
Jong An, Kim.