At 01:04 AM 10/25/2002 +0200, Oliver Neukum wrote:
So this is safe if, and only if, remove_proc_entry waits
for current readers to finish before it returns.
As far as I can tell, this is not the case.
So reading from the proc file while the camera is disconnected is
potentially deadly. I see no e
At 10:35 AM 10/25/2002 +0200, Oliver Neukum wrote:
So in your read the easiest fix would be not to let proc pass you a pointer
to a device descriptor, but an offset into a table of pointers to device
descriptors which you can protect with a spinlock.
Probe and disconnect would have to update the t
Am Freitag, 25. Oktober 2002 09:42 schrieb Joe Burks:
> At 01:04 AM 10/25/2002 +0200, Oliver Neukum wrote:
> >So this is safe if, and only if, remove_proc_entry waits
> >for current readers to finish before it returns.
> >As far as I can tell, this is not the case.
> >
> >So reading from the proc f
Hi,
the recent discussion on procfs and driverfs caused me to look at the
existing uses with respect to races against disconnect.
I think I found something in stv680, the second driver I looked at.
from usb_stv680_remove_disconnected:
#if defined(CONFIG_PROC_FS) && defined(CONFIG_VIDEO_PROC_FS)
