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

[Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>]

On 9/22/26 15:12, Alexey Kuznetsov wrote:
> Hello!
> 
> On Tue, Sep 22, 2026 at 7:41 PM Vladimir Riabchun
> <vladimir.riabchun@virtuozzo.com> wrote:
>> 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.
> 
> I do not see any problems there. Well, except for too scary code.
> If you see, elaborate, I could miss something.

You are right, sorry. There is no BUG_ON problem.
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.
> 
>> To prevent cases like the one below - inconsistent code state.
> 
> IMHO it prevents nothing. It just minimizes patch success. :-)
> Is it correct that all these kludges are done to avoid stop machine?

Probably no. stop_machine-based livepatch I worked with does the same
stack checks and even more. But there it is 100% needed because it could
patch any place of code(not ftrace-based patching), so it is possible
to corrupt return site.

Guys just doing their best to avoid half-patches code from being run.

> Or is it still used? Sleeping states must be responsibility of patch maker,
> protections based on traces are  just useless, kernel simply cannot do it
> by many reasons f.e. because of tail calls.

What's wrong with tail calls? If it is inlined, we will just patch
the parent and stack checks would be performed for parent.

> 
>> Btw, I'm just curious, how iptables rule will help? It will tesspeed up pcs_rpc_connect?
> 
> Yes, almost infinitely. In the last case we had 16 dead rpcs, each has
> queued 200000-300000
> requests. Each connect waits for ~2sec. So, counting: it would take
> ~75 days to finish. :-)
> With -j DROP they were processed faster than I started drgn to measure
> the rate, some
> seconds.

So, this is the cure if livepatch doesn't apply.

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

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