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 F1DF48013F for ; Fri, 4 Sep 2026 10:01:21 +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 684A0032031218; Fri, 4 Sep 2026 13:00:01 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 684A0032031218 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="yxz/3Ith" Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6849xvZR031214 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 4 Sep 2026 12:59:58 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6849xvZR031214 Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-851992f22ccso662658b3a.2 for ; Fri, 04 Sep 2026 02:59:58 -0700 (PDT) X-Forwarded-Encrypted: i=3; AKwUvBxfCeuOrNIq75xV6RizMDnZYbVB27Br4hkObGEUhSzlAYMUpN/ejUDvayoGFSLShk82dQBXMg==@openvz.org X-Gm-Message-State: AFuF++nXelesJbWhZAdUMNqUG7qtOmDzVYZ0KFG5Lot7oDm9sqEL5kct UG7Jki5r1KXeLPjHX0Xm78b5v0PrGDYYuJAWonExL0DlAfQd1lXLgWweOiHlhxWXE4sm5p6r64W CorJnfNggKTtrwLbxGRXqDLUTOtvJ0rGTHjIqx5T4Uw2ZDcCm+jOu4g== X-Gm-Gg: AYBFou1Hx62YreMfx+hitLWrSRJOHdlUl/kTzF3iZ0NZX9ixlQgktoHxglW+oveU3yp o/+f+H1wZAjojIf2gKOsUCnZoK55ygBYesqMBmeY8H6D72G8ETQHV0e2E59dkSjSHbbRDHvCTPY XGskRjSXQZMqCKwajnalZN8TWh+HUcnghPM/3pyB+DTVpV478+Hz8P1NsfbFl35m12u3IQNDKHj sHAfyYHkBI9ooy8TipNXpuTbOJTvx1RcQO3Om0oj8bpSHYndUl39KjrCJiysGnH4rhBPlwZzwNM 0iLJ67p5rX1R7PERA+8E/HyJLtb97erklFTMw9AklM59j+2aDAX0w/8TNXYlcqDZc8APYJLwl+E RgXJyQmcG2NfkxbSSSiZ0IdrGB3XEcwz+tJqbA+uG5gdroBSwQBw5ShdgxYUHBBg3KpQ39Nq3Vo ovuwnA1f+3oS0oDSXdrJR9noYQ X-Received: by 2002:a05:6a00:3d48:b0:84e:4d6:78fe with SMTP id d2e1a72fcca58-861679a5642mr6803599b3a.3.1788515996654; Fri, 04 Sep 2026 02:59:56 -0700 (PDT) X-Received: by 2002:a05:6a00:3d48:b0:84e:4d6:78fe with SMTP id d2e1a72fcca58-861679a5642mr6803543b3a.3.1788515996050; Fri, 04 Sep 2026 02:59:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1788515996; cv=pass; d=google.com; s=arc-20260327; b=gheg12xKhHh668o0NvrZapLf37zwEyS8aHxxTS7M+PsKR8xvdW3jYXRuYnr4941OuI GbKjiafTqF60HnlbNX0wvWgaAmDQNdb2jG2LxORQaiH7HUT1VQYXeDfzVU2CluOjTuUb m9UlKkKh0ZMYNv+fiCZtdcPeE9nBpBbwKAJZ5c08UXLifYYINarabPzA2UTWMMb7P/MX yrokCRs1ua1Qo65/iRBBjic53ekdk5siqV0YaAOyTQfwSOy0mlmKb0WVtZYAMo3y13fq RdyDYe9HslmsdqBrl6ldMyz9hCYXzqQpNEURkPep51aXtIZkvmqzO/vN99iD5tbJdC2W 4e6w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:date :message-id:dkim-signature; bh=zKiuiUnwys1EZdrdvDtRNwH7JCyivzB1+P/LA+9LZls=; fh=Lvb/8Im8xYYpqFf8B85QH0Gu7C/O1zq/23RFOIwML5o=; b=hdJgvupLoFCJni7w+SKXgH/LxG5bXqWkV2uBTO9+ZV89PzKcnz/ryryo3Ol7yJYmRZ Z7yw8adU7PvtrQ0D25IbzsmXplI2tyQu/AGlrPTxFvODZRTE9OmjJFqAT5DliB46x/yT fgPi5OrlMrZRkHJzM7MWNSYBMFE4afKbn/jpNC22x0Hm17AOk2L9iBO5Cr687+a9ql/6 jIPNomo7iAFHoiWF1M9yB1wrNjQqC+Dfh4zEeLhZNyobxJKRTEwKlAJ3ietkYD4Vhu2t KDJbL+k1Xapx/DR2u7cIBG+cdv0+l+iB40ycsDKLAjnLng2c0rLQXBeM1ATn9U1DYGDU jFzw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b="yxz/3Ith"; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of khorenko@virtuozzo.com designates 2a01:111:f403:c200::1 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from DB3PR0202CU003.outbound.protection.outlook.com (mail-northeuropeazlp170100001.outbound.protection.outlook.com. [2a01:111:f403:c200::1]) by mx.google.com with ESMTPS id 41be03b00d2f7-cc455109bf4si3791364a12.2.2026.09.04.02.59.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 02:59:56 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 2a01:111:f403:c200::1 as permitted sender) client-ip=2a01:111:f403:c200::1; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b="yxz/3Ith"; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of khorenko@virtuozzo.com designates 2a01:111:f403:c200::1 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vNM/N7FLgzNNFVfm7wn6YM4EZUtI7V6ErsW6JSoSgvkr7hcYDVX1WDUNC8e3cvz4afw5kd9TbzWTw2y75c911xawZ6SqaBRwoH4aA5C8GOUKfiYgHx7hOpbjqyR9/G0j+KjCifhIrd+FQPbmJlj0aZb4yhsSIea12Mz9prGjkQYY+wp0ykc3X+RHhAUQvJxUlIHeEZTAibASUXd3qDRutQ3asW41w3rYkLpzSAQsHgON8PghGFLk9hrzQjJHwrAC83o/Y1jkZ2Lad+YRcLOzlqcQd8Vxs1o4Y7ceC9HN66CADgK0NCnFPT87xQoiD7hSfxXRhTS+KnrKbBhHSpapRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zKiuiUnwys1EZdrdvDtRNwH7JCyivzB1+P/LA+9LZls=; b=SmDG/WrtHpF3ktaZoAa55sTuawj/F8RBiKmwAZP8WPXCv2irdPOeJh3Xc0+IQeB2TynmVH/HgO/LtwtjlbF+UNF6Qp9CHHPswmXSCJpxYUT33j0cICZbLgQ6BBkhV30vhr2ITgxKTzfII67QohmvPp0GZJKL2tPMTIJKGA3NPlo+HAbV/6skLMZdhmMkzj6xYJjooJZbBqN8Du4VfBHd1Bgprm3JKOZ7oIbb8unxa5Qn0ezfx13GTpRMFGa57jYVgwepWilr/wUYiUFRWzhe6e67dSIwZ0Xot9HcTt5n9Cw9aiaPJTH5IDzZgE6H9P22jqCo8dDgQN+evOPxce57dA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zKiuiUnwys1EZdrdvDtRNwH7JCyivzB1+P/LA+9LZls=; b=yxz/3ItheRfgR6NnG+yVJlXlsC+wN9EMYaWfRLRnxHrOaakxNRajkRfQS35Q5VpH3B9FubRrssKJxZliyXKXXWGFvO9uZnSKZTl82AYHLiRelzAlq/M/eaO9et8jwgeb984OCDgtAsue2Nr4+LQO58cVRZCCQQERqH/u+KmgdVxJ4SHliknlBIKZAwSVom2UN7zwBVz7B+E4A3s5y2+RxNBOEwnXhsmdeS3IxLHq7OVmeXKnFBKkEYnZ9EuM8ot/IR4C0cqZGdl7U0O7eQbA5moJqda7mg+7laoy17uU7T1CEeThcEjbBmCdDpviAAmzVDn2ONDNo1gxrmZOc2mfNA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from PA6PR08MB10708.eurprd08.prod.outlook.com (2603:10a6:102:3c7::20) by DB8PR08MB5355.eurprd08.prod.outlook.com (2603:10a6:10:11f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.382.10; Fri, 4 Sep 2026 09:59:48 +0000 Received: from PA6PR08MB10708.eurprd08.prod.outlook.com ([fe80::1999:c6db:dc55:494a]) by PA6PR08MB10708.eurprd08.prod.outlook.com ([fe80::1999:c6db:dc55:494a%4]) with mapi id 15.21.0382.007; Fri, 4 Sep 2026 09:59:48 +0000 Message-ID: <323dd29a-d9dd-46a9-8be2-18515f45ed2e@virtuozzo.com> Date: Fri, 4 Sep 2026 11:59:46 +0200 User-Agent: Mozilla Thunderbird To: Liu Kui , Vladimir Riabchun References: <20260904015755.23985-1-kui.liu@virtuozzo.com> Content-Language: en-US, ru, sr From: Konstantin Khorenko In-Reply-To: <20260904015755.23985-1-kui.liu@virtuozzo.com> X-ClientProxiedBy: FR4P281CA0035.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:c7::19) To PA6PR08MB10708.eurprd08.prod.outlook.com (2603:10a6:102:3c7::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA6PR08MB10708:EE_|DB8PR08MB5355:EE_ X-MS-Office365-Filtering-Correlation-Id: 0edadb49-8bd4-44ee-fd98-08df0a6b4103 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|1800799024|376014|23010399003|18002099003|22082099003|56012099006|10067099003|6133799003|5023799004; X-Microsoft-Antispam-Message-Info: y/WdnWohNLy3JZLY3OJN0hBIbY0cwYK3tiusynL7Whd8DVN3tYBOriyzc0BtFV6d9SNqWZduDmoUnktQFLLnvmhVpG0/GDVlEsUrWzWFuxzb34H9kE8POe7eW5CnNSdUE6M/OQuFezwHIP/x3sL7m+Q3Gipt6zsmVnjlLIpFAwD17mFbF/5WZGR3ApnCVHjfvn/imIE7MJog8V3lnpnqtQ7WlG2okA54X0Sv2n+YoBL1/Sjjc+nWqYpHNL8UevI7pRwIYHv6WSPttSM8eptCDlgFN59iNtPEnuX3YFbUNxcE96RkocVRKyj/6NuDn/bubEHk+NcZrHNprq8+2R+tRWvNpqpnNOJtipSXOking47VujVrbZUkr3oBpWB7PYuct6M7JDQL9C5Lpk/CdW4uW5DgeSvOh9zXMrIoqLZ+vDP5UaLi8lCao97HxvzE31ACNQBJgLcgd69mtU4VmiSaZPU30Ua8FoJ7GnV3Vsi5QMrDEYK+sN8nO62tx4cS4X9a1mYyLALFuOwlQRWOD0oc9hMP0F2F9xffDW6Kt5fPQulC7iocpYUJ+g8NWHEc8aoo8LoblnVWdKJLtONnrLwMEjMxw6vSXOJYGfEXkcBmfJoTdcCqpiVtvpb4nGkk+TkrgCEpRyEBhxJ5URgl8XDOFUZQrboOqeQC5PAdhTNPIxM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA6PR08MB10708.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(18002099003)(22082099003)(56012099006)(10067099003)(6133799003)(5023799004); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MXVFanV1dExES1NGVUhZeFFqV3dPS0MrVmdoY1gvcmpZbG9Jc0Rxb0YwYTNE?= =?utf-8?B?a2IwS1VpMU80Sm4yTTJDdUgzN3FSeTRaY1drdFluZjk5bExSTmlWRE5GbndL?= =?utf-8?B?U0E3VTA0U2twbitiTmQrOVBVTUNEV2hYcXBaQ0F5eExDbWhvdVVGQ2FJU1B5?= =?utf-8?B?R2p4U1owRWd2SGhUYlk3M3habitmdS9sbjFSSmNVMnA3Zm1jMkZ5d3U4cDVZ?= =?utf-8?B?akxIcDJKVzNMOXBWano4QUs1UTBrQSswNWtxUmpyQ0RSSE9IN05lTyswcFRG?= =?utf-8?B?d1dCMnFzOXp4blg5N0xLWXdEVURQeVU2Z3JBY2l0d2ZhelhidXhMV3FwamxW?= =?utf-8?B?MVN1RlU4TkNQOUZhenVodWFBaFFOQnpYb21BZXdPdnVxQW9ZaEVvZWQzMk8w?= =?utf-8?B?YmhqN2ppeXpwVFNpY2xOZmRIRnRLb2ZHZmt5VWVFYk9ubHdrdXBLRllNQzll?= =?utf-8?B?T1BITzY5Zmc5QmVsVnhhdUs1TytuWHdQYVoyNmllNUNTeCtTVVlXckRqNTZR?= =?utf-8?B?UlRYK2FWL1JRT2E4MkFCYnBOT2E4elB1U0R5ZFk1cmt4ZElOKzJRU0MxTUNX?= =?utf-8?B?dUUrMEIwMmtveUVPc2ZSdXMxVk9BYndPeUJaTWhRd1FvTHQvc2srMVFmeVE4?= =?utf-8?B?TVpVeWRNZW1kNHdXVTE1dmlGS2xmYVA5QXlVQzI1a1NjdkNlSmFteURSSTdr?= =?utf-8?B?V3BvY0NsTWI5NG5HSE9sVXZsY004RmdZbzV4bGs1ZFBERjU0NE1GdkFkQUhV?= =?utf-8?B?V2R5TW1vQnJCWWZ4NUZQbXY1RDFTcmZ4YjYwTVNSMHVmblV1MGZEOWJPL2or?= =?utf-8?B?SS9VbXBiY2ptZ0Izc2NoTFZ6N1lGYmgyM2twT1lHa1NEV1BMQlBLOUlhang0?= =?utf-8?B?TzdVNGhGL0VqLzV6ZWs4Vnlsd05WZnlZZVJ4Z3RqWjVkL0tmS1R5MzJCaThy?= =?utf-8?B?UThOMWV1R2VTdFFkc1BSVU5JQ0ZZQWRjVFVlMWhPNkpPUEd2czBsODkxRjIz?= =?utf-8?B?U09JS0RXTnRtSzZqMFlrcURJbThmeCtqSFo0NTM3emJRSmVQaWcyTjV2cXYw?= =?utf-8?B?SjhPZ1hRZXBnc1dLeEVkQWdHZThyd2xSZytwamJyeHg5UDg0ZVJyUjFjVTZs?= =?utf-8?B?d0RhaEpYdWpQVnE4VU9PaTRvdTMvdUFLalhXaDhOZmJWZDhtWGloL2JmZGdt?= =?utf-8?B?Vy9FY1RlbExCNVpVZ1NGL2twRkJ3cTdPUit3NU9zdndGN0crL2VTbXNnVHdW?= =?utf-8?B?SVVkRmtucDlVeHlpeU9CS2thYWlZdGtqMWZZQWpwSU9xYzRYbHhURjJ1dmp0?= =?utf-8?B?cFJXS2N4R3hYTTdHWHpHSUhpTit3c3I3Z1hjQkRYSFRJTGgwVE1nUDJnZVg4?= =?utf-8?B?V2duQ0FFMEF2U3dHeUJDTG1hZmNyNmRtZTRQS01ZSTMzOEMzbFFDMFZ5RUsw?= =?utf-8?B?aStOZzBDSEZIYU8vTERqRXhESytZcVFObk1KSXVpaE1kY0hLQ3hUWjJJeHJE?= =?utf-8?B?ZkdTVkc0Mnc5ZkZGSUt4dVh1am5QREFGSDFoK2NQaDhpWCtiZ1JrRE1rT0JK?= =?utf-8?B?ZzF1TkRTYnlMUG5NWk5nb1ZXczNUSWhtdkRNNEZhK1R4eGtZM2FCRTVWU3RV?= =?utf-8?B?bndlK255cURsazZJVFZpQ2xrOWExTWNJQVZlQ0J1YWpBcUpDdFROZC9EVjdx?= =?utf-8?B?UjZPTnR0MlAyNm1QS1J4MUdwenZ3bTdwbms4NDZzYmIxTmVlNXNoZDNVaEJs?= =?utf-8?B?RFViWFBMT0Y5RFlITS9qNy9Lc2I0bVJGOEhodDFVL211T2FaZlpXNkZXS0ZT?= =?utf-8?B?UGFRYVZGR0xBeGV1bUk1eTJYbkhybUgvTjhTRStTTGNSbitoZHRQbVNBWUhX?= =?utf-8?B?dnFRZFMycnFldThkQXpod3Y5S1A3Q2tlQWxQbjVaVUxBbVpyNnF0SXdEOFhr?= =?utf-8?B?c2pXdUFoelg2TVJqaWM5YzhOM1pFcDhDTTVCT3EyWFFQZTV1cEdnVkhIWVJ6?= =?utf-8?B?RFVJTWpoZHVIb3phajFDVHZqMmRDbVVFUktMMUhtQ3dtRmowRklqU3JvTm9n?= =?utf-8?B?UEZMWUl6eXBQV2ZLN0xYVXo3MkQ4UWVYekF6ZEhybUs4SkJXb3FMSUJiTXVZ?= =?utf-8?B?OWM0ODZLMlhWNlZybGhxaGFvZExlaGpHTGYrdk5lSXVoTjlEMWszTTFabSt2?= =?utf-8?B?QzNaVTM1MCtrTFg0MDgxbHlmbmxPekpTWEJNN05rUldmbjk2aUpUdVBhZEZR?= =?utf-8?B?ZytZSE1xMmJrb1lpODJxQ3N4aXdnNzZxUVNmMVhJS2dqbmFDRzQwT0cvd251?= =?utf-8?B?S1hSSG55ZEViQklTemFOc2VVUmZucDVMNUFuallWRGdOWmErQUMxZz09?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0edadb49-8bd4-44ee-fd98-08df0a6b4103 X-MS-Exchange-CrossTenant-AuthSource: PA6PR08MB10708.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 09:59:48.0507 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: fnS00j5RdL55u4oDu8tHX+J3rX0aiZRoSW7K78O6VmWTYCeY9ucLkuULZ4eE8FDOIYknv7QVUfQGSJ2Fx1ZDkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5355 X-OZ-Fwd: true Cc: devel@openvz.org, azaitsev@virtuozzo.com Subject: Re: [Devel] [PATCH VZ10 v2] fs/fuse kio: track pending kRPC connect via state machine, not a pointer 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 Hi Lui, the patch itself looks correct to me for a kernel that boots with it: CONNECT is entered only by pcs_krpc_connect() with a req queued, and pcs_rpc_send() guarantees msg->done() for every queued msg (ABORT/DESTROY fail it at once, WORK completes it at once, otherwise it sits in state_queue until WORK or a fatal rpc_abort()), so "CONNECT means a req is in flight" holds from the first connect on. The problem is the livepatch case this rework is made for. On the running kernel (without 7ae23fa1c145e and this patch) the invariant does not hold: - old krpc_connect_done() leaves state == CONNECT when the connect fails, it only wakes poll with EPOLLHUP; - old pcs_krpc_poll() returns 0 for CONNECT, so userspace sits in poll until its own connect timeout, then closes the fd; - only then old pcs_krpc_abort() moves CONNECT -> UNCONN. So at the moment the livepatch is applied, every krpc whose CS is currently unreachable is periodically in "CONNECT, no req in flight", and stays there for a whole userspace connect timeout on each retry. With the new code such a krpc never recovers: - new pcs_krpc_poll(): state CONNECT, gen matches -> 0, userspace waits for its timeout as before and closes the fd; - new pcs_krpc_release() -> pcs_krpc_abort(): state CONNECT -> gen++ only, state stays CONNECT; - there is no req whose completion would settle the state to UNCONN; - every later pcs_krpc_connect() for this CS returns -EPERM, until the krpc is destroyed (i.e. until the mount is recreated). Note this can not be fixed in the patched code by looking at the krpc alone: the new code has no way to tell "req in flight" from "stale CONNECT inherited from the old kernel", that is exactly the information connect_req used to carry. i'm not sure if we need take care of this, may be we can consider the probability of that very low. But in case we deside to handle it, options I see: 1. Livepatch post-patch callback: walk fuse_conn_list -> kio ctx -> krpcset, and for every krpc in CONNECT check whether its rpc has a msg with done == krpc_connect_done in input_queue / state_queue; if none, reset state to UNCONN. Correct but needs care with locking and reaching into fuse internals from the patch. 2. Livepatch-only self-healing: in the -EPERM branch of pcs_krpc_connect() (and/or in pcs_krpc_abort() for CONNECT) do the same queue check under ep->mutex and treat "CONNECT without a connect msg queued" as UNCONN. Cheap, only runs on the rare refusal path. There is a small window while rpc_queue_work() has the msg moved to its local list; a false "no req" there just leads to two reqs in flight, which the new code settles on its own (stale one -> UNCONN, live one dropped, userspace retries). 3. Operational: apply the livepatch while all CSes are reachable, or restart vstorage-mount after applying it, so all krpcs are recreated by the patched code. May be just to notify support about that so they can quicly restart vstorage-mount in case of a problem. Nothing needs to change in the mainline vz kernel version of the patch. -- Best regards, Konstantin Khorenko, Virtuozzo Linux Kernel Team On 9/4/26 03:57, Liu Kui wrote: > 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. > > 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. > > https://virtuozzo.atlassian.net/browse/VSTOR-135626 > > Signed-off-by: Liu Kui > --- > fs/fuse/kio/pcs/pcs_krpc.c | 63 ++++++++++++++++++++++++++++---------- > fs/fuse/kio/pcs/pcs_krpc.h | 2 -- > 2 files changed, 46 insertions(+), 19 deletions(-) > > diff --git a/fs/fuse/kio/pcs/pcs_krpc.c b/fs/fuse/kio/pcs/pcs_krpc.c > index 0930fb4adf12..9d534b037cd1 100644 > --- a/fs/fuse/kio/pcs/pcs_krpc.c > +++ b/fs/fuse/kio/pcs/pcs_krpc.c > @@ -787,8 +787,15 @@ static int pcs_krpc_abort(struct pcs_krpc *krpc) > spin_lock(&krpc->lock); > > if (krpc->state != PCS_KRPC_STATE_CONNECTED) { > + /* > + * A pending connect req stays in flight and the state stays > + * CONNECT, refusing new connects until the req completes. > + * Advancing gen disowns the req, so that a late completion > + * settles the state to UNCONN in krpc_connect_done() instead > + * of committing this dead session on success. > + */ > if (krpc->state == PCS_KRPC_STATE_CONNECT) > - krpc->state = PCS_KRPC_STATE_UNCONN; > + krpc->gen++; > spin_unlock(&krpc->lock); > return 0; > } > @@ -949,15 +956,15 @@ static __poll_t pcs_krpc_poll(struct file *file, poll_table *wait) > > poll_wait(file, &krpc->poll_wait, wait); > > - if (unlikely(ctx->gen != krpc->gen)) { > - pollflags |= EPOLLERR; > - return pollflags; > - } > - > spin_lock(&krpc->lock); > > - if (krpc->state == PCS_KRPC_STATE_ABORTED || > - (krpc->state == PCS_KRPC_STATE_CONNECT && !krpc->connect_req)) { > + /* > + * when ctx->gen == krpc->gen, UNCONN here can only mean its > + * connect attempt has failed (see krpc_connect_done()). > + */ > + if (ctx->gen != krpc->gen || > + krpc->state == PCS_KRPC_STATE_ABORTED || > + krpc->state == PCS_KRPC_STATE_UNCONN) { > pollflags |= EPOLLERR; > } else if (krpc->state == PCS_KRPC_STATE_CONNECTED) { > pollflags |= EPOLLOUT; > @@ -1047,7 +1054,6 @@ int pcs_krpc_create(struct pcs_krpc_set *krpcs, PCS_NODE_ID_T *id, > krpc->gen = 0; > krpc->state = PCS_KRPC_STATE_UNCONN; > krpc->cs = NULL; > - krpc->connect_req = NULL; > > krpc->rpc = pcs_rpc_clnt_create(&cc_from_krpcset(krpcs)->eng, id, addr, cs_flags); > if (!krpc->rpc) { > @@ -1099,10 +1105,20 @@ static void krpc_connect_done(struct pcs_msg *msg) > } > > spin_lock(&krpc->lock); > - if (krpc->connect_req == req) > - krpc->connect_req = NULL; > - /* from a stale session, do nothing */ > - if (req->gen != krpc->gen || krpc->state != PCS_KRPC_STATE_CONNECT) { > + /* the session was aborted or destroyed, nothing to settle */ > + if (krpc->state != PCS_KRPC_STATE_CONNECT) { > + spin_unlock(&krpc->lock); > + goto out; > + } > + > + if (req->gen != krpc->gen) { > + /* > + * The session that started this connect was aborted while the > + * req was in flight (pcs_krpc_abort() advanced gen): settle > + * the state so a new connect is allowed, but never commit the > + * dead session, even on success. > + */ > + krpc->state = PCS_KRPC_STATE_UNCONN; > spin_unlock(&krpc->lock); > goto out; > } > @@ -1110,6 +1126,14 @@ static void krpc_connect_done(struct pcs_msg *msg) > if (!pcs_if_error(&msg->error)) { > krpc->state = PCS_KRPC_STATE_CONNECTED; > pollflags = EPOLLOUT; > + } else { > + /* > + * Connect failed: settle back to UNCONN so that a new connect > + * is allowed again, and report the failure to poll(). Since > + * gen is unchanged, the current session's poll sees UNCONN > + * and returns EPOLLERR. > + */ > + krpc->state = PCS_KRPC_STATE_UNCONN; > } > spin_unlock(&krpc->lock); > > @@ -1167,9 +1191,15 @@ int pcs_krpc_connect(struct pcs_krpc_set *krpcs, PCS_NODE_ID_T *id) > } > > spin_lock(&krpc->lock); > - if (krpc->state == PCS_KRPC_STATE_CONNECTED || > - krpc->state == PCS_KRPC_STATE_DESTROYED || > - krpc->connect_req) { > + /* > + * A connect is allowed only when there is neither an established > + * session nor a connect req in flight (CONNECT state, see > + * krpc_connect_done()). This limits connect reqs to one at a time: > + * if userspace gave up on a connect and retries, the new connect > + * fails immediately until the old req completes. > + */ > + if (krpc->state != PCS_KRPC_STATE_UNCONN && > + krpc->state != PCS_KRPC_STATE_ABORTED) { > spin_unlock(&krpc->lock); > err = -EPERM; > /* fput() drops ctx and its krpc reference via pcs_krpc_release() */ > @@ -1181,7 +1211,6 @@ int pcs_krpc_connect(struct pcs_krpc_set *krpcs, PCS_NODE_ID_T *id) > connect_req->gen = krpc->gen; > connect_req->krpc = pcs_krpc_get(krpc); > krpc->state = PCS_KRPC_STATE_CONNECT; > - krpc->connect_req = connect_req; > spin_unlock(&krpc->lock); > > /* publish the fd only after the connect is committed */ > diff --git a/fs/fuse/kio/pcs/pcs_krpc.h b/fs/fuse/kio/pcs/pcs_krpc.h > index 803376895cc5..96b4815abf86 100644 > --- a/fs/fuse/kio/pcs/pcs_krpc.h > +++ b/fs/fuse/kio/pcs/pcs_krpc.h > @@ -84,8 +84,6 @@ struct pcs_krpc { > /** Wait queue head for poll */ > wait_queue_head_t poll_wait; > struct pcs_cs *cs; > - > - struct krpc_connect_req *connect_req; > }; > > struct pcs_krpc_context { _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel