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: Thu, 14 Mar 2024 13:31:33 -0700
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Erwan Velu <e.velu@...teo.com>, Brett Creeley <bcreeley@....com>, "Erwan
 Velu" <erwanaliasr1@...il.com>
CC: Jesse Brandeburg <jesse.brandeburg@...el.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 iwl-net] i40e: Prevent setting MTU if greater than MFS



On 3/14/2024 11:04 AM, Erwan Velu wrote:
> 
> Le 14/03/2024 à 18:55, Brett Creeley a écrit :
>> [...]
>> AFAIK there is no API for a user to change the max_mtu, so the only way
>> the device's MFS would need to change is if it's done during
>> initialization time, which should be done before netdev registration 
>> anyway.
> 
> Sorry Brett, I was probably unclear and please note that I'm not a 
> network developer, just a user that faced a bug.
> 
> My initial though was to check the mfs size in i40e_change_mtu() and if 
> mfs is too small, then let's increase it.
> 
> Maybe just resetting it at init time to the largest value (which seems 
> to be the default fw behavior) is a best approach.
> 
> I'd love to ear from Intel dev that knows this driver/cards/fw better on 
> what's the best approach here.

Setting the mfs size to max values during init and reset would better; 
this is what the ice driver does. However, this would take implementing 
new AdminQ calls. IMO this patch is ok to prevent the issue being 
reported and allow for ease of backport.

Thanks,
Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ