From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Liu Kui <kui.liu@virtuozzo.com>
Cc: azaitsev@virtuozzo.com, devel@openvz.org
Subject: Re: [Devel] [PATCH VZ10 v2] fs/fuse kio: track pending kRPC connect via state machine, not a pointer
Date: Fri, 04 Sep 2026 11:06:00 +0200 [thread overview]
Message-ID: <178851276075.1372856.4272514571977010402.b4-review@b4> (raw)
In-Reply-To: <20260904015755.23985-1-kui.liu@virtuozzo.com>
> Rework the previous fix ("fs/fuse kio: fix kRPC connect issues") to not
> require the new struct pcs_krpc member "connect_req", so the fix can be
> shipped as a livepatch: struct pcs_krpc objects are long-lived, and a
> patched kernel would dereference the new member on objects allocated
> before the livepatch was loaded, reading unallocated slab space.
>
> Both things connect_req was tracking are already derivable from the
> existing state machine once PCS_KRPC_STATE_CONNECT is made to mean
> exactly "a connect req is in flight":
>
> - krpc_connect_done() settles a failed connect back to UNCONN instead
> of leaving the state in CONNECT forever;
>
> - pcs_krpc_abort() no longer resets CONNECT to UNCONN: the req is
> still in flight, and only its completion settles the state. It
> advances gen instead, disowning the pending req: when the req
> completes, krpc_connect_done() settles the state to UNCONN without
> committing the dead session, even if the late connect succeeded;
>
> - pcs_krpc_connect() proceeds only from UNCONN or ABORTED, refusing
> new connects (-EPERM) while a req is in flight - at most one connect
> req exists at a time, same as with the connect_req check;
>
> - pcs_krpc_poll() reports EPOLLERR on UNCONN: poll bails out earlier
> unless ctx->gen == krpc->gen, and the current session can only be in
> UNCONN if its connect failed, which is what the (CONNECT && !connect_req)
> test used to detect.
- pcs_krpc_poll() reports EPOLLERR on UNCONN, and the gen check moves
under krpc->lock into the same condition: with ctx->gen == krpc->gen
the current session can only be in UNCONN if its connect failed,
which is what the (CONNECT && !connect_req) test used to detect.
> Within CONNECT the pending req carries the current gen unless the
> session was aborted, so a gen mismatch in krpc_connect_done() reliably
> identifies a disowned req.
>
Fixes: 7ae23fa1c145e ("fs/fuse kio: fix kRPC connect issues")
Feature: fuse: kRPC - single RPC for kernel and userspace
> https://virtuozzo.atlassian.net/browse/VSTOR-135626
>
> Signed-off-by: Liu Kui <kui.liu@virtuozzo.com>
Reviewed-by: Konstantin Khorenko <khorenko@virtuozzo.com>
--
Konstantin Khorenko <khorenko@virtuozzo.com>
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-09-04 9:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 1:57 Liu Kui
2026-09-04 9:06 ` Konstantin Khorenko [this message]
2026-09-04 9:14 ` Konstantin Khorenko
2026-09-04 9:59 ` Konstantin Khorenko
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=178851276075.1372856.4272514571977010402.b4-review@b4 \
--to=khorenko@virtuozzo.com \
--cc=azaitsev@virtuozzo.com \
--cc=devel@openvz.org \
--cc=kui.liu@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.