Re: [Devel] [PATCH hci-8.1 1/6] ve/printk: Add sanity checks in ve_printk functions

[Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>]

On 10/2/26 23:31, no-reply@sashiko.virtuozzo.com wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] printk: WARN_ON_ONCE() in ve_vprintk_deferred() uses non-deferred printk path
> --
> 
> commit 2b22fc2da5243bd2b5c695100f66ab107b28c158
> Author: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
> 
> ve/printk: Add sanity checks in ve_printk functions
> 
> This patch adds a sanity check on the dst argument in the ve_printk
> helpers. It also reorders the VE_LOG test so the dst bit is checked
> before ve_is_super().
> 
> Link: https://virtuozzo.atlassian.net/browse/VSTOR-146839
> 
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
> 
> [ ... ]
> 
>> @@ -2567,10 +2569,12 @@ static asmlinkage int ve_vprintk_deferred(int dst, const char *fmt, va_list args
>>   	va_list args2;
>>   	int r = 0;
>>   
>> +	WARN_ON_ONCE(!dst || (dst & ~VE_LOG_BOTH));
>> +
>>   	va_copy(args2, args);
>>   	if (ve_is_super(get_exec_env()) || (dst & VE0_LOG))
>>   		r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, fmt, args);
> 
> [Severity: Low]
> This isn't a bug in the normal case, but is the new WARN_ON_ONCE() safe
> in ve_vprintk_deferred()?
> 
> This function exists for contexts where the regular printk path is
> unsafe, which is why it emits at LOGLEVEL_SCHED through vprintk_emit().
> WARN_ON_ONCE() reports through the normal printk and console path. It
> can also panic if panic_on_warn is set.
> 
> If a caller passes dst == 0 or a dst with bits outside VE_LOG_BOTH from
> such a context, could the warning recurse into scheduler or console
> locks that the deferred variant is meant to avoid?
> 
> I did not find a caller that passes an invalid dst. The trigger would
> need a buggy caller, and the warning fires only once.
> 
> Would a BUILD_BUG_ON() for constant arguments be more suitable here?
> Alternatively, the report could go through a deferred-safe mechanism
> such as printk_deferred().

We can't know passed values when compiling this file.
Also, WARN_ON doesn't print anything itself, instead it executes UD2,
leaving all the job to the exception handler.

And kernel does use WARNs in sched code: check 
force_compatible_cpus_allowed_ptr,
it has both WARN_ON and printk_deferred.

> 

-- 
Best regards, Riabchun Vladimir
Linux Kernel Developer, Virtuozzo

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel