[PATCH v5 0/3] pidfd: Add task path ioctls

[Chen Linxuan via B4 Relay]

Obtaining a target task's executable, working directory or root
currently requires following /proc/<pid>/{exe,cwd,root}. Add
PIDFD_GET_EXE, PIDFD_GET_CWD and PIDFD_GET_ROOT so callers holding a
pidfd can obtain these paths without requiring procfs to be mounted or
visible.

Each ioctl takes a zero argument and returns an O_PATH file descriptor
with FD_CLOEXEC set. Targets must be visible in the caller's active pid
namespace. Reuse the procfs path getters and hold exec_update_lock
across PTRACE_MODE_READ_FSCREDS authorization and path acquisition.

Following Christian Brauner's review, use a dedicated task_path_open()
helper after releasing exec_update_lock. It calls ->d_weak_revalidate()
with flags zero when the filesystem provides it, propagates a negative
error, maps a zero result to ESTALE, and otherwise opens the path with
O_PATH. This gives filesystems such as failfs the opportunity to refuse
an O_PATH descriptor without starting a pathname lookup.

The first patch factors out the task path getters. The second prepares
scoped task access for the pidfd ioctls. The third adds the three ioctls
and task_path_open().

This series depends on the separately submitted pid-namespace visibility
restriction:
  https://lore.kernel.org/all/20261027-pidfd-task-access-v1-1-d46cf0fa4ca1@xxxxxxxxxxxxx/

Tested with virtme-ng.

Sashiko AI review reported the missing weak revalidation in v4.
This entire patch series was generated with LLM assistance. I defined
the requirements, guided the implementation, reviewed the changes, and
made the design decisions.

---
Changes in v5:
- Add task_path_open() as suggested by Christian Brauner, replacing the
  direct dentry_open() call from v4. Revalidate with flags zero outside
  exec_update_lock and return filesystem errors without lookup retries.
- Link to v4:
  https://lore.kernel.org/all/20261027-pidfd-get-paths-v4-0-e2a6a47e3c95@xxxxxxxxxxxxx/

To: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
To: Christian Brauner <brauner@xxxxxxxxxx>
To: Jan Kara <jack@xxxxxxx>
To: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
To: Lorenzo Stoakes <ljs@xxxxxxxxxx>
To: "Liam R. Howlett" <liam@xxxxxxxxxxxxx>
To: Vlastimil Babka <vbabka@xxxxxxxxxx>
To: Mike Rapoport <rppt@xxxxxxxxxx>
To: Suren Baghdasaryan <surenb@xxxxxxxxxx>
To: Michal Hocko <mhocko@xxxxxxxx>
To: Ingo Molnar <mingo@xxxxxxxxxx>
To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
To: Juri Lelli <juri.lelli@xxxxxxxxxx>
To: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
To: Dietmar Eggemann <dietmar.eggemann@xxxxxxx>
To: Steven Rostedt <rostedt@xxxxxxxxxxx>
To: Ben Segall <bsegall@xxxxxxxxxx>
To: Mel Gorman <mgorman@xxxxxxx>
To: Valentin Schneider <vschneid@xxxxxxxxxx>
To: K Prateek Nayak <kprateek.nayak@xxxxxxx>
To: Kees Cook <kees@xxxxxxxxxx>
To: John Johansen <john.johansen@xxxxxxxxxxxxx>
To: Georgia Garcia <georgia.garcia@xxxxxxxxxxxxx>
To: Paul Moore <paul@xxxxxxxxxxxxxx>
To: James Morris <jmorris@xxxxxxxxx>
To: "Serge E. Hallyn" <serge@xxxxxxxxxx>
Cc: linux-fsdevel@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: linux-mm@xxxxxxxxx
Cc: apparmor@xxxxxxxxxxxxxxxx
Cc: linux-security-module@xxxxxxxxxxxxxxx

---
Chen Linxuan (3):
      fs: Introduce task path helpers
      pidfd: Use scoped cleanup for task access
      pidfd: Add task path ioctls

 fs/fs_struct.c             |  44 +++++++++++++
 fs/internal.h              |   1 +
 fs/open.c                  |  30 +++++++++
 fs/pidfs.c                 | 157 ++++++++++++++++++++++++++++++++-------------
 fs/proc/base.c             |  34 +---------
 include/linux/fs_struct.h  |   3 +
 include/linux/mm.h         |   1 +
 include/uapi/linux/pidfd.h |   7 ++
 kernel/fork.c              |  22 +++++++
 security/apparmor/task.c   |  12 +---
 10 files changed, 224 insertions(+), 87 deletions(-)
---
base-commit: d135ab453a7400a34930bdda1ef4bdc8acfac80e
change-id: 20260819-pidfd-get-paths-59640d8cd1ee
prerequisite-change-id: 20261027-pidfd-task-access-b797ecb260a4:v1
prerequisite-patch-id: 021f6b0840ced7fe967a849b99c366257160c005

Best regards,
--  
Chen Linxuan <me@xxxxxxxxxxxxx>