Since the introduction of pidfs, we have had 64-bit process identifiers that will not be reused for the entire uptime of the system. This greatly facilitates process tracking in userspace. There are two limitations at present: * These identifiers are currently only exposed to processes on 64-bit systems. On 32-bit systems, inode space is also limited to 32 bits and therefore is subject to the same reuse issues. * There is no way to go from one of these unique identifiers to a pid or pidfd. Patch 1 & 2 in this stack implements fh_export for pidfs. This means userspace can retrieve a unique process identifier even on 32-bit systems via name_to_handle_at. Patch 3 & 4 in this stack implement fh_to_dentry for pidfs. This means userspace can convert back from a file handle to the corresponding pidfd. To support us going from a file handle to a pidfd, we have to store a pid inside the file handle. To ensure file handles are invariant and can move between pid namespaces, we stash a pid from the initial namespace inside the file handle. I'm not quite sure if stashing an initial-namespace pid inside the file handle is the right approach here; if not, I think that patch 1 & 2 are useful on their own. Erin Shepherd (4): pseudofs: add support for export_ops pidfs: implement file handle export support pid: introduce find_get_pid_ns pidfs: implement fh_to_dentry fs/libfs.c | 1 + fs/pidfs.c | 57 +++++++++++++++++++++++++++++++++++++++ include/linux/pid.h | 1 + include/linux/pseudo_fs.h | 1 + kernel/pid.c | 10 +++++-- 5 files changed, 68 insertions(+), 2 deletions(-) -- 2.46.1
