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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
