All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
From: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
To: Alexey Kuznetsov <kuznet@virtuozzo.com>
Cc: devel@openvz.org, Liu Kui <kui.liu@virtuozzo.com>,
	azaitsev@virtuozzo.com
Subject: Re: [Devel] [PATCH hci-8.1] fs/fuse kio: start connect once per rpc_queue_work batch
Date: Tue, 22 Sep 2026 17:19:50 +0200	[thread overview]
Message-ID: <bf42bf81-79e3-499b-abc1-90d24718eba1@virtuozzo.com> (raw)
In-Reply-To: <CAMrnHh6m+-qcHnMLvJyAWvz1H7Z5MJuJb6iHA8DBEafW1Jb7Xg@mail.gmail.com>



On 9/22/26 17:01, Alexey Kuznetsov wrote:
> Hello!
> 
> On Tue, Sep 22, 2026 at 10:11 PM Vladimir Riabchun
> <vladimir.riabchun@virtuozzo.com> wrote:
>> Condition in BUG_ON(msg->rpc != (requeue ? ep: NULL)) was too hard
>> for me to process correctly in my head, while writing reply I decoded
>> it.
> 
> Exactly. As I said the code is too scary.
> 
>> What's wrong with tail calls? If it is inlined, we will just patch
>> the parent and stack checks would be performed for parent.
> 
> tail called functions are not on stack. at least they used to,
> probably with ORCA they are visible, I still did not learn this.
> 
> Return should not be an issue, old code remains executable and not corrupted,
> it can live forever if someobe sleeps in it.
> Or it does not?? I thought it uses __fentry__ placeholder to redirect.

I mentioned return sites to show that these stack trace checks might be
useful even if patching does stop_machine. But it is not the case for
ftrace-based livepatches.

There I think guys just want some additional guarantees on executed code
state, to think less about such problems.

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

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

      reply	other threads:[~2026-09-22 15:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 11:28 Liu Kui
2026-09-21 12:13 ` Alexey Kuznetsov
2026-09-21 20:52 ` Vladimir Riabchun
2026-09-21 21:17   ` Alexey Kuznetsov
2026-09-22  9:38     ` Vladimir Riabchun
2026-09-22 10:46       ` Alexey Kuznetsov
2026-09-22 11:36         ` Vladimir Riabchun
2026-09-22 13:12           ` Alexey Kuznetsov
2026-09-22 14:10             ` Vladimir Riabchun
2026-09-22 15:01               ` Alexey Kuznetsov
2026-09-22 15:19                 ` Vladimir Riabchun [this message]

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=bf42bf81-79e3-499b-abc1-90d24718eba1@virtuozzo.com \
    --to=vladimir.riabchun@virtuozzo.com \
    --cc=azaitsev@virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=kui.liu@virtuozzo.com \
    --cc=kuznet@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.