在 2023/12/5 下午4:35, Jason Wang 写道:

On Tue, Dec 5, 2023 at 4:02 PM Heng Qi [off-list ref] wrote:

quoted

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).

quoted

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