file searches fail when procfs is mounted at multiple mount points

[DamjanJovanovic]

With HASPROCFS enabled, and procfs mounted in multiple places (eg. main system and a nested chroot), "lsof /proc/1/map" can fail to find anything, even though "lsof | grep /proc/1/map" works.

On multiple dialects (du, freebsd, n+obsd, sun, uw; Linux might be unaffected), the following seems to happen. There is a general filename search code path (running through multiple files), and a procfs-specific code path. The choice between them begins in dmnt.c: it populates Mtprocfs if exactly one procfs mountpoint is found to activate the procfs-specific code path, otherwise it is set to NULL to fall back to the general code path. Then in arg.c that populates other variables.

Later in dnode.c, at the bottom of process_node(), if Ntype == N_PROC, the procfs-specific search takes place. If Mtprocfs was set then Procfsid will be set, and custom logic compares pids and inodes. If multiple procfs mountpoints existed, Mtprocfs wouldn't have been set, Procfsid is NULL, and nothing will ever match.

Even hacking around that, to make procfs files go through the general path (the Ntype != N_PROC case), it still fails to match. This is because is_file_named() requires a match on both dev and inode, and earlier in process_node(), N_PROC files have this run on them:

Lf->dev_def= Lf->rdev_def = 0;

causing is_file_named() to also never match.

Both issues should be fixed. If multiple procfs mounts should fall back to the general case, then it should fall back properly: the condition shouldn't be if (Ntype == N_PROC) but rather something like if (Ntype == N_PROC && Procfsid). Then either the dev on procfs should be treated as valid (with dev_def=1) (on FreeBSD it is valid and differs between mountpoints), or is_file_named() should have a custom search mode purely for procfs inodes that ignores dev.

(I also don't understand why we have the procfs-specific search path in the first place.)

I'll try fix to this in FreeBSD's dnode.c, but other dialects are beyond me.