linux-kernel - Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

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: <2025040230-showoff-spray-ac83@gregkh>
Date: Wed, 2 Apr 2025 12:31:13 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc: linux-kernel@...r.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
> HI Greg,
> 
> On 01/04/2025 20:18, Greg KH wrote:
> > On Sun, Mar 09, 2025 at 02:56:50PM +0000, srinivas.kandagatla@...aro.org wrote:
> > > From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
> > > 
> > > Hi Greg,
> > > 
> > > Here are few nvmem patches for 6.15, Could you queue
> > > these for 6.15.
> > > 
> > > patche include
> > > 	- updates to bindings to include MSM8960, X1E80100, MS8937,
> > > 	  IPQ5018
> > > 	- add support to bit offsets for register strides exceeding
> > > 	  single byte
> > > 	- add rockchip-otp variants.
> > > 	- Few enhancements in qfprom and rochchip nvmem providers.
> > 
> > Ok, I wanted to apply these, and tried to, but they fail horribly
> > because:
> > 
> > Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
> > 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> > 	Has these problem(s):
> > 		- Target SHA1 does not exist
> > Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit reading is required")
> > 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> > 	Has these problem(s):
> > 		- Target SHA1 does not exist
> > Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one byte")
> > 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> > 	Has these problem(s):
> > 		- Target SHA1 does not exist
> 
> Looks some of your scripts or b4 is picking up older version v1 of the
> patchset
> 
> None of the above patches have Fixes tags in the V2 patches that I shared
> aswell as patches in linux-next.

Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.

But, that's even worse.  Those "fixes" are now not actually marked as
fixes of the previous patch.  So that information is totally lost, and
again, the first commit here, "nvmem: core: verify cell's raw_len" is
broken so much that it took 3 other changes to fix it, which implies
that bisection would cause problems if you hit it in the middle here.

While fixing patches is great, and something we do in the tree all the
time, let's not purposefully break things and then fix them up in the
same exact patch series please.  That's just sloppy engineering.

Please redo this series completely.  I can take the "new device support"
patches at any time, and really, those should be marked with Cc: stable
to get backported, right?  The other ones are written as if they are
fixes, so again, I can take them any time, no need to wait for the -rc1
merge cycle.

thanks,

greg k-h