netdev - RE: [PATCH iwl-next v2] ice: Disable Cage Max Power override

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]

Message-ID: <MW4PR11MB5776601FD7C2C577C78576A3FDE4A@MW4PR11MB5776.namprd11.prod.outlook.com>
Date: Fri, 1 Sep 2023 13:34:04 +0000
From: "Drewek, Wojciech" <wojciech.drewek@...el.com>
To: Ido Schimmel <idosch@...sch.org>
CC: Jakub Kicinski <kuba@...nel.org>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>, "idosch@...dia.com" <idosch@...dia.com>
Subject: RE: [PATCH iwl-next v2] ice: Disable Cage Max Power override



> -----Original Message-----
> From: Ido Schimmel <idosch@...sch.org>
> Sent: środa, 30 sierpnia 2023 17:17
> To: Drewek, Wojciech <wojciech.drewek@...el.com>
> Cc: Jakub Kicinski <kuba@...nel.org>; intel-wired-lan@...ts.osuosl.org;
> netdev@...r.kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>;
> idosch@...dia.com
> Subject: Re: [PATCH iwl-next v2] ice: Disable Cage Max Power override
> 
> On Tue, Aug 29, 2023 at 09:12:22AM +0000, Drewek, Wojciech wrote:
> > In some cases users are trying to use media with power exceeding max
> allowed value.
> > Port split require system reboot so it feels natural to me to restore default
> settings.
> 
> I don't believe it's the kernel's responsibility to undo changes done by
> external tools. Given that the tool is able to change this setting, I
> assume it can also restore it back to default.

I agree with that, but we can end up with no link if we don't restore
default settings. Let me explain how.

> 
> Moreover, it doesn't sound like port split won't work without this
> change, so placing this change there only because we assume that a
> reboot will follow seems random.

After port split, we might end up with no link in one of the ports.
In dual port card if we increase max pwr on the 1st cage the 2nd one
will have max pwr decreased automatically. This might be useful if we have port
option with count 1, the second cage is not used in this case. If we then split and
use two ports now, the second port will use second cage which has decreased max pwr, default module
used there will not work.

So, should we leave the restoration of the default settings to the user?

> 
> I think the best way forward is to extend ethtool as was already
> suggested. It should allow you to avoid the split brain situation where
> the hardware is configured by both the kernel and an external tool.

I'll try to follow up with the ethtool extension.