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 620C68017D for ; Tue, 13 Oct 2026 12:48:01 +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 69DCkZoZ014263; Tue, 13 Oct 2026 15:46:36 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69DCkZoZ014263 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="TSJcpKos" Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69DCkVZi014259 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Tue, 13 Oct 2026 15:46:32 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69DCkVZi014259 Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2e869e00005so26549525ad.2 for ; Tue, 13 Oct 2026 05:46:32 -0700 (PDT) X-Gm-Message-State: AFq9FYI7mWLuYQcp//MH5fU9CYPs73mqHo4kvnG66v+vIqYOcg+3IpUV wIQUW/M0eRweb/jEAyDWx6OfejgxiBH+BcUc7OfNW0TeIeBv5t/w4D66vi7aiZIMZOAIU36QPbH BLSmYr9qlrB5MvAisOwnjW3c0uI2jXpWbUUVppbauqXF+nP9B3sgs7w== X-Gm-Gg: AYBFou0UYIQ3fQb1Ek3k6gfOdeNehSi/tVslCwe39Iv4Uya6yF8sw3GbSoKQhbzZIVJ WdKqGWlYIRpNFJjlvrs1EhLLxV50xvEhKQ0mGlzW5JFw4vPk/MmNd+WQbfGtnl016IzIxR+m8tI vM6XO+fZ5+RXaPEBpCYxE0HBidq4LThYKFCSzO0MzOVx/oFj0IiYiGFArz0RWxFSLXTYMnGdHFv MLzJNGZLSeHUA18zCC68G3d78GNUUnbCNC10T+bDQzyAyuMSbRtk7V8To1cOmE+o+HFkqN4iU8X A/EIRTFCPf66ICp9DZvLviQAlIwIKUx69C06e8ttGjaPNiH9dAnz/RtaoINncslOVjztzHejR6m jS+aKJktbmJt6HsXWj5o+p1tlR3pgyNisvP0jdwF8AEbIW69GqBf0JN7SRckHRLhNg3Jj5rV1Na I+oa9qMyLaVQvZa0fZ6yJn5dK3vDXLPRVUBrI= X-Received: by 2002:a17:903:2309:b0:2e5:38bf:cb43 with SMTP id d9443c01a7336-2e8427f0c01mr113302895ad.2.1791895591149; Tue, 13 Oct 2026 05:46:31 -0700 (PDT) X-Received: by 2002:a17:903:2309:b0:2e5:38bf:cb43 with SMTP id d9443c01a7336-2e8427f0c01mr113302585ad.2.1791895590300; Tue, 13 Oct 2026 05:46:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1791895590; cv=pass; d=google.com; s=arc-20260327; b=qH+8tKjAowrsVQ4U1WcZfLImEcYsG1yRcm+Zjv91hTLq4JIn7tb+rSWEBsDSF5jzGK JxyHodC9eWDUFt+CvlGB4AVzJ1+8vpdMeT9K6a6ztsyDPdySRAsThsnNC0TaGHHJwky+ Q0fYtoEu8fwoBXgmq3SRbc0tjfPO2tBCGx5YOeyoycG93FKLb0IHkHvsaGhzr74UuTsj VCuB/zqnsr+kEWsqRQfMx+9lxILRQo3L6EoGwQ5TPLv0/gqcltD8zUuQifEJI6rriAmc H3NeTX9P373fweyX8ezkLGR5naa+Yv3nQ4BdEz98mIwcoVIAK7e8Eym6Ly3Sgxi+IYyw slMw== 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=RsIxVlKS9387v39qjsf/cO8UQrWM+4O7X7DX5UFhd+I=; fh=a7O+alUt1cWQrLe5ChyqsVBdToUocbAn8sZxqBezD24=; b=lfaydW/tQ+Rx5Hb3bBpJ+6lPPZGLlaTVY1cUkHr5j+/VOrDb3cNvuieoK6YH5u74ws GeTluOGATdQnq71r0NxvdsraL6Mgqav65cb88ONx26jsLtsmXWEiXA4mebcxZyLOX2EM VQ0Ap4mEwj4AVl+loCE8CM3UwpMu4nPoXw+BFC5fq3bhAa3wAOd17Lzors70XcEKUUo+ Pyu4gBF58iCmT9wFa7X+pbtuEAaIdXC/zjvzvqEvDLlYZKB0LnzPJ4KqCzUNatFE37lW 7hY8rEK0CzxU3nyDZV5A0mNJTcul5fCWbGm9yMVxh7h3h6aUBs+Si4I6ZGx9JIlblZtl CJyw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=TSJcpKos; 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 alexander.ivanov@virtuozzo.com designates 2a01:111:f403:c200::1 as permitted sender) smtp.mailfrom=alexander.ivanov@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 d9443c01a7336-2e842357a0dsi250304895ad.197.2026.10.13.05.46.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2026 05:46:30 -0700 (PDT) Received-SPF: pass (google.com: domain of alexander.ivanov@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=TSJcpKos; 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 alexander.ivanov@virtuozzo.com designates 2a01:111:f403:c200::1 as permitted sender) smtp.mailfrom=alexander.ivanov@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=AULVgULFmpx837qjqmaqNImiza3E+U7QXg3P2FFnGqmWqy5PNLyFxQ4BJTpkZhinv+tLmZCQ9td4zwZrfErHorC9KpzpUmPWAo7IXtw5strZQ/HrNDZXF1AJXs6r4PTH1HWh4iWa9SLC7IQL9HiGNz7eaUryEnLdUESewGXeJuEv/sFZoEl2zv5qNPxmkVxSnMzARkoq6aFFErXkElO4TxyGDgCMxmjzkYMf3koQwQ6A/QefgdYfyN3Qm+1YYkxgCVIm5pzInTkbIFbqA17ncAv8cv6TASXxJq1ZyTabAJjSFi0PbMX72xohWF1/L6yL1tPAE6Q3I4JAiUiDtshU/Q== 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=RsIxVlKS9387v39qjsf/cO8UQrWM+4O7X7DX5UFhd+I=; b=lmEbidZhjrZuQf7FdQmJpOGGjP2G6DqsCV/m0mYwq/vxmCPu8RNYygwifVQogNroRpwrz3gCim3r6Ayfo4ZI83dGy/a46gACpIEEsYZK7TSXs5+lwp/MnYFbhbJGWK+EzqVZ+uBEqh3m3y/scWH3nTM5r+5UJETlDSQVeWRJt0lpvD+z6itwKJFVBf4vrxuoyvCHzwws014SxWLzMcDrFh5mRMbf+Ovpv4mI0HoBne0LaIsXck272Xl1eCu+Wy7n8cnUJbnj1RgYMTJLOBxRcYyQWCI39HBjSFXcXy9CmZjDOEgc1Ve8ywv89zBB9v6MuYom4Yk9Ghc9lQfOB21jGw== 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=RsIxVlKS9387v39qjsf/cO8UQrWM+4O7X7DX5UFhd+I=; b=TSJcpKosZia0VdWxMK/kSEa1mvKPk8WjcBFGpmDZKMgsT3GBxIDXilrddLF/eAnz/us+TJ7+7JeQnh3UL3TQfTx1JfbTksYlZ1E1cfEN3F8+oOevMyzkPhzNC/pXfJZcNJptDEltatwnvG2OCCfYuomIsdXBF4Z2UVLr6bcWHTEiEZIJLQMBgdGArFXdz4xu2lQ3A18YHHIcZBJ62fbKRLCvjonXurPyWSLYczM1oK3ZizOw/C8Uao8BvCT2OHg7AvuXvPSso2omQ1W0PtBR/L9YjrO2IhrtFrcrL//TX6ZzgR/o700PaaL6njcr993u/e6fRKO9UxmVzzoAENA+tQ== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) by DU4PR08MB11079.eurprd08.prod.outlook.com (2603:10a6:10:577::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.10; Tue, 13 Oct 2026 12:46:27 +0000 Received: from VI0PR08MB10743.eurprd08.prod.outlook.com ([fe80::7a7c:d078:f125:f16a]) by VI0PR08MB10743.eurprd08.prod.outlook.com ([fe80::7a7c:d078:f125:f16a%6]) with mapi id 15.21.0522.011; Tue, 13 Oct 2026 12:46:26 +0000 Message-ID: <797d8cba-d64c-453b-9711-2287223f4d11@virtuozzo.com> Date: Tue, 13 Oct 2026 14:46:25 +0200 User-Agent: Mozilla Thunderbird To: no-reply@sashiko.virtuozzo.com, den@openvz.org References: <20261013111604.142989-1-alexander.ivanov@virtuozzo.com> <20261013111604.142989-12-alexander.ivanov@virtuozzo.com> <010701a1350c284d-137ccce0-774e-492c-ab3b-2a320c743e99-000000@eu-central-1.amazonses.com> Content-Language: en-US From: Alexander Ivanov In-Reply-To: <010701a1350c284d-137ccce0-774e-492c-ab3b-2a320c743e99-000000@eu-central-1.amazonses.com> X-ClientProxiedBy: FR2P281CA0020.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::7) To VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10743:EE_|DU4PR08MB11079:EE_ X-MS-Office365-Filtering-Correlation-Id: effb9b2d-6ebb-4830-3b56-08df2927fecc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|366016|376014|23010399003|18002099003|10067099003|22082099003|4143699003|261009223027099003|56012099006|5023799004; X-Microsoft-Antispam-Message-Info: J5op6R2DMZXsS/8+YuG1l6rWIjSEiZ2BuLKM6nqDNVpIvMxJCxKAH7H2mqLv7jeK2x5XP8neh7DQLYYHCWQaKJZHtyG2AzxpInhaSs8D2KSuBGwUoL0nDZ6h4QZBvvT4F1QNXtJPnXyEteLaTiiCl4Y3lZi2SkKw1oJKcFOSJQ1KG7KvoUcjUWu1vLE4tTvTNBJudzMPgOi0t6MdVrU4LYD4WZQAWFBou53lKCzH4cUe+lMV7n063ULcPTTJ+JoJQm9vpgR6zFlE2EJDaoldVIDlJEJjmWfKOqHQYerJ49jcAtErg85Dv9DxPD37DIZ5VHmstiBEpnvA/pqSGX6AWiqI+YjCYS5BkvY7DSKRoNfGY1ua5p7mlUI3in6vifdYKDQj7PThpshrNBzN2wrzXYVwajY4mJEDZd1XBvV4u4DkFTfCZCx3DLLmOAg008AV9LVxFDf2H5i0fjS1F952vbZunwH6mKgSWa47VkjEm16qOoxsn4SA4D2preUEkt4+eXtwlpYRfrh9xhSW9ZTb1sr0Y+aCrn2JkUeNHD30JTK7Fb1wTngp+x6YKB+0qsBWeu0al+/miHjwBPJ81hDN5yVYbkMnr0ByvCorw7JbQcn+ItLAOQi6jEOmuYYItlZV3p2uA21HTg5Ejkp+M02CpLSrZhb3HxFfFQT0hmVQXrU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI0PR08MB10743.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(18002099003)(10067099003)(22082099003)(4143699003)(261009223027099003)(56012099006)(5023799004); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eXYrTzRoNUxxbXZjYXA3OEFNbzVtK0NOdEZNWDF3Tmp2dGdYTnZ3Nk9JeXN2?= =?utf-8?B?SEpTcFN0N1hFY2JKM1FtSHkyejMrZFU3YVRwZi9mZSs5c1BrRzI2NVV2N3pT?= =?utf-8?B?QjY5MkE5M0lvdUlycVEyOWowZGh4S3BuSERCdjFodjkvd2FacTJFYmNMWDcv?= =?utf-8?B?VzllSVlVSlJ0c1pDTDk1aks4Rkc4MFliaVJBY21kVFNESjZ2R1RFMnRQS1do?= =?utf-8?B?Z3pYKytqTG5VOFkwZVZNdnpRdWRPOEtOeU1Ta2pQL212YVFGc1Z3ckhqUlMr?= =?utf-8?B?aCtrMmpoanY3RVpkU2x6bkFYOTM3ZnZBcmVpcmFPVnZVRFN0VmhrZWJYWkNS?= =?utf-8?B?WkVhL1Y5blhMSmh4aUtwUDhEeGp0K1huK0t5dkprdTJXMFJJaHd3bWREbDV2?= =?utf-8?B?dFVzbjlsOEVMYklScUtsYXdlSDJudkd1bUFuWDRTT25vdW9udjMxUDZsTGJv?= =?utf-8?B?ZHNzSzNwbHowWE5JcEYzbExmUkQ4OGtYSHRFYTJxQnJSbzl6TnQyN0Vsd0ZI?= =?utf-8?B?aW56R0QzLzdBZlFUUlJIaGZsRE1nUGNjU0R5bVZyRmNrclhIT1hJbzJhYVEx?= =?utf-8?B?VVdSeE90MThHbzVBajY2eFBRNk5PWjRUd1FaV0J5ZHVOTS9EYUMrSUNad1dI?= =?utf-8?B?REFHeC9CZXVTYkNWdE5rbE9yeWxCQXFFNmZoSFVHTmFxTTRXNTk1MVNaNXdv?= =?utf-8?B?WUNwR3d6WlA5Yi92SHBKaXNHQ2VRbG16OUp4L2dCc3AwdjBhWjhNOFcvRjQ4?= =?utf-8?B?VWR3QTVRdGF5K3dCVVVoeTNBM1hYU21TeE9RemtOcjJqRm5WZDNYcHU3MmpM?= =?utf-8?B?YTlWS0xNQU9ENTdxdzUySGRyQXZVWW9kMnR5YUVMbzloWnBTbDhUc1Y1dmh0?= =?utf-8?B?T01IR083TjRjZVZabUFKN09nTXBGVFdFR2tGQUQrd2xUR25PeXFxdVRyQStq?= =?utf-8?B?bGVTVUZFaUFzQVhuM0h0dVlOOVJGTXMreGw5NkJTTnhFTWhoR0U4YUhvSmk5?= =?utf-8?B?OGdpU2J1NS81RTVYaGN6SEVPN0RMRHRqVXhNaE93bHR1YWNIbFgybmtSUnBt?= =?utf-8?B?NTdzMkNFUTFDUUhJcy93VXNjM09tNzVJYm5JK3E2eU10TG8xcXNYUnFIK3hY?= =?utf-8?B?UjMwUVQ2eUtxMlMwTVJvUitqd01yNnhtd05iQ0VkMWdscFI2TStHbDRocUxV?= =?utf-8?B?dng3WnFkcnBGVmpsMVl1dDhYRHl1MnB3M3lRKzRBajcwZTd6QVYrbzJ1Zzht?= =?utf-8?B?THhXNG5rQ0cvN1pKeUlVYzlzQXplcE10REFzN3JKcXhodm5Ga3VrcmtsNlNJ?= =?utf-8?B?YTJXY2RVR2VkajdlcXVqalRNcW1XKytVcFY5Tmk0dllXR2JFS2pzeXBJT3NE?= =?utf-8?B?WDd3T1ArM1BQb0lJRnE5SStZL0h3ZmNmVk52S0ptQkVJVDlYakRKaXdra00w?= =?utf-8?B?emtYc1ExOFdEZWdSTUdlNEFYRTNKWDE5QU9IVld4SUdyQVc5RWVVMXJwWlVx?= =?utf-8?B?elhHNGU5bTVPT3ZkTEpNdlBUZDhSdUxwdWdraHJSbWVWeFFEMFBCS3poVzd5?= =?utf-8?B?aGs5YmtyZjNNNFp3aU1tZjVRakxBbURlSzVHTDViZVc0WWx1cThwMnZRY1hO?= =?utf-8?B?aEpjbG1CM3dWeXZGdDgrVkROVFdOZWZwZnk3L1BaU1lqMlFWYW9ncWVFTXhR?= =?utf-8?B?bmxOSXNQcFpKV0M5UVFYMzBpQVFnY2F4OFpqYzI0SHlONjVUL2hLZ1lEZ2NV?= =?utf-8?B?RXkrOUR1K21WSGlHTnpaQTB2eHAvTFc1WGhkRnMxQW85SWQvQkFpL2RBUHpZ?= =?utf-8?B?S3pKTkFTWTd4M3ZEL3VzdXNsdTlCbnJvQWpDRDJQWWFiMVlYZmtEVHhoTjh0?= =?utf-8?B?SmErTUVqTTBQbDhGbnp3MUY5ME05QVNSZks5Tzk2NGhrenZhbnZ2WXdJQWky?= =?utf-8?B?d0ZhY0hlOW5ZQlZhczBwM21INE5UbFZIMWE5ZzR3ZHBEK3FhQTVzcEhZU2Vw?= =?utf-8?B?c3RTdEhMVzJXalM1d1ZSekR3U01VUEI4Zm9vYXJzVXNkcUljTlJRczdiYUp6?= =?utf-8?B?K21LaWJqSGpkbFNHYnZaeHNrVXlOZ1BlS0NPbkowTVRxc3o1d0pBMEExUGJ2?= =?utf-8?B?SU1rWGJpd0ZLck9Hbm5OYjlkWXNRejhrRTlZeFdEZ29GWEUyajNpalhieXY0?= =?utf-8?B?WFJHLzhKZFJ0M1lRZUJ1dk1nRDlaVEJLTWZWZXFrR2tlMVd1cU1mM1BzeDAz?= =?utf-8?B?Z1Qva3BCOEpHdEVBZFY2WkRjKzBvU3NBbXlsbm5YcHBJVFQ4bno5aDljbFVY?= =?utf-8?B?S0pLT0FUMG9IMENwY3Q5b2YwWlkyRVBVNUNiYkQxakJKWEJpb0tRSEZJSm1n?= =?utf-8?Q?UkD7wnTyiAQs5cNI=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: effb9b2d-6ebb-4830-3b56-08df2927fecc X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10743.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 12:46:26.6805 (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: G7DLPy8KEa1IOgqHdIJZRNsnHveoa4TbIZsjkwiecgnnrnPnoZcB+Wpw0jB3mbGSeSmTqyS5CAQKxhuFfIQjtXSKLWZOz+mCoPkslDa+thQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU4PR08MB11079 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 v6 11/12] dm-ploop: reload metadata on resume 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org On 10/13/26 13:35, no-reply@sashiko.virtuozzo.com wrote: > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: > - [Medium] dm-ploop: postsuspend waits unkillably on inflight_md even in standby > - [Medium] dm-ploop: killed wait in postsuspend() leaves prealloc pending after device is marked suspended > -- > > commit 881f9bc269db1bbaa88bf766f12f3d91d98c7d92 > Author: Alexander Ivanov > > dm-ploop: reload metadata on resume > > This patch reloads the top delta header, the BAT of every delta and the > delta file sizes in ploop_preresume(), and rebuilds the BAT tree and > holes_bitmap. It also moves preallocation to after the reload and makes > postsuspend wait for pending preallocation and for inflight_md. Standby > state is now tracked per ploop instead of through the queue bit. > > Link: https://virtuozzo.atlassian.net/browse/VSTOR-148171 > >> diff --git a/drivers/md/dm-ploop-map.c b/drivers/md/dm-ploop-map.c >> --- a/drivers/md/dm-ploop-map.c >> +++ b/drivers/md/dm-ploop-map.c > [ ... ] > >> @@ -1259,6 +1259,12 @@ static int ploop_no_pending_prealloc(struct ploop *ploop) >> return ret; >> } >> >> +void ploop_wait_prealloc(struct ploop *ploop) >> +{ >> + wait_event_killable(ploop->dispatcher_wq_prealloc, >> + ploop_no_pending_prealloc(ploop)); >> +} >> + > [Severity: Medium] > The return value of wait_event_killable() is discarded here, so a killed > wait looks the same as a completed one to the caller. > > Can this leave a prealloc pending after the device is marked suspended? > > Suppose the dmsetup task gets a fatal signal while ploop_postsuspend() is > in ploop_wait_prealloc(), and prealloc_size or prealloc_in_progress is > still non-zero. Then: > > ploop_postsuspend() > ploop_wait_prealloc() /* returns -ERESTARTSYS, ignored */ > wait_event(ploop->inflight_md_wq, ...); > ploop_set_suspended(ti, true); > > The postsuspend callback returns void, so dm_suspend() cannot abort. The > old allocator thread keeps running and can still extend or truncate the top > delta. > > The new ploop's ploop_preresume() checks only its own prealloc state, which > is zero: > > ploop_preresume() > } else if (!ploop_is_standby(ploop) && > ploop_no_pending_prealloc(ploop)) { > reload = true; > ... > ret = ploop_reload_metadata(ploop); > > It therefore reloads and caches a file size that the old allocator is still > changing. Can the old allocator's later truncate then cut off clusters that > the new ploop has already written? > > The new comment in ploop_postsuspend() says "a ploop of a reloaded table may > see a stale size, and a late truncate of our allocator may shrink the file > under it", but nothing in the code prevents that outcome. Is there a way to > detect the killed wait, for example by checking the return value and > refusing to proceed? Known and documented: it needs a reload plus a fatal signal exactly during this wait. Postsuspend can't fail, so there's no way to refuse, and having no wait at all was strictly worse. >> diff --git a/drivers/md/dm-ploop-target.c b/drivers/md/dm-ploop-target.c >> --- a/drivers/md/dm-ploop-target.c >> +++ b/drivers/md/dm-ploop-target.c > [ ... ] > >> static void ploop_postsuspend(struct dm_target *ti) >> { >> + struct ploop *ploop = ti->private; >> + >> + /* >> + * Let the next resumed ploop (maybe of reloaded table) >> + * see final size of the top delta. Don't wait in standby >> + * mode: the allocator may be stuck on the dead file, while >> + * dm_replace() of libploop must be able to suspend the device >> + * to recover it. The wait is killable for the same reason. >> + * If the wait is skipped or killed, a ploop of a reloaded >> + * table may see a stale size, and a late truncate of our >> + * allocator may shrink the file under it. >> + */ >> + if (!ploop_is_standby(ploop)) >> + ploop_wait_prealloc(ploop); >> + /* >> + * Data bios are completed before BAT writeback is finished >> + * (see ploop_put_piwb()), so wait for it explicitly to make >> + * md pages clean for ploop_reload_metadata(). >> + */ >> + wait_event(ploop->inflight_md_wq, !atomic_read(&ploop->inflight_md)); > [Severity: Medium] > The prealloc wait above is skipped in standby and is killable, because the > comment says the allocator may be stuck on a dead file. The inflight_md > wait here is neither. > > Can this wait_event() hang suspend in uninterruptible sleep on a failing > device? > > inflight_md only drops when the BAT write pio completes: > > ploop_index_wb_submit() > ploop_runners_add_work(ploop, pio); /* file IO on the top delta */ > ... > ploop_put_piwb() > ploop_dec_inflight_md() > if (atomic_dec_and_test(&ploop->inflight_md)) > wake_up_locked(&ploop->inflight_md_wq); > > If the device is in standby because of a hung backing file and a BAT write > is in flight on that same file, inflight_md never reaches zero. > ploop_presuspend() only waits for kt_worker->inflight_pios, so it does not > drain this. > > Before this patch postsuspend never waited on inflight_md, so dm_replace() > could suspend such a device. Should this wait also be skipped in standby > and made killable, like ploop_wait_prealloc()? > > A follow-up patch in the series, 'dm-ploop: truncate unused tail of top > delta on suspend', keeps this wait_event() unchanged and moves the call > under ctl_rwsem, so a hang there would hold ctl_rwsem for write while > waiting. Skipping the wait or making it killable just moves the hang to resume or dtr, which must wait for in-flight BAT writes anyway. Unlike the allocator, a BAT write is a plain pio, so it completes, with an error if need be. If the file is dead enough for it to hang, data IO hangs too and suspend never gets this far. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel