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

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 13:36:58 +0200	[thread overview]
Message-ID: <441bdbcd-d5fd-4708-afa9-2d82ddbcb401@virtuozzo.com> (raw)
In-Reply-To: <CAMrnHh44M4nHv-hAc-pGpWp+hRL62HoWPcgPoxeE6L5hTeXBWg@mail.gmail.com>

On 9/22/26 12:46, Alexey Kuznetsov wrote:
> 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.

These were just my thoughts if we can heal the stuck thread with
low effort. Seems like no - at least we need to drop these
assertions.

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

To prevent cases like the one below - inconsistent code state.

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

Making some smart livepatch tricks is too dangerous here without proper testing,
and from what I read in VSTOR-135626 comments, we can't do this easily.

I'll just take this patch as-is, and if guys need to fix stuck thread, they
should do some extra work.

Btw, I'm just curious, how iptables rule will help? It will speed up pcs_rpc_connect?

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

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