在 2023/12/5 下午4:35, Jason Wang 写道:
On Tue, Dec 5, 2023 at 4:02 PM Heng Qi <hen...@linux.alibaba.com> wrote:
Currently access to ctrl cmd is globally protected via rtnl_lock and works
fine. But if dim work's access to ctrl cmd also holds rtnl_lock, deadlock
may occur due to cancel_work_sync for dim work.
Can you explain why?
For example, during the bus unbind operation, the following call stack
occurs:
virtnet_remove -> unregister_netdev -> rtnl_lock[1] -> virtnet_close ->
cancel_work_sync -> virtnet_rx_dim_work -> rtnl_lock[2] (deadlock occurs).
Therefore, treating
ctrl cmd as a separate protection object of the lock is the solution and
the basis for the next patch.
Let's don't do that. Reasons are:
1) virtnet_send_command() may wait for cvq commands for an indefinite time
Yes, I took that into consideration. But ndo_set_rx_mode's need for an
atomic
environment rules out the mutex lock.
2) hold locks may complicate the future hardening works around cvq
Agree, but I don't seem to have thought of a better way besides passing
the lock.
Do you have any other better ideas or suggestions?
Thanks!
Thanks
