On Monday, January 07, 2013 4:23 PM, Greg Kroah-Hartman wrote:
> On Wed, Jan 02, 2013 at 04:21:23PM +0000, Ian Abbott wrote:
>> When a low-level comedi driver auto-configures a device, a `struct
>> comedi_dev_file_info` is allocated (as well as a `struct
>> comedi_device`) by `comedi_alloc_board_minor()`.  A pointer to the
>> hardware `struct device` is stored as a cookie in the `struct
>> comedi_dev_file_info`.  When the low-level comedi driver
>> auto-unconfigures the device, `comedi_auto_unconfig()` uses the cookie
>> to find the `struct comedi_dev_file_info` so it can detach the comedi
>> device from the driver, clean it up and free it.
>> 
>> A problem arises if the user manually unconfigures and reconfigures the
>> comedi device using the `COMEDI_DEVCONFIG` ioctl so that is no longer
>> associated with the original hardware device.  The problem is that the
>> cookie is not cleared, so that a call to `comedi_auto_unconfig()` from
>> the low-level driver will still find it, detach it, clean it up and free
>> it.
>> 
>> Stop this problem occurring by always clearing the `hardware_device`
>> cookie in the `struct comedi_dev_file_info` whenever the
>> `COMEDI_DEVCONFIG` ioctl call is successful.
>> 
>> Signed-off-by: Ian Abbott <[email protected]>
>> Cc: [email protected]
>> ---
>> @Greg: This was originally sent on 4th December.  It clashes with
>> Hartley's "[PATCH 04/26] staging: comedi: use comedi_dev_from_minor()"
>> of 19th December.  It would be nice if my patch takes precedence so that
>> it can be used as-is in the stable kernels, though unfortunately that
>> would require a slight re-work of Hartley's patch.
>
> I've applied this, and Hartley's patches, and merged the branches
> together.  I've fixed up the obvious build error, can both of you verify
> that I didn't do anything wrong?  It should be in the staging-next
> branch now.

Look good to me.

Thanks,
Hartley

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to