From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id 3319B803D5 for ; Tue, 1 Sep 2026 21:00:45 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 681KxRcr008736; Tue, 1 Sep 2026 23:59:28 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 681KxRcr008736 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="XUYsxLW2" Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 681KxPxj008732 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Tue, 1 Sep 2026 23:59:25 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 681KxPxj008732 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-47f4bff865cso240389f8f.0 for ; Tue, 01 Sep 2026 13:59:25 -0700 (PDT) X-Forwarded-Encrypted: i=2; AKwUvBwqnoANKK8jLcuoFWWa7PFMLO50gHafODArAn4mlHDcAFtDlN4qa/oOUtfPJmKnKlWjIRsbww==@openvz.org X-Gm-Message-State: AFuF++nvG2V1ziLBIrPIuXlt3N03hmzSf1Aw8J7Vi1rhtC3hr9dIUoKi 0mC7yCdro+wz+6VuPSGCGcK6vV6GC3x/adI+zbB+b7NT7Figt8vPfLUaOYQ8FLtVSUFGUpjbpjd cmUWcj5OIvgPt9+YvSSknZQmyoypu6BQdWzqAuxN4OROelaH0HJBqoA== X-Gm-Gg: AYBFou1i8VtsfPcKn39GXPRk/oZGLqKe8wtZVSdhI7JQfSl7/8c8LMuUFicqPOqCHla vniWaBk1Oo8jJquLp1xPvCQ78JhajBSRtOt5oGfRAMiXcqd0e5XeXGs5B8hzLAqtZVWl4Z/XHKa F5yN13+n1Cac546naQQEhYBmRR9f1i0vkn3fryce00yXOfaQYOXaokDlgXG/q5oO6oMIZioppsg +tUuQ/bIRIesDTnRr6oslCWL0mXCacq9f3BHlxy1JDUq19TB4dbJdF8248WbDiWiA4rFE4JDOoo /McXagmlYZLsWK3iKD6PfqROK6FtzluKFvR3GUPbVmVaT93sj7iJNHVmrChCYygwMbsbDxiKGPe YX/GubSWqqNq7d0flGg== X-Received: by 2002:a05:6000:2584:b0:482:f0dc:cfe7 with SMTP id ffacd0b85a97d-48488effcf0mr143637f8f.8.1788296365321; Tue, 01 Sep 2026 13:59:25 -0700 (PDT) X-Received: by 2002:a05:6000:2584:b0:482:f0dc:cfe7 with SMTP id ffacd0b85a97d-48488effcf0mr143563f8f.8.1788296364655; Tue, 01 Sep 2026 13:59:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788296364; cv=none; d=google.com; s=arc-20260327; b=hzUZEtEB0YHQrti/LvyXcBoe/np3phDk+gOexB7rIjMyXL65Drx616KxFrtHmIOCiS aJZB0EE1MTTCV92vcUcLrkhGkyBDJdWFf81UUavHdiWClZNA9/olTg/g6igM+QS/Qxmx GGM7pd8hkNGOIjVYThDJt0JgCLwe9PPoLj+hbdpgZyAEjiukJ3iquv3IMH8Kv7B5ZnG0 p7GTPSa3YW6vVPSePXwTlGXw4yrDrWJn5DsJImyn7fAdFZs+V3OczA3r6Ex0xTIVfc0O lwq9ogCqni6pTYIIR2Cd0UDm0ewmA/uc0GTV/zWYA7w986oueIxRl1ImXxIycBfacKhj oXKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=message-id:date:references:in-reply-to:cc:to:from:subject :content-transfer-encoding:mime-version:dkim-signature; bh=fSZkYPqoTJNN+QDxi/jnxmDXlUKU4hjnrtPadxfRTW0=; fh=HBNdCRRqGAWC2ICfTurXSHCCdBjKa7HB1jG+7rGs1mc=; b=bcqdR0ONvMd3ZfMRLEEmnNxm1gug6ZDfTyeWr3gKQtK/T4PhtUx5dVFVOHK+FSKCvx U8kLWOmsRYkrtN3GXezmV83JS67dzqnUDGe0Lg4l5BGnon8PZ8qNQLcwmyDXQ7V7Xafg L17c9GAQUsR1+p6rdvlp65ijjEdLeUDULkOehAnJ75x0OR2D4TQTxi97qgrji0uk65pT q++kzgpwlzzj2mexksOTusYOtxhAp6i3p4hgRfVzw7ru2Uo4/TazsywN5trLPEO3vgiJ hfB1VTVeWTNgUhpYlLvi/VdXlEhQNE4/C/JA5Qkr0mgOK6ZWSHXvrRcJ9IThmUm4kz7u ZRsQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=XUYsxLW2; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-4844951671csi1208817f8f.457.2026.09.01.13.59.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Sep 2026 13:59:24 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=XUYsxLW2; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Message-Id:Date:From:Subject:Content-Type: MIME-Version; bh=fSZkYPqoTJNN+QDxi/jnxmDXlUKU4hjnrtPadxfRTW0=; b=XUYsxLW2ocBN BpUFFpK8Lryeq9r6Os3lOqxT6Qs4oxWuQpob3fVbnHPSTi6FlunQBYWuwW4wdWtAlKnWOY0Fvkn4A W/PkRoK7SdHVwFuaKzk5vdjOPHUS09oVZWLGue8fyXwes7GvyJvDOjq9+7QvLkiJ7JCNpcRcimgaO s4PkVCqDyMLcUayRA4w9jlC0UPsK8CofmmslHzwrepQhq3GbL3TL2BeG1shYvAWCC3qZkSJm/2rjH BRZ90ctB4baZwXmswSSNgxcwI0sygPc1mhWAhpq7scrYJxwH0WxgEi/33AUHUY4ZITK68je7xcKef 2gGpNxHLjSZV1CC9CHXftQ==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1x1VXM-000Aw8-04; Tue, 01 Sep 2026 22:59:13 +0200 MIME-Version: 1.0 From: Konstantin Khorenko To: Liu Kui In-Reply-To: <20260827123712.84476-1-kui.liu@virtuozzo.com> References: <20260827123712.84476-1-kui.liu@virtuozzo.com> Date: Tue, 01 Sep 2026 22:59:10 +0200 Message-Id: <178829635034.1186226.7726025563757909332.b4-review@b4> X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5433; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=Tn5B8gv7CSvVXHy+HZJar+vq2AoeejEjHqv1c+A9TuI=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBqlzyg4sm+jHvYnnjcnnnhYAyk3VjJSIts9pMu/ N+CQOA+rt2JAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCapc8oAAKCRBRlgpH+WFc KlH5D/9KT02Mvak8elQPOLunFNf5y1bjt1VnFkS8hZ3/nWuTVGGGw5IV142+/p7l6EM6TV6vB7y PLF8FuunS7uD1uPzUjKIM7XLJvYng/U/GSHWBenLOfmSXYzyJwljQIqFo/QbqM9v75dU0enNkJl alDXfv2CarDzY7N18pAnbfZiVlBWvwUtRcQByCdXYuuQ2C3frZA0n2Oxu/5Gc5opi3QecyGc+n5 cAyVXPWoHWF2V5zI1CZ6ME8Ra87wF0gSia88rUe1e9WouZIW8HXxpMJmNLWJb6nTZ9Wy4Ngo3I7 oo1UArhYWEE3BlD3CP/TFcM/ajnSU4bKHKFZPsryfuS4aSil6kVs9sapHsD9QRg8sHknT2Vvcfa ZvLTpQa3Lf8Ir3PDi5vN6IlNZvjHAtVIIo09BPGeEk1TtCHCAKd6fcm+t59071PBgw6ngqye5/o Gr6jUJBZlJgyMVjlp0AdHQJZjUQ2tEnpSBo7s2g0s+NyhNwiTE9BDbbcw8qpxh/hF2yMZcL1Ms1 4GRvPuV4326WkwvUoKeaxOF55W6+Yg94ZLR7moQATdYlRXX6kNa3LJVhRrCRhmq4lA4vO71sz9h kn/oTdJMinhWbYEQhl/7AMknMljE1ccQMbwk8HWmblSEDjvZPDDLpO7lYVqmQFQoeqEY2Rzxf+V d95ftfquw9Kgk+w== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Cc: devel@openvz.org, azaitsev@virtuozzo.com Subject: Re: [Devel] [PATCH VZ10] fs/fuse kio: track pending kRPC connect via state machine only X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org > 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. > > 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; > > - 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 or was aborted, which is what the > (CONNECT && !connect_req) test used to detect. > > gen only advances in pcs_krpc_connect(), which is blocked during > CONNECT, so within that state the in-flight req always carries the > current gen and krpc_connect_done()'s existing staleness check is > sufficient. > > Related to: > https://virtuozzo.atlassian.net/browse/VSTOR-135626 > Fixes: d0d6034c36010 ("fs/fuse kio: fix kRPC connect issues") > Feature: fuse: kRPC - single RPC for kernel and userspace > > Signed-off-by: Liu Kui > > diff --git a/fs/fuse/kio/pcs/pcs_krpc.c b/fs/fuse/kio/pcs/pcs_krpc.c > index 0930fb4adf125..f9fb6b3699062 100644 > --- a/fs/fuse/kio/pcs/pcs_krpc.c > +++ b/fs/fuse/kio/pcs/pcs_krpc.c > @@ -787,8 +787,12 @@ static int pcs_krpc_abort(struct pcs_krpc *krpc) > spin_lock(&krpc->lock); > > if (krpc->state != PCS_KRPC_STATE_CONNECTED) { > - if (krpc->state == PCS_KRPC_STATE_CONNECT) > - krpc->state = PCS_KRPC_STATE_UNCONN; > + /* > + * A pending connect stays in CONNECT state: its connect req > + * is still in flight and krpc_connect_done() will settle the > + * state to UNCONN when it completes. Until then new connects > + * are refused, so at most one connect req exists at a time. > + */ > spin_unlock(&krpc->lock); > return 0; > } [Severity: High] Can this change leave a krpc stuck in the connected state with no session fd attached to it? Consider a connect req in flight (state is CONNECT) whose fd is closed by userspace after its connect timeout expires - the scenario the original fix was written for: pcs_krpc_release() if (ctx->gen == krpc->gen) pcs_krpc_abort(krpc); /* state is CONNECT: does nothing now */ gen cannot advance while the state stays CONNECT, because pcs_krpc_connect() refuses new connects with -EPERM in that state. So when the in-flight req later completes successfully (the peer became reachable again), krpc_connect_done() passes its staleness check and commits the dead session: if (req->gen != krpc->gen || krpc->state != PCS_KRPC_STATE_CONNECT) { spin_unlock(&krpc->lock); goto out; } if (!pcs_if_error(&msg->error)) { krpc->state = PCS_KRPC_STATE_CONNECTED; Now the krpc is CONNECTED while its gen still names a session whose fd is gone. Every following PCS_IOC_KRPC_CONNECT returns -EPERM, there is no fd left on which userspace could issue PCS_KRPC_IOC_ABORT, and no kernel path resets the state, so the node stays unconnectable until the krpc is destroyed. The connect_req based code handled this case: pcs_krpc_abort() moved CONNECT to UNCONN, a successful krpc_connect_done() then took the stale path without transitioning to CONNECTED, and the next connect was allowed as soon as the old req completed. Does the abort/release path need to invalidate the pending connect, so that a late successful completion settles the state to UNCONN instead of resurrecting the closed session? > @@ -956,8 +960,13 @@ static __poll_t pcs_krpc_poll(struct file *file, poll_table *wait) > > spin_lock(&krpc->lock); > > + /* > + * ctx->gen == krpc->gen (checked above) means this is the current > + * session, so UNCONN here can only mean its connect attempt has > + * failed (see krpc_connect_done()) or the session was aborted. > + */ > if (krpc->state == PCS_KRPC_STATE_ABORTED || > - (krpc->state == PCS_KRPC_STATE_CONNECT && !krpc->connect_req)) { > + krpc->state == PCS_KRPC_STATE_UNCONN) { > pollflags |= EPOLLERR; > } else if (krpc->state == PCS_KRPC_STATE_CONNECTED) { > pollflags |= EPOLLOUT; [Severity: Low] This isn't a bug, but after this change pcs_krpc_abort() never sets UNCONN, and an aborted session is left in ABORTED, which the first check already handles. For a session with ctx->gen == krpc->gen, can UNCONN still be reached through an abort as the comment says, or only through a failed connect? The commit message carries the same wording ("the current session can only be in UNCONN if its connect failed or was aborted"). [ ... ] -- Konstantin Khorenko _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel