[PATCH v12 10/26] nvme-tcp: Deal with netdevice DOWN events
Sagi Grimberg
sagi at grimberg.me
Sun Aug 20 03:50:47 PDT 2023
>>>>> + switch (event) {
>>>>> + case NETDEV_GOING_DOWN:
>>>>> + mutex_lock(&nvme_tcp_ctrl_mutex);
>>>>> + list_for_each_entry(ctrl, &nvme_tcp_ctrl_list, list) {
>>>>> + if (ndev == ctrl->offloading_netdev)
>>>>> + nvme_tcp_error_recovery(&ctrl->ctrl);
>>>>> + }
>>>>> + mutex_unlock(&nvme_tcp_ctrl_mutex);
>>>>> + flush_workqueue(nvme_reset_wq);
>>>>
>>>> In what context is this called? because every time we flush a workqueue,
>>>> lockdep finds another reason to complain about something...
>>>
>>> Thanks for highlighting this, we re-checked it and we found that we are
>>> covered by nvme_tcp_error_recovery(), we can remove the
>>> flush_workqueue() call above.
>>
>> Don't you need to flush at least err_work? How do you know that it
>> completed and put all the references?
>
> Our bad, we do need to wait for the netdev reference to be put, and we
> must keep the flush_workqueue().
>
> We did test with lockdep but did not notice any warnings.
I'm assuming you are running with lockdep and friends?
>
> As for the context of the event handler when you set the link down is
> the process issuing the netlink syscall.
>
> So if you run "ip link set X down" it would be (simplified):
>
> "ip" -> syscall -> netlink api -> ... -> do_setlink -> call_netdevice_notifiers_info.
ok, that should be fine I think.
More information about the Linux-nvme
mailing list