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

Message-ID: <b888cbe2-6071-4445-91cd-8ce7cc9cc8f4@leemhuis.info>
Date: Sat, 9 Mar 2024 15:06:38 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Nícolas F. R. A. Prado <nfraprado@...labora.com>,
 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>
Cc: 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 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.

> 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.

Ciao, Thorsten