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: <96516ac6-777a-469a-b5d3-9897a0e40de5@vt.edu>
Date: Tue, 29 Apr 2025 15:17:33 -0500
From: Carlos Bilbao <bilbao@...edu>
To: Andrew Morton <akpm@...ux-foundation.org>, carlos.bilbao@...nel.org
Cc: tglx@...utronix.de, seanjc@...gle.com, jan.glauber@...il.com,
 pmladek@...e.com, jani.nikula@...el.com, linux-kernel@...r.kernel.org,
 gregkh@...uxfoundation.org, takakura@...inux.co.jp,
 john.ogness@...utronix.de, x86@...nel.org
Subject: Re: [PATCH v3 0/2] Reduce CPU consumption after panic

Hey Andrew,

On 4/29/25 15:39, Andrew Morton wrote:
> (cc more x86 people)
> 
> On Tue, 29 Apr 2025 10:06:36 -0500 carlos.bilbao@...nel.org wrote:
> 
>> From: Carlos Bilbao <carlos.bilbao@...nel.org>
>>
>> Provide a priority-based mechanism to set the behavior of the kernel at
>> the post-panic stage -- the current default is a waste of CPU except for
>> cases with console that generate insightful output.
>>
>> In v1 cover letter [1], I illustrated the potential to reduce unnecessary
>> CPU resources with an experiment with VMs, reducing more than 70% of CPU
>> usage. The main delta of v2 [2] was that, instead of a weak function that
>> archs can overwrite, we provided a flexible priority-based mechanism
>> (following suggestions by Sean Christopherson), panic_set_handling().
>>
> 
> An effect of this is that the blinky light will never again occur on
> any x86, I think?  I don't know what might the effects of changing such
> longstanding behavior.

Yep, someone pointed this out before. I don't think it's super relevant? 

Also, in the second patch, I added a check to see that there's no console
output left to be flushed.


> 
> Also, why was the `priority' feature added?  It has no effect in this
> patchset.
> 

This was done to allow for flexibility, for example, if panic devices
wish to override the default panic behavior. Other benefits of such
flexibility (as opposed to, for example, a weak function that archs can
override) were outlined by Sean here:

https://lore.kernel.org/lkml/20250326151204.67898-1-carlos.bilbao@kernel.org/T/#m93704ff5cb32ade8b8187764aab56403bbd2b331

Thanks,
Carlos

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ