Re: 2.1.57 /proc problem

Bill Hawes (
Tue, 30 Sep 1997 08:03:16 -0400

Richard Guenther wrote:
> > Does your /proc code install a custom inode_operations in the inodes?
> No it doesnt, it uses the create_proc_entry/remove_proc_entry interface
> from fs/proc/generic.c
> The problem manifested in having two files with the same inode, catting
> the first gives contents of the second and other weirdness.

I modified put_inode to kill off unused inodes immediately to prevent
this. Since inode numbers in /proc may get recycled, you need to
dispose of the previous incarnation when the use count goes to 0.

> Another problem related to proc and binfmt_misc is a race condition I
> can trigger (by doing extremly stress testing on the binfmt_misc interface)
> is removing the binfmt_entry (and freeing the proc_dir_entry) while
> another process has opened the file, the subsequent catting of the file
> leads to an oops (obviously, the proc_dir_entry and the binfmt data
> structure are no longer there). This race condition is there for every
> proc file that gets removed, but its really easy to tigger with binfmt_misc.
> (This one is probably not worth fixing)

I disagree, this most certainly should be fixed. The binfmt entries
should have a use count tied to the number of file openers. If the
problem exists for all /proc files, we should try to figure a way to fix
is globally rather than having each /proc entry to something.

One possibility that comes to mind would be to use delete_inode to
decrement a use count and free the entry. I'll take a look at
proc/generic and think about this.