Re: diff-2.7.7 crashes on /proc/<pid>/maps

[Paul Eggert]

> From: Alexander Viro <address@hidden>
> Date: Wed, 30 Jan 2002 19:28:02 -0500 (EST)

> > Question: Is the kernel right in offering data of unknown size in the form
> > of a regular file?.
> 
> You can lseek on it, reads are non-blocking, etc.  Doesn't look like a named
> pipe semantics for me...

Presumably these files act like ordinary regular files, except that
they're read-only for ordinary processes and are constantly being
truncated and written to by the kernel.  In this "constantly being
truncated and rewritten" model, the kernel constantly truncates the
file to zero size (just before each user-program 'stat'), and
constantly then writes the appropriate data (just before each
user-program 'read').

I can think of one class of programs that this behavior will "break":
programs like 'cmp' and 'diff' that assume that, if two files' st_size
values differ, then the file contents differ.  For example, "cmp -s A
B" can exit with nonzero status if A and B's sizes differ; cmp doesn't
bother to read the files in that case.  This will result in weird
scenarios like the following:

1$ cat /proc/3428/maps >/tmp/maps
2$ cat /proc/3428/maps | cmp -s - /tmp/maps || echo differ
3$ cmp -s /proc/3428/maps /tmp/maps || echo differ
differ
4$ cat /proc/3428/maps | cmp -s - /tmp/maps || echo differ
5$ 

Advanced users who understand the model will figure out why command $3
always fails even though 2$ and 4$ succeed (assuming the process map
hasn't changed), but ordinary users will be puzzled.

I wouldn't be surprised if there are other little problems like this
in other programs.  This suggests that the problem should be
documented in the man page for 'proc'.  Perhaps you could mention the
"constantly being truncated and rewritten" model.

However, wouldn't it be better to change /proc so that the sizes are
correct, at least for the moment in time that 'stat' is applied?  That
would simplify a lot of this mess away, and would make life easier on
users.  It shouldn't be that hard to implement.  To some extent it is
just the price you have to pay for making the files regular.

Another simple fix, of course, is to go back to making them be
non-regular files.  This will mean that you can't lseek on them, but
that's not much of a real problem is it?  Reads can still be
non-blocking -- POSIX doesn't require them to block if data are always
available.

If neither of these changes are feasible, is there some cheap way that
programs like "cmp" can detect this anomalous situation, and treat
these /proc files as special even though S_ISREG reports them as
regular?  (It will be a bit of a pain to hack through all those
applications fixing these glitches, unfortunately, so I don't favor
this approach myself.)

On a more pedantic note: are all the requirements met for regular
files here?  For example, does mmap work?  Does record locking work?
Do poll and select work?  POSIX requires all of this stuff to work for
regular files.