netdev - Re: [RFC PATCH] net: ethtool: do runtime PM outside RTNL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 4 Dec 2023 14:22:17 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Marc MERLIN <marc@...lins.org>, netdev@...r.kernel.org, Jesse Brandeburg
 <jesse.brandeburg@...el.com>, Tony Nguyen <anthony.l.nguyen@...el.com>,
 intel-wired-lan@...ts.osuosl.org, Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [RFC PATCH] net: ethtool: do runtime PM outside RTNL

On Mon, 04 Dec 2023 22:32:25 +0100 Johannes Berg wrote:
> Well, I was hoping that
> 
>  (a) ethtool folks / Jakub would comment if this makes sense, but I
>      don't see a good reason to do things the other way around (other
>      than "code is simpler"); and

My opinion on RPM is pretty uneducated. But taking rtnl_lock to resume
strikes me as shortsighted. RPM functionality should be fairly
self-contained, and deserving of a separate lock.
Or at the very least having looked at the igc RPM code in the past,
I'm a bit cautious about bending the core to fit it, as it is hardly
a model...

>  (b) Intel wired folks could help out with getting the patch across the
>      finish line, seeing how their driver needs it :) I think the dev
>      get/put needs to use the newer API, but I didn't immediately see
>      how that works locally in a function without an allocated tracker