On 4/27/2015 7:22 PM, Jason Gunthorpe wrote:
On Mon, Apr 27, 2015 at 11:25:56AM +0300, Matan Barak wrote:
On 4/26/2015 11:10 PM, Or Gerlitz wrote:
On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
<[email protected]> wrote:
From: Matan Barak <[email protected]>
Previously. we used device_mutex lock in order to protect
the device's list. That means that in order to guarantee a
device isn't freed while we use it, we had to lock all
devices.
Matan, looking on the cover letter, it says: "[...] Patch 0002 adds a
reference count mechanism to IB devices. This mechanism is similar to
dev_hold and dev_put available for net devices. This is mandatory for
later patches [...]"
So in that respect, saying here "Previously. we used device_mutex
lock" is a bit cryptic, @ least one typo must exist in this sentence,
right? did you want to say "Currently we use device_mutex lock for XXX
[...] and this should be replaced as of a YYY change which is to be
introduced [...]" please clarify
Correct, I'll change that into:
Currently we use device_mutex lock for protecting the device's list.
In the current approach, in order to guarantee a device isn't freed
we have to lock all devices.
Adding a kref per IB device. Before an IB device is unregistered, we
wait until it's not held anymore.
Why do we need two krefs for this structure? There is already a kref
inside the embedded 'struct device dev'
Sounds wrong to me without a lot more explanation.
This was already asked by Haggai Eran awhile ago and was answered.
Anyway, in ib_unregister_device we delete all client's related data.
We would like to ensure that all references were released before this
data is being deleted. Meaning, we would like to ensure the device is
still functioning but isn't referenced rather than just to avoid freeing
the IB device's memory.
ib_device_get and ib_device_hold are APIs for the clients, similar to
dev_hold and dev_put.
Jason
Regards,
Matan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
