On Tue, Feb 21, 2017 at 04:54:05PM -0700, Logan Gunthorpe wrote:
Is that true? Once device_register or device_add is called then you
to use put_device.
General rule is once kref_init has been called then you should use
kref_put and not kfree.
device_initialize ultimately calls kref_init..
Reasoning that you don't 'need' to use put_device until device_add is
just too hard.
For instance, there is still another bug in ib_ucm_add_one:
if (device_create_file(&ucm_dev->dev, &dev_attr_ibdev))
If we go down the err_dev path then device_unregister will probably
kfree ucm_dev - the argument is not guarenteed valid after
device_unregister returns - this is what makes it different from
The simplest fix is to change the unwind into:
And the only way to keep our idiomatic goto unwind working is if all
'goto errs' can call put_device - which requires the device_initialize
be done before any errors are possible.
In fact device_add is what does the first get_device so this
add up to me.
Not quite, kref_init creates a kref with a count of 1 - eg the caller
owns the ref, and that ref must be put to trigger kref release.
Thus good kref usage should always pair a kref_put with the kref_init.
The get_device at the start of device_add pairs with the put_device at
the end of device_del and the kref_init pairs with the put_device at
the end of device_unregister. (notice that device_unregister ends up
calling put_device twice in a row..)
I'll send you a clean patch for your v2.
I know the DAX code only uses put_device after device_add.
Looks to me like that code fails to call cdev_del if device_add fails?
This approach is problematic because it is trying do the ida removals
in the release function. That is not necessary and has the side effect
of making the release function uncallable until too late in the