All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: vasileios.almpanis@virtuozzo.com,
	Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>,
	Konstantin Khorenko <khorenko@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 1/6] ve/printk: Add sanity checks in ve_printk functions
Date: Fri, 2 Oct 2026 21:31:45 +0000	[thread overview]
Message-ID: <010701a0fe87c530-6148b930-e30b-4de3-b6d3-6ceb259bac9b-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261002-ve-printk-irq-v1-1-cb55896d455c@virtuozzo.com>

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

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261002-ve-printk-irq-v1-0-cb55896d455c@virtuozzo.com?part=1

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

  reply	other threads:[~2026-10-02 21:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 21:26 [Devel] [PATCH hci-8.1 0/6] ve/printk: Fix logs leakage via ve_printk called from IRQ context Vladimir Riabchun
2026-10-02 21:26 ` [Devel] [PATCH hci-8.1 1/6] ve/printk: Add sanity checks in ve_printk functions Vladimir Riabchun
2026-10-02 21:31   ` no-reply [this message]
2026-10-03 12:26     ` Vladimir Riabchun
2026-10-02 21:26 ` [Devel] [PATCH hci-8.1 2/6] ve/printk: Report potentially leaking usage of " Vladimir Riabchun
2026-10-02 21:32   ` no-reply
2026-10-03 12:26     ` Vladimir Riabchun
2026-10-02 21:26 ` [Devel] [PATCH hci-8.1 3/6] ve/printk: Specify ve in printks Vladimir Riabchun
2026-10-02 21:36   ` no-reply
2026-10-03 13:49     ` Vladimir Riabchun
2026-10-02 21:26 ` [Devel] [PATCH hci-8.1 4/6] ve/printk: Fix time virtualization Vladimir Riabchun
2026-10-02 21:37   ` no-reply
2026-10-05  8:45     ` Vladimir Riabchun
2026-10-02 21:26 ` [Devel] [PATCH hci-8.1 5/6] ve/failcount: Use ve_printk with specified ve Vladimir Riabchun
2026-10-02 21:38   ` no-reply
2026-10-05  9:56     ` Vladimir Riabchun
2026-10-02 21:26 ` [Devel] [PATCH hci-8.1 6/6] ve: add neigh_tbl failcounter Vladimir Riabchun
2026-10-02 21:40   ` no-reply
2026-10-05 10:02     ` Vladimir Riabchun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=010701a0fe87c530-6148b930-e30b-4de3-b6d3-6ceb259bac9b-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=khorenko@virtuozzo.com \
    --cc=vasileios.almpanis@virtuozzo.com \
    --cc=vladimir.riabchun@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.