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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <461F9076.4070209@amd.com>
Date:	Fri, 13 Apr 2007 16:15:18 +0200
From:	"Markus Rechberger" <markus.rechberger@....com>
To:	"Cornelia Huck" <cornelia.huck@...ibm.com>
cc:	"Alan Stern" <stern@...land.harvard.edu>,
	"USB development list" <linux-usb-devel@...ts.sourceforge.net>,
	"Kernel development list" <linux-kernel@...r.kernel.org>
Subject: Re: How should an exit routine wait for release() callbacks?

Cornelia Huck wrote:
> On Fri, 13 Apr 2007 13:42:04 +0200,
> "Markus Rechberger" <markus.rechberger@....com> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/