`test_all` fails reproducibly on `pasta` `(please report this procfs bug)`

[NoisyCoil]

The test_all test fails reproducibly when running alongside pasta, asking the user to report the procfs bug:

---- process::tests::test_all stdout ----
1 systemd
[...]
382759 pasta
thread 'process::tests::test_all' panicked at procfs/src/process/tests.rs:18:21:
check_unwrap error for 382759 InternalError(bug at procfs-core/src/process/mount.rs:181 (please report this procfs bug)
Internal Unwrap Error: NoneError)

failures:
    process::tests::test_all

To reproduce, e.g. in Debian (testing), install pasta (apt install passt), execute pasta and leave the session open, then in a separate terminal run cargo test on current main.

I discovered this while running podman, which executes pasta.

[eminence]

I confirm this is easy to reproduce. The problem is that the mountinfo file for the pasta process looks like this:

1558 1516 0:127 / / ro,nosuid,nodev,noexec,relatime - tmpfs  ro,seclabel,size=0k,nr_inodes=2,uid=1000,gid=1000,inode64

Normally there should be 3 fields after the - separator. But we only see two here. I suspect the middle field is actually empty; notice the two consecutive spaces, which is highly unusual.

So this feels like a kernel bug (I think it should print none instead?), but we can work around this in procfs I think

[NoisyCoil]

This also happens for the other mount* files:

$ cat /proc/633543/mount{info,s,stats}
880 845 0:93 / / ro,nosuid,nodev,noexec,relatime - tmpfs  ro,size=0k,nr_inodes=2,uid=1000,gid=1000,inode64
 / tmpfs ro,nosuid,nodev,noexec,relatime,size=0k,nr_inodes=2,uid=1000,gid=1000,inode64 0 0
device  mounted on / with fstype tmpfs

Note the empty first field on the second line (mounts) and second field on the third line (mountstats). All three files are defined in fs/proc_namespace.c, and in all three mnt_devname is replaced with none (or no device for mountstats) only if it is null, but not if it's empty. If this is the intended behavior it's not documented in the proc_pid_mount* manpages.

[NoisyCoil]

Looks like it's intended and not documented? See e.g. https://lore.kernel.org/all/20240715-abgibt-akkreditieren-7ac23ec2413c@brauner/, which is a reply to a patch that tried to fix this behavior.

[eminence]

Nice find, thank you. This makes our parsing job a little harder, but that's ok. A primary goal of this procfs crate is to handle these weird edge cases that most people won't know about.

[eminence]

This should be fixed now. Thanks for reporting this bug!