From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Johannes Berg <johannes@sipsolutions.net>, <netdev@vger.kernel.org>
Cc: Johannes Berg <johannes.berg@intel.com>,
Marc MERLIN <marc@merlins.org>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
intel-wired-lan@lists.osuosl.org,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [Intel-wired-lan] [RFC PATCH] net: ethtool: do runtime PM outside RTNL
Date: Tue, 5 Dec 2023 06:19:15 +0100 [thread overview]
Message-ID: <d0fc7d04-e3c9-47c0-487e-666cb2a4e3bc@intel.com> (raw)
In-Reply-To: <20231204200710.40c291e60cea.I2deb5804ef1739a2af307283d320ef7d82456494@changeid>
On 12/4/23 20:07, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> As reported by Marc MERLIN in [1], at least one driver (igc)
perhaps Reported-by tag? (I know this is RFC as of now)
> wants/needs to acquire the RTNL inside suspend/resume ops,
> which can be called from here in ethtool if runtime PM is
> enabled.
>
> [1] https://lore.kernel.org/r/20231202221402.GA11155@merlins.org
>
> Allow this by doing runtime PM transitions without the RTNL
> held. For the ioctl to have the same operations order, this
> required reworking the code to separately check validity and
> do the operation. For the netlink code, this now has to do
> the runtime_pm_put a bit later.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/ethtool/ioctl.c | 71 ++++++++++++++++++++++++++-----------------
> net/ethtool/netlink.c | 32 ++++++++-----------
> 2 files changed, 56 insertions(+), 47 deletions(-)
>
Thank you for the patch,
I like the idea of split into validate + do for dev_ethtool(),
what minimizes unneeded PM touching. Moving pm_runtime_get_sync() out of
RTNL is also a great improvement per se. Also from the pure coding
perspective I see no obvious flaws in the patch. I think that igc code
was just accidental to the issue, in a way that it was not deliberate to
hold RTNL for extended periods. With your patch fixing the bug, there is
no point with waiting IMO, so
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-12-05 5:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 19:07 [Intel-wired-lan] [RFC PATCH] net: ethtool: do runtime PM outside RTNL Johannes Berg
[not found] ` <20231204200038.GA9330@merlins.org>
[not found] ` <a6ac887f7ce8af0235558752d0c781b817f1795a.camel@sipsolutions.net>
2023-12-04 20:36 ` Marc MERLIN
2023-12-04 20:40 ` Johannes Berg
2023-12-04 20:54 ` Marc MERLIN
2023-12-04 21:28 ` Marc MERLIN
2023-12-04 21:32 ` Johannes Berg
2023-12-04 22:22 ` Jakub Kicinski
2023-12-04 22:25 ` Johannes Berg
2023-12-05 2:46 ` Marc MERLIN
2023-12-05 19:33 ` Johannes Berg
2023-12-05 5:19 ` Przemek Kitszel [this message]
2023-12-05 19:48 ` Johannes Berg
2023-12-06 8:46 ` Przemek Kitszel
2023-12-06 9:37 ` Johannes Berg
2023-12-06 11:59 ` Heiner Kallweit
2024-01-03 8:20 ` Stanislaw Gruszka
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=d0fc7d04-e3c9-47c0-487e-666cb2a4e3bc@intel.com \
--to=przemyslaw.kitszel@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=hkallweit1@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=marc@merlins.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox