linux-kernel - Re: dmaengine: CPU stalls while loading bluetooth module

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 28 Mar 2024 12:21:26 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	parthiban@...umiz.com, saravanan@...umiz.com,
	'karthikeyan' <karthikeyan@...umiz.com>,
	"bumyong.lee" <bumyong.lee@...sung.com>
Subject: Re: dmaengine: CPU stalls while loading bluetooth module

On 26-03-24, 14:50, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Vinod Koul, what's your option here? We have two reports about
> regressions caused by 22a9d958581244 ("dmaengine: pl330: issue_pending
> waits until WFP state") [v6.8-rc1] now:
> 
> https://lore.kernel.org/lkml/1553a526-6f28-4a68-88a8-f35bd22d9894@linumiz.com/
> 
> https://lore.kernel.org/all/ZYhQ2-OnjDgoqjvt@wens.tw/
> [the first link points to the start of this thread]
> 
> To me it sounds like this is a change that better should be reverted,
> but you are of course the better judge here.

Sure I have reverted this, so original issue exist as is now...

> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> 
> On 20.03.24 07:28, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 20.03.24 01:49, bumyong.lee wrote:
> >>>>> Hmmm. 6.8 final is due. Is that something we can live with? Or would
> >>>>> it be a good idea to revert above commit for now and reapply it when
> >>>>> something better emerged? I doubt that the answer is "yes, let's do
> >>>>> that", but I have to ask.
> >>>>
> >>>> I couldn't find better way now.
> >>>> I think it's better to follow you mentioned
> >>>
> >>> 6.8 is out, but that issue afaics was not resolved, so allow me to ask:
> >>> did "submit a revert" fell through the cracks or is there some other
> >>> solution in the works? Or am I missing something?
> >>
> >> "submit a revert" would fix the issue. but it would make another issue
> >> that the errata[1] 719340 described.
> > 
> > "Make" as it "that other issue was present before the culprit was
> > applied"? Then that other issue does not matter due to the "no
> > regression" rule and how Linus afaics wants to see it applied in
> > practice. For details on the latter, see the quotes from him here:
> > https://docs.kernel.org/process/handling-regressions.html
> >  Hence please submit a revert (or tell me if I misunderstood something)
> > -- or of course a workaround for the other issue that does not cause the
> > regression people reported.
> > 
> >> [...]
> >> [1]: https://developer.arm.com/documentation/genc008428/latest
> > 
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
> > 
> > 
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> #regzbot poke

-- 
~Vinod