From: Jakub Kicinski <kuba@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Ziwei Xiao <ziweixiao@google.com>,
Praveen Kaligineedi <pkaligineedi@google.com>,
Harshitha Ramamurthy <hramamurthy@google.com>,
Willem de Bruijn <willemb@google.com>,
Jeroen de Borst <jeroendb@google.com>,
Shailend Chand <shailend@google.com>,
netdev@vger.kernel.org, eric.dumazet@gmail.com
Subject: Re: [PATCH net-next 3/6] net: ethtool: perform pm duties outside of rtnl lock
Date: Thu, 20 Jun 2024 17:22:35 -0700 [thread overview]
Message-ID: <20240620172235.6e6fd7a5@kernel.org> (raw)
In-Reply-To: <20240620114711.777046-4-edumazet@google.com>
On Thu, 20 Jun 2024 11:47:08 +0000 Eric Dumazet wrote:
> Move pm_runtime_get_sync() and pm_runtime_put() out of __dev_ethtool
> to dev_ethtool() while RTNL is not yet held.
>
> These helpers do not depend on RTNL.
The helpers themselves don't, but can we assume no drivers have
implicit dependencies on calling netif_device_detach() under rtnl_lock,
and since the presence checks are under rtnl_lock they are currently
guaranteed not to get any callbacks past detach() + rtnl_unlock()?
I think its better to completely skip PM + presence + ->begin if driver
wants the op to be unlocked, but otherwise keep the locking as is
I also keep wondering whether we shouldn't use this as an opportunity
to introduce a "netdev instance lock". I think you mentioned we should
move away from rtnl for locking ethtool and ndos since most drivers
don't care at all about global state. Doing that is a huge project,
but maybe this is where we start?
next prev parent reply other threads:[~2024-06-21 0:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 11:47 [PATCH net-next 0/6] net: ethtool: reduce RTNL pressure in dev_ethtool() Eric Dumazet
2024-06-20 11:47 ` [PATCH net-next 1/6] net: ethtool: grab a netdev reference " Eric Dumazet
2024-06-20 11:47 ` [PATCH net-next 2/6] net: ethtool: add dev_ethtool_cap_check() Eric Dumazet
2024-06-20 11:47 ` [PATCH net-next 3/6] net: ethtool: perform pm duties outside of rtnl lock Eric Dumazet
2024-06-21 0:22 ` Jakub Kicinski [this message]
2024-06-21 0:59 ` Andrew Lunn
2024-06-21 2:11 ` Jakub Kicinski
2024-06-21 4:16 ` Eric Dumazet
2024-06-20 11:47 ` [PATCH net-next 4/6] net: ethtool: call ethtool_get_one_feature() without RTNL Eric Dumazet
2024-06-20 11:47 ` [PATCH net-next 5/6] net: ethtool: implement lockless ETHTOOL_GFLAGS Eric Dumazet
2024-06-20 11:47 ` [PATCH net-next 6/6] net: ethtool: add the ability to run ethtool_[gs]et_rxnfc() without RTNL Eric Dumazet
2024-06-20 17:45 ` Willem de Bruijn
2024-06-20 18:29 ` Eric Dumazet
2024-06-20 17:58 ` [PATCH net-next 0/6] net: ethtool: reduce RTNL pressure in dev_ethtool() Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240620172235.6e6fd7a5@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=hramamurthy@google.com \
--cc=jeroendb@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pkaligineedi@google.com \
--cc=shailend@google.com \
--cc=willemb@google.com \
--cc=ziweixiao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.