All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: Konstantin Khorenko <khorenko@virtuozzo.com>,
	Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>,
	vasileios.almpanis@virtuozzo.com, ptikhomirov@virtuozzo.com
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v3 2/6] ve/printk: Report potentially leaking usage of ve_printk functions
Date: Sun, 11 Oct 2026 22:59:15 +0000	[thread overview]
Message-ID: <010701a12d311bbc-e0c366e6-3ae3-4211-8782-5d95ff805346-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261012-ve-printk-irq-v3-2-efc95fd5c78a@virtuozzo.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] ve/printk: host-log branch still keyed on get_exec_env() from IRQ/softirq
--

commit 8d09395a5f1fa2043bb21991f8eb2152c9a5ad97
Author: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>

ve/printk: Report potentially leaking usage of ve_printk functions

This patch adds WARN_ON_ONCE(!in_task()) checks to the VE_LOG branches of
ve_vprintk(), ve_vprintk_deferred() and ve_dev_printk_emit(), and to
ve_log_state(). The goal is to avoid relying on get_exec_env() in
non-task context, so that nothing leaks to a random container.

Link: https://virtuozzo.atlassian.net/browse/VSTOR-146839

> diff --git a/drivers/base/core.c b/drivers/base/core.c
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c

[ ... ]

> @@ -4952,7 +4952,9 @@ int ve_dev_printk_emit(int dst, int level, const struct device *dev, const char
>  
>  	if (ve_is_super(get_exec_env()) || (dst & VE0_LOG))
>  		r = dev_vprintk_emit(level, dev, fmt, args);
> -	if ((dst & VE_LOG) && !ve_is_super(get_exec_env()))
> +
> +	/* Report IRQ usage here - printing to VE requires explicit ve reference */
> +	if ((dst & VE_LOG) && !WARN_ON_ONCE(!in_task()) && !ve_is_super(get_exec_env()))
>  		r = ve_dev_vprintk_emit(level, dev, fmt, args2);

[Severity: Low]
Is the host-log branch still keyed on get_exec_env() in softirq or IRQ
context?

Only the VE_LOG branch is guarded by in_task().  The preceding host
branch is unchanged:

    if (ve_is_super(get_exec_env()) || (dst & VE0_LOG))
        r = dev_vprintk_emit(level, dev, fmt, args);

With dst == VE_LOG in softirq, the result depends on which task was
interrupted:

    - host task interrupted: the message goes to the host log, and then
      the VE branch only produces a WARN, even though that branch would
      have been skipped anyway.
    - container task interrupted: neither branch runs, so the message is
      silently dropped.

In both cases r stays 0, so the caller cannot tell what happened.

Nothing leaks to a container, but the outcome is not deterministic.
Would it make sense to check in_task() once before either branch and
apply a single rule for non-task context?

ve_dev_printk_emit() takes no ve argument, so it always relies on
get_exec_env().  The in-tree caller net/core/dev.c:__ve_netdev_printk()
passes no ve and can run from softirq/NAPI context, so it reaches this
path.

The later patches in the series ("Specify ve in printks" and "Use
ve_printk with specified ve") only help callers that pass an explicit ve.
This netdev path and ve_dev_printk_emit() are not covered by them.

> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c

[ ... ]

> @@ -2540,7 +2541,9 @@ static asmlinkage int ve_vprintk(int dst, const char *fmt, va_list args)
>  	va_copy(args2, args);
>  	if (ve_is_super(get_exec_env()) || (dst & VE0_LOG))
>  		r = vprintk(fmt, args);
> -	if ((dst & VE_LOG) && !ve_is_super(get_exec_env()))
> +
> +	/* Report IRQ usage here - printing to VE requires explicit ve reference */
> +	if ((dst & VE_LOG) && !WARN_ON_ONCE(!in_task()) && !ve_is_super(get_exec_env()))
>  		r = ve_vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, fmt, args2);

[Severity: Low]
Does ve_vprintk() have the same problem?

The host-log decision still uses ve_is_super(get_exec_env()) without an
in_task() check.  In the series-final state it reads:

    if (!ve)
        ve = get_exec_env();

    va_copy(args2, args);
    if (ve_is_super(ve) || (dst & VE0_LOG))
        r = vprintk(fmt, args);

    if ((dst & VE_LOG)) {
        if (!ve_provided && WARN_ON_ONCE(!in_task()))
            goto done;

So a VE_LOG-only message from softirq with ve == NULL is either printed
to the host log or dropped, depending on the interrupted task.  The WARN
can also fire when a host task was interrupted, although the VE branch
would have been skipped anyway.

Could the host-branch decision be made deterministic for non-task
context with no explicit ve?

> @@ -2574,7 +2577,9 @@ static asmlinkage int ve_vprintk_deferred(int dst, const char *fmt, va_list args
>  	va_copy(args2, args);
>  	if (ve_is_super(get_exec_env()) || (dst & VE0_LOG))
>  		r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, fmt, args);
> -	if ((dst & VE_LOG) && !ve_is_super(get_exec_env()))
> +
> +	/* Report IRQ usage here - printing to VE requires explicit ve reference */
> +	if ((dst & VE_LOG) && !WARN_ON_ONCE(!in_task()) && !ve_is_super(get_exec_env()))
>  		r = ve_vprintk_emit(0, LOGLEVEL_SCHED, NULL, fmt, args2);

[Severity: Low]
The same pattern appears in ve_vprintk_deferred().  The host branch
ve_is_super(get_exec_env()) || (dst & VE0_LOG) is unguarded, and the
final-state code only guards the VE_LOG branch with
"if (!ve_provided && WARN_ON_ONCE(!in_task())) goto done;".

Can the same non-deterministic host-log versus drop outcome occur here
when this is called from IRQ or softirq with ve == NULL?

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261012-ve-printk-irq-v3-0-efc95fd5c78a@virtuozzo.com?part=2

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

  reply	other threads:[~2026-10-11 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 22:52 [Devel] [PATCH hci-8.1 v3 0/6] ve/printk: Fix logs leakage via ve_printk called from IRQ context Vladimir Riabchun
2026-10-11 22:52 ` [Devel] [PATCH hci-8.1 v3 1/6] ve/printk: Add sanity checks in ve_printk functions Vladimir Riabchun
2026-10-11 22:57   ` no-reply
2026-10-11 22:52 ` [Devel] [PATCH hci-8.1 v3 2/6] ve/printk: Report potentially leaking usage of " Vladimir Riabchun
2026-10-11 22:59   ` no-reply [this message]
2026-10-11 22:52 ` [Devel] [PATCH hci-8.1 v3 3/6] ve/printk: Specify ve in printks Vladimir Riabchun
2026-10-11 23:02   ` no-reply
2026-10-11 22:52 ` [Devel] [PATCH hci-8.1 v3 4/6] ve/printk: Fix time virtualization Vladimir Riabchun
2026-10-11 23:03   ` no-reply
2026-10-11 22:52 ` [Devel] [PATCH hci-8.1 v3 5/6] ve/failcount: Use ve_printk with specified ve Vladimir Riabchun
2026-10-11 23:05   ` no-reply
2026-10-11 22:52 ` [Devel] [PATCH hci-8.1 v3 6/6] ve: add neigh_tbl failcounter Vladimir Riabchun
2026-10-11 23:04   ` no-reply
2026-10-12  7:59   ` Vasileios Almpanis
2026-10-12  7:59 ` [Devel] [PATCH hci-8.1 v3 0/6] ve/printk: Fix logs leakage via ve_printk called from IRQ context Vasileios Almpanis

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=010701a12d311bbc-e0c366e6-3ae3-4211-8782-5d95ff805346-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=khorenko@virtuozzo.com \
    --cc=ptikhomirov@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.