From: Yury Norov <ynorov@nvidia.com>
To: jongan.kim@lge.com
Cc: a.hindborg@kernel.org, aliceryhl@google.com, arve@android.com,
bjorn3_gh@protonmail.com, boqun.feng@gmail.com,
brauner@kernel.org, cmllamas@google.com, dakr@kernel.org,
daniel.almeida@collabora.com, gary@garyguo.net,
gregkh@linuxfoundation.org, heesu0025.kim@lge.com,
ht.hong@lge.com, jungsu.hwang@lge.com, kernel-team@android.com,
linux-kernel@vger.kernel.org, lossin@kernel.org,
ojeda@kernel.org, rust-for-linux@vger.kernel.org,
sanghun.lee@lge.com, seulgi.lee@lge.com, sunghoon.kim@lge.com,
tamird@gmail.com, tkjos@android.com, tmgross@umich.edu,
viresh.kumar@linaro.org, vitaly.wool@konsulko.se,
yury.norov@gmail.com
Subject: Re: [PATCH v3 1/3] binder: handle PID namespace conversion for freeze operation
Date: Wed, 4 Feb 2026 12:04:17 -0500 [thread overview]
Message-ID: <aYN8EeZKIw4_QHRa@yury> (raw)
In-Reply-To: <20260204090521.32136-1-jongan.kim@lge.com>
On Wed, Feb 04, 2026 at 06:05:21PM +0900, jongan.kim@lge.com wrote:
> On Tue, Feb 03, 2026 at 03:38:59PM -0500, Yury Norov wrote:
> > On Tue, Feb 03, 2026 at 03:59:26PM +0900, jongan.kim@lge.com wrote:
> > > From: JongAn Kim <jongan.kim@lge.com>
> > >
> > > Currently, when a freeze is attempted from a non-init PID namespace,
> > > there is a possibility that the wrong process in the init namespace
> > > may be frozen due to PID collision across namespaces.
> > >
> > > For example, if a container with PID namespace has a process with
> > > PID 100 (which maps to PID 5000 in init namespace), attempting to
> > > freeze PID 100 from the container could incorrectly match a different
> > > process with PID 100 in the init namespace.
> > >
> > > This patch fixes the issue by:
> > > 1. Converting the caller's PID from their namespace to init namespace
> > > 2. Matching against binder_proc->pid (which stores init namespace TGID)
> > > 3. Returning -EINVAL for invalid PIDs and -ESRCH for not-found processes
> > >
> > > This change ensures correct PID handling when binder freeze occurs in
> > > non-init PID namespace.
> > >
> > > Signed-off-by: JongAn Kim <jongan.kim@lge.com>
> > > ---
> > > v2 -> v3 : change to use task->tgid instead of task_tgid_nr_ns()
> > >
> > > drivers/android/binder.c | 53 +++++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 50 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > > index 535fc881c8da..4c4366089ecb 100644
> > > --- a/drivers/android/binder.c
> > > +++ b/drivers/android/binder.c
> > > @@ -5609,6 +5609,41 @@ static bool binder_txns_pending_ilocked(struct binder_proc *proc)
> > > return false;
> > > }
> > >
> > > +/**
> > > + * binder_convert_to_init_ns_tgid() - Convert pid to global pid(init namespace)
> >
> > For global PIDs we've got task_pid_nr(), see include/linux/pid.h:
> >
> > /*
> > * the helpers to get the task's different pids as they are seen
> > * from various namespaces
> > *
> > * task_xid_nr() : global id, i.e. the id seen from the init namespace;
> > * task_xid_vnr() : virtual id, i.e. the id seen from the pid namespace of
> > * current.
> > * task_xid_nr_ns() : id seen from the ns specified;
> > *
> > * see also pid_nr() etc in include/linux/pid.h
> > */
> >
> > I think task_tgid_nr(current) would work for you. Or I misunderstand
> > something?
> >
> > If your "binder_convert" returns something not covered by one from
> > the above, please put your function in include/linux/pid.h and give
> > it a proper name.
>
> Thank you for the suggestion. However, task_tgid_nr(current) returns the TGID
> of the *current* process, not the target process we want to freeze.
>
> What we need is to convert a TGID from the caller's PID namespace to the
> corresponding TGID in the init namespace for a *different* process (the one
> being frozen). The flow is:
>
> 1. User space passes a TGID in their own namespace
> 2. We find the task_struct for that TGID via find_vpid()
> 3. We return task->tgid, which is always in init namespace
>
> This differs from the existing task_xid_nr() family because we're converting
> a PID from one namespace (caller's) to init namespace for a different task.
OK, I think I see now. Thanks for the explanation. Maybe add it in commit
message?
> > > + * @pid: pid from user space
> > > + *
> > > + * Converts a process ID (TGID) from the caller's PID namespace to the
> > > + * corresponding TGID in the init namespace.
> >
> > Process ID (PID) is not the same as TGID, but you use the names
> > interchangeably. This is very confusing. Can you reword?
>
> Binder driver handles TGID for bind freeze operation.
> To avoid confusion, I will unify the variable names and terminology to use
> "TGID" consistently.
>
> > > + * Return: On success, returns TGID in init namespace (positive value).
> > > + * On error, returns -EINVAL if pid <= 0, or -ESRCH if process
> > > + * not found or not visible in init namespace.
> > > + */
> > > +static int binder_convert_to_init_ns_tgid(u32 pid)
> >
> > This should use pid_t.
>
> Ok. I will change to use pid_t for next patch.
>
> > > +{
> > > + struct task_struct *task;
> > > + int init_ns_pid = 0;
> > > +
> > > + /* already in init namespace */
> > > + if (task_is_in_init_pid_ns(current))
> > > + return pid;
> > > +
> > > + if (pid == 0)
> > > + return -EINVAL;
> >
> > Can you comment what is wrong with pid == 0?
>
> Since find_vpid() always returns NULL when the input value is 0, it returns
> an EINVAL error before calling rcu_read_lock().
OK, so it's a performance trick. Can you discuss performance impact
then? I just wonder how often this function is called with the pid
of idle task? If no performance impact, maybe it's worth to keep
code simpler?
This also adds inconsistency: if you're running on behalf of root ns,
you return 0 if pid == 0, otherwise you return an error. That's weird
because idle is 0 for any namespace. If it's intended, can you explicitly
mention it?
If you still want to bail out early for pid == 0, maybe:
if (pid == 0 || task_is_in_init_pid_ns(current))
return pid;
> > > + rcu_read_lock();
> > > + task = pid_task(find_vpid(pid), PIDTYPE_PID);
> > > + if (task)
> > > + init_ns_pid = task->tgid;
> >
> > So I've been replying with the same suggestion to v2, but you did it
> > in this v3 yourself.
> >
> > > + rcu_read_unlock();
> > > +
> > > + if (!init_ns_pid)
> > > + return -ESRCH;
> >
> > You can assign init_ns_pid to -ESRCH at declaration and drop this chunk.
> >
> > > +
> > > + return init_ns_pid;
> > > +}
> >
> > Thanks,
> > Yury
>
> Thanks for suggestion. I will apply it (init_ns_pid = -ESRCH) in the next
> patch.
>
> Thanks,
> JongAn Kim.
next prev parent reply other threads:[~2026-02-04 17:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 6:59 [PATCH v3 0/3] binder: handle PID namespace conversion for freeze operation jongan.kim
2026-02-03 6:59 ` [PATCH v3 1/3] " jongan.kim
2026-02-03 20:38 ` Yury Norov
2026-02-04 9:05 ` jongan.kim
2026-02-04 17:04 ` Yury Norov [this message]
2026-02-05 5:30 ` jongan.kim
2026-02-03 6:59 ` [PATCH v3 2/3] rust: pid: add Pid abstraction and init_ns helper jongan.kim
2026-02-03 13:01 ` Gary Guo
2026-02-03 6:59 ` [PATCH v3 3/3] rust_binder: handle PID namespace conversion for freeze operation jongan.kim
2026-02-03 12:59 ` Gary Guo
2026-02-04 9:11 ` jongan.kim
2026-02-04 10:50 ` Alice Ryhl
2026-02-05 5:01 ` jongan.kim
2026-02-05 8:20 ` Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYN8EeZKIw4_QHRa@yury \
--to=ynorov@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=cmllamas@google.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=heesu0025.kim@lge.com \
--cc=ht.hong@lge.com \
--cc=jongan.kim@lge.com \
--cc=jungsu.hwang@lge.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sanghun.lee@lge.com \
--cc=seulgi.lee@lge.com \
--cc=sunghoon.kim@lge.com \
--cc=tamird@gmail.com \
--cc=tkjos@android.com \
--cc=tmgross@umich.edu \
--cc=viresh.kumar@linaro.org \
--cc=vitaly.wool@konsulko.se \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.