When a dynamically allocated `struct comedi_device` gets automatically
unconfigured by a call to `comedi_auto_unconfig()` from a lower-level
driver's bus removal function (e.g. when a USB device is disconnected),
the class device in `dev->class_dev` (where `dev` points to the `struct
comedi_device`) is destroyed by a call to `device_destroy()` that
matches a previous call to `device_create()`.

However, if the `struct comedi_device` is still associated with an open
file object, the now invalid `dev->class_dev` pointer may still be
passed to `dev_printk()` (via `dev_dbg()` etc.), producing bogus output
or worse.

To fix this, call `get_device()` on the class device if
`device_create()` was successful.  Add a matching call to `put_device()`
in `comedi_dev_kref_release()` when the `struct comedi_device` is freed.
The calls to `dev_dbg()` etc. after the call to `device_destroy()` will
still produce valid output, although the device will have been
unregistered in sysfs.

Signed-off-by: Ian Abbott <abbo...@mev.co.uk>
---
 drivers/staging/comedi/comedi_fops.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index cdaef09..6e5f538 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -91,6 +91,7 @@ static void comedi_dev_kref_release(struct kref *kref)
                container_of(kref, struct comedi_device, refcount);
 
        mutex_destroy(&dev->mutex);
+       put_device(dev->class_dev);
        kfree(dev);
 }
 
@@ -2514,7 +2515,7 @@ struct comedi_device *comedi_alloc_board_minor(struct 
device *hardware_device)
        csdev = device_create(comedi_class, hardware_device,
                              MKDEV(COMEDI_MAJOR, i), NULL, "comedi%i", i);
        if (!IS_ERR(csdev))
-               dev->class_dev = csdev;
+               dev->class_dev = get_device(csdev);
 
        /* Note: dev->mutex needs to be unlocked by the caller. */
        return dev;
-- 
1.8.4.4

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to