Re: How should an exit routine wait for release() callbacks?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux