race in remove_proc_entry()

[Massimiliano Hofer <max@nucleus.it>]

Hi,
I found what I think is a nasty behaviour in procfs.

If I create a proc entry and rely on proc_file_read() and proc_file_write() to 
hand requests to dp->read_proc and dp->write_proc there is no protection from 
removal.

Example:
Process A            Process B
proc_file_read()
                     remove_proc_entry()
                     kfree(/* whatever was in dp->data */)
dp->read_proc()


read_proc() has no way to know if dp->data has been zeroed or freed since it 
was read by proc_file_read(). Process B has no way to know that a read is in 
progress.
Of course I can reimplement proc_file_read(), but this makes it pointless in 
the first place.
Most proc entries live as long as the kernel or the module that creates them, 
so this is a really rare problem, but there are simple precautions that could 
prevent it.

We could:
- add a per proc file lock (it could be optional);
- add an optional callback that allows us to perform whatever is needed when 
the file is really removed (remove_proc_entry() or de_put()).

The latter would be really simple and would allow for proper completion of 
read/write operations with whatever lock and protection is needed inside 
dp->data and possibly a simple kfree() performed by the disposal callback 
when everyone is really done.

-- 
Saluti,
   Massimiliano Hofer
        Nucleus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/