Cornelia Huck wrote:
On Fri, 13 Apr 2007 13:42:04 +0200,
"Markus Rechberger" <[email protected]> wrote:
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device till the last user closed the device node.
Probably dumb question (since I'm not at all familiar with the dvb
code): Isn't that a different race you're solving there? I don't see
any driver core objects involved (except class devices created by
class_device_create, which obviously don't have the release function
problem). This looks more like a race of "we want an object to go
away, but a user still has a file open" (which would be similar to the
kobject<->sysfs lifetime rules issues, where work is currently ongoing).
most dvb usb drivers call the device node unregistration when a device
gets unplugged (when
At this time the filehandle can still be open, the patch on that site
sets a flag that disallows
any further access to the device node (in the DVB framework there are 4
of such nodes)
This can happen any time, so while someone is reading or accessing the
device some structures
might have gone away already and this could cause an oops.
The problem of the DVB framework is file operation related, the last
user calls fops_put on the existing
structure and sets the pointer to NULL before it wakes up the other
function which frees the file operation
structure.
In Alan's case isn't there any users flag available that shows that the
structure is still beeing accessed?
If that would be the case he could set a flag when he enters my_exit
which would disable access to all other
functions by returning an error value at the beginning of the other
functions, the only way out would be
to call my_release for existing users and wake up my_exit when the last
reference to that structure is gone.
Some more information about the whole driver/scenario would be helpful.
Markus
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
-
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]
