The ethtool ioctl interface used to guarantee that ethtool_ops callbacks were always called in a block between calls to ->begin() and ->complete() (if these are defined) and that this whole block was executed with RTNL lock held: rtnl_lock(); ops->begin(); /* other ethtool_ops calls */ ops->complete(); rtnl_unlock(); This prevented any nesting or crossing of the begin-complete blocks. However, this is no longer guaranteed even for ioctl interface as at least ethtool_phys_id() releases RTNL lock while waiting for a timer. With the introduction of netlink ethtool interface, the begin-complete pairs are naturally nested e.g. when a request triggers a netlink notification. Fortunately, only minority of networking drivers implements begin() and complete() callbacks and most of those that do, fall into three groups: - wrappers for pm_runtime_get_sync() and pm_runtime_put() - wrappers for clk_prepare_enable() and clk_disable_unprepare() - begin() checks netif_running() (fails if false), no complete() First two have their own refcounting, third is safe w.r.t. nesting of the blocks. Only three in-tree networking drivers need an update to deal with nesting of begin() and complete() calls: via-velocity and epic100 perform resume and suspend on their own and wil6210 completely serializes the calls using its own mutex (which would lead to a deadlock if a request request triggered a netlink notification). The series addresses these problems. Michal Kubecek (3): wil6210: get rid of begin() and complete() ethtool_ops via-velocity: allow nesting of ethtool_ops begin() and complete() epic100: allow nesting of ethtool_ops begin() and complete() drivers/net/ethernet/smsc/epic100.c | 7 +++- drivers/net/ethernet/via/via-velocity.c | 14 +++++-- drivers/net/ethernet/via/via-velocity.h | 1 + drivers/net/wireless/ath/wil6210/ethtool.c | 43 ++++++++-------------- 4 files changed, 32 insertions(+), 33 deletions(-) -- 2.24.1
