[Devel] [PATCH hci-8.1] fs/fuse kio: start connect once per rpc_queue_work batch
Alexey Kuznetsov
kuznet at virtuozzo.com
Tue Sep 22 13:46:54 MSK 2026
On Tue, Sep 22, 2026 at 5:41 PM Vladimir Riabchun
<vladimir.riabchun at 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.
More information about the Devel
mailing list