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.
Regards,
Bill