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: <20250424171856.GK3042781@horms.kernel.org>
Date: Thu, 24 Apr 2025 18:18:56 +0100
From: Simon Horman <horms@...nel.org>
To: Jacek Kowalski <jacek@...ekk.info>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"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] e1000e: disregard NVM checksum on tgp when valid
 checksum mask is not set

On Thu, Apr 24, 2025 at 06:46:45PM +0200, Jacek Kowalski wrote:
> > > Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
> > > checksum")
> > 
> > I think that while the commit cited above relates to this problem, this
> > bug actually dates back to the patch I'm citing immediately below. And I
> > think we should cite that commit here. IOW, I'm suggesting:
> > 
> > Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
> 
> I had my doubts when choosing a commit for the "Fixes" tag, but since
> my setup would most likely work up until 4051f68318ca9, I selected it
> specifically.
> 
> On my laptop NVM write attempt does (temporarily) fix a checksum
> and makes driver loading possible. Only after 4051f68318ca9, which
> disabled this code path (because it broke someone else's setup), I'd
> be unable to use my network adapter anymore.

Thanks, in that case things aren't as clear as I had assumed
when writing my previous email.

If the problem only occurs after 4051f68318ca9 then I think
it is fine to use that commit in the Fixes tag.

Although I do wonder if commit 4051f68318ca9 is backported,
will this patch (once accepted) end up being backported far enough?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ