On Thu, May 31, 2018 at 1:08 PM, Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
>
>>>
>>> Why is this not needed for others as well?
>>
>>
>> Well, I can only consider nvme case, why it is not needed there, but in
>> other ULPs that can be probably a bug or they have other protections,
>> I do not know (seems net/rds/ib.c does nice things).
>>
>> *_remove_one() callback will be firstly called if device is dying and
>> only then cm_handler() will get RDMA_CM_EVENT_DEVICE_REMOVAL. Order
>> matters.
>>
>> NVMe host and target do flush_scheduled_work() in
>> nvme[t]_rdma_remove_one(),
>> thus it is guaranteed that *_remove_one() is the last one who puts the
>> reference on the device, i.e.:
>>
>> nvmet_rdma_remove_one(...)
>> {
>> ...
>> flush_scheduled_work();
>> WARN_ON(!nvmet_rdma_dev_put(ndev));
>> }
>>
>
> I think it would be a good idea to do the same for iser.
> If you don't have time, keep it as is, I'll try to find some time
> to get it incrementally.
I will take a look, but I am not sure that I can come up quickly
with something. Seems not a trivial change which can bring
another global lists with locks and stuff, but probably I am
mistaken.
And Sagi, could you please share with me any script to setup iser
target and initiator? Frankly speaking I've never did that.
On the next iteration with this series would be nice if I could
test my iser patches :)
--
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
