On Mon, Sep 23, 2024 at 11:13:56AM GMT, Alice Ryhl wrote:
> On Mon, Sep 16, 2024 at 12:02 AM Gary Guo <gary@xxxxxxxxxxx> wrote:
> >
> > On Sun, 15 Sep 2024 14:31:33 +0000
> > Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote:
> > > + /// Returns the given task's pid in the current pid namespace.
> > > + pub fn pid_in_current_ns(&self) -> Pid {
> > > + // SAFETY: We know that `self.0.get()` is valid by the type invariant, and passing a null
> > > + // pointer as the namespace is correct for using the current namespace.
> > > + unsafe { bindings::task_tgid_nr_ns(self.0.get(), ptr::null_mut()) }
> >
> > Do we want to rely on the behaviour of `task_tgid_nr_ns` with null
> > pointer as namespace, or use `task_tgid_vnr`?
>
> Hmm. Looks like C Binder actually does:
> trd->sender_pid = task_tgid_nr_ns(sender, task_active_pid_ns(current));
>
> Not sure why I'm using a null pointer here.
Passing a NULL pointer for task_tgid_nr_ns() is fine. Under the hood
it's just __task_pid_nr_ns(task, PIDTYPE_TGID, NULL) which causes
task_active_pid_ns(current) to be called internally. So it's equivalent.
In any case, I did add Rust wrappers for struct pid_namespace just to
see how far I would get as task_active_pid_ns() is rather subtle even if
it isn't obvious at first glance. Sending that in a second.
