Re: [PATCH v3 3/4] xen/console: add build-time rate-limiting controls

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.07.2026 11:59, Teddy Astie wrote:
> Le 15/07/2026 à 22:24, dmukhin@xxxxxxxx a écrit :
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -672,4 +672,33 @@ config PM_STATS
>>        Enable collection of performance management statistics to aid in
>>        analyzing and tuning power/performance characteristics of the system
>>   
>> +menu "Console rate-limiting"
>> +
>> +config PRINTK_RATELIMIT_MS
>> +    int "printk rate-limiting time window (milliseconds)"
>> +    default 5000
>> +    help
>> +      Specifies the time window, in milliseconds, for rate-limited printk
>> +      messages. No more than `CONFIG_PRINTK_RATELIMIT_BURST` messages will 
>> be
>> +      printed within this window.
>> +
>> +      Setting this value to 0 disables rate-limiting entirely.
>> +
>> +      Rate-limited messages are those controlled by the `loglvl` and
>> +      `guest_loglvl` command-line parameters.
>> +
>> +config PRINTK_RATELIMIT_BURST
>> +    int "printk rate-limited message burst size"
>> +    default 10
>> +    help
>> +      Defines the maximum number of rate-limited printk messages that may be
>> +      printed within each `CONFIG_PRINTK_RATELIMIT_MS` time window.
>> +
>> +      Setting this value to 0 disables rate-limiting entirely.
>> +
>> +      Rate-limited messages are those controlled by the `loglvl` and
>> +      `guest_loglvl` command-line parameters.
>> +
>> +endmenu
>> +
>>   endmenu
> 
> Given that setting 0 to either will disable rate limiting, would it be 
> preferable instead to have a more general PRINTK_RATELIMIT toggle, where :
> 
> Setting it to true would enable configuration of ms and burst (rejecting 
> 0 if possible).
> Setting it to false would set both to 0 hence disabling rate limiting by 
> default.
> 
> And we do something like
> 
> static const unsigned int printk_ratelimit_ms =
>    IS_ENABLED(CONFIG_PRINTK_RATELIMIT) ? CONFIG_PRINTK_RATELIMIT_MS : 0;
> 
> (similarly for burst)
> 
> ?

While I'm not quite sure we need to go this far (it's tidier overall, but
as it is right now the effect of disabling rate limiting is also clearly
stated), there's a security angle here: Disabling rate limiting altogether
must be clearly documented as not security supported. But we may need to
go beyond that, and also document as not security supported any lowering
of the default values.

Jan