On 10/23/2017 04:51 PM, Christoph Hellwig wrote:
> Instead of allocating a separate struct device for the character device
> handle embedd it into struct nvme_ctrl and use it for the main controller
> refcounting. This removes double refcounting and gets us an automatic
> reference for the
Instead of allocating a separate struct device for the character device
handle embedd it into struct nvme_ctrl and use it for the main controller
refcounting. This removes double refcounting and gets us an automatic
reference for the character device operations. We keep ctrl->device as a
pointer
On Thu, Oct 19, 2017 at 01:33:55PM +0300, Sagi Grimberg wrote:
>> Well, the ctrl device integration is what enables us to do this.
>> Before that the ctrl refcount could have reached null by the time
>> we call the delete_ctrl method.
>
> OK, maybe a change log mention then?
I thought I did that,
By the time we call ->delete_ctrl in nvmf_create_ctrl we must still
have that reference because we are still in a ->write call and thus
->release can't have been called yet.
Thanks for the clarification. Is it worth a preparatory patch to
change that before the ctrl device integration for
On Thu, Oct 19, 2017 at 01:02:59PM +0300, Sagi Grimberg wrote:
>> By the time we call ->delete_ctrl in nvmf_create_ctrl we must still
>> have that reference because we are still in a ->write call and thus
>> ->release can't have been called yet.
>
> Thanks for the clarification. Is it worth a
I don't think the fabrics device does not help us to keep the ctrl
allocated until we finish removal.
All fabrics drivers grab an extra reference during ->create_ctrl,
which we will drop when releasing the file descriptor that we used
to create the device.
By the time we call ->delete_ctrl
On Thu, Oct 19, 2017 at 10:31:20AM +0300, Sagi Grimberg wrote:
> I don't think the fabrics device does not help us to keep the ctrl
> allocated until we finish removal.
All fabrics drivers grab an extra reference during ->create_ctrl,
which we will drop when releasing the file descriptor that we
- if (!kref_get_unless_zero(>ctrl.kref))
- return -EBUSY;
+ nvme_get_ctrl(>ctrl);
Given that we take this reference before we are protected with
the state change I think this should still be get_unless_zero.
Because we now refcount the device we must have a
On Thu, Oct 19, 2017 at 10:17:01AM +0300, Sagi Grimberg wrote:
>
>
>> -if (!kref_get_unless_zero(>ctrl.kref))
>> -return -EBUSY;
>> +nvme_get_ctrl(>ctrl);
>
> Given that we take this reference before we are protected with
> the state change I think this should still be
- if (!kref_get_unless_zero(>ctrl.kref))
- return -EBUSY;
+ nvme_get_ctrl(>ctrl);
Given that we take this reference before we are protected with
the state change I think this should still be get_unless_zero.
Maybe we can introduce get_device_unless_zero() for this?
Instead of allocating a separate struct device for the character device
handle embedd it into struct nvme_ctrl and use it for the main controller
refcounting. This removes double refcounting and gets us an automatic
reference for the character device operations. We keep ctrl->device as a
pointer
11 matches
Mail list logo
