Re: [Devel] [PATCH hci-8.1] fs/fuse kio: start connect once per rpc_queue_work batch

[Alexey Kuznetsov <kuznet@virtuozzo.com>]

On Tue, Sep 22, 2026 at 5:41 PM Vladimir Riabchun
<vladimir.riabchun@virtuozzo.com> wrote:
> I now think it won't work: we take messages from ep->input_queue,
> move them to ep->state_queue via pcs_rpc_send, but also while doing
> this we set msg->rpc = ep. When we reach second pcs_rpc_send with
> this message, it will trigger BUG_ON(msg->rpc != (requeue ? ep: NULL)).

Please, elaborate.

Yes, the code is kind of strange, I daresay. Apparently, original author did
some wrong assumptions and left mud, and when we cleaned it up later, instead of
just cleanup we left old paths, added BUG_ONs and abundant comments,
apparently being afraid that we miss something. :-) Must just be
deleted altogether.

Yet the intent is clear. msg->rpc is NULL while message is in
input_queue. It grabs ref
and assigns it the first time it leaves this queue. And after this
it stays == ep. It does not even correlate with the patch.

> So you think we should keep the RK patch simple and not bother with
> already stuck nodes

This is yes.

>... and force options?

And this is up to you. IMHO the whole digging of stack in livepatch is
entirely useless,
protects from nothing. At least I do not understand this wisdom and
leave paranoia to persons
who do understand.

As I see the only real danger is when after patch old code which is
still running (old rpc_queue_work())
calls pcs_rpc_send, which after the patch is _new_. This means that
rpc connect can
be missed because it is removed from pcs_rpc_send, and old rpc_queue_work does
not have it. Well, it is not a big deal, it will timeout and redone later.

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