linux-kernel - Re: Probe regression of efuse@...10000 on mt8183-kukui-jacuzzi-juniper-sku16 running next-20240202

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] [day] [month] [year] [list]

Date: Mon, 11 Mar 2024 09:54:09 -0400
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Chen-Yu Tsai <wenst@...omium.org>, regressions@...ts.linux.dev,
	linux-mediatek@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kernel@...labora.com
Subject: Re: Probe regression of efuse@...10000 on
 mt8183-kukui-jacuzzi-juniper-sku16 running next-20240202

On Sat, Mar 09, 2024 at 03:06:38PM +0100, Thorsten Leemhuis wrote:
> On 08.03.24 15:31, Nícolas F. R. A. Prado wrote:
> > On Tue, Feb 06, 2024 at 11:11:00AM -0500, Nícolas F. R. A. Prado wrote:
> >>
> >> KernelCI has identified a regression [1] on the
> >> mt8183-kukui-jacuzzi-juniper-sku16 machine running on next-20240202 compared to
> >> next-20240118:
> >>
> >> #regzbot introduced next-20240118..next-20240202
> > 
> > Not sure why this got filed by regzbot under the mainline tab rather than next.
> > Maybe it was the missing collon? 
> 
> No, I guess that is a bug in regzbot: the support for -next is there,
> but not much tested. Will need to take a closer look, will do so in the
> next few days.

Ah ok, that's good to know.

> 
> > In any case, the fix has already made it to linux-next, so this should close the
> > regression:
> >
> > #regzbot fix: nvmem: mtk-efuse: Drop NVMEM device name
> 
> Out of interest: Is involving regzbot worth it in case the fix is
> already in -next? Or is that primarily to keep track of "we found a
> regression and a fix was already available in next". I don't mind if
> it's the latter, just curious.

When the fix has already landed in next, no, I guess it wouldn't make sense to
involve regzbot, as that would be like creating a regression ticket that is
closed from the start. (And basically it would mean we're testing an outdated
kernel release, which is not very helpful)

In this case when I sent the regression report the regression was still there on
the latest next. The fix had been sent, but not yet merged into next. In that
case it's very much helpful to involve regzbot so we can track the fix and make
sure it gets applied. Also, as was for this case, and probably many others, the
fix patch didn't have that much information on the symptoms and circumstances of
the issue, while the regression report I sent did, so the regression report
should be easier to find for people encountering the regression, and then they
can easily see the status of the regression through regzbot.

Thanks,
Nícolas