From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (mail.openvz.org [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id CB0FE81377 for ; Mon, 9 Nov 2026 13:27:31 +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 6A9DQ86I032223; Mon, 9 Nov 2026 16:26:10 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A9DQ86I032223 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="WjdS3GBp" Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A9DQ5t0032219 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Mon, 9 Nov 2026 16:26:06 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A9DQ5t0032219 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-8b0e4c2f052so11437667b3.3 for ; Mon, 09 Nov 2026 05:26:06 -0800 (PST) X-Gm-Message-State: APuU4Z816t1dVr29GVDxfKIW81wQN7Z59kRAL11+w50i6e880busTo2X 9jLFE74uJyxwlYzFwBgmQ1W0ZJ1qqv1+h06Onj/UI+k/MbCoRMO5+PAqLHngYySdQuAIKJ4Zra8 8KdvScN9QDugaSbadkAEA05ADVi6iUpDpzd3QhrkO1CbihcAtgNgSgA== X-Gm-Gg: AYBFou322JcqtIJo6n9xU9DDojKWO40ddaMnWHvgH9G0Cw8HG2Ng+Kxacq0ousQqUJ9 hZ0aZk/Vgkhjfr1KKzG0eNEXMGg+byf60hQBmEq94niS3H2yKeiE1Zj5uk3OeSQdiaDmMZpvgUu 6RtjoQR4+rgj93dEg0wsR0859eCRi3KMGYMo+4PjqgWBLQn5EvfviUrHyHqilPWp4eHXoG8fmCi 76SxK3PZlC1KnHgWzN0lYCouJbuIlPfqXQhf9A1X5N0HCnjmD8JI8TTzJxWiP/ogRdOefaJEKn7 Lu4KCmOzHXzUHG1TUmKjsdUgKwpv4iJIvilH3fntuzDhqr5ymrwp1eyeeHHWvPms9dSMhYgIHwF kTbdU/GBnsQqfHp/fvqy5KMZ+/dqqQ4iQOmj6vkmuIGyYfVmuwo9a6o62tmHikGKZPS4Ez4HfXJ UyEV6J/JcmN4PrBl7awRrxxgI6Ylr+5Y8= X-Received: by 2002:a05:690c:c50f:b0:8b3:2c71:b325 with SMTP id 00721157ae682-8b36c667826mr24591697b3.0.1794230765530; Mon, 09 Nov 2026 05:26:05 -0800 (PST) X-Received: by 2002:a05:690c:c50f:b0:8b3:2c71:b325 with SMTP id 00721157ae682-8b36c667826mr24591507b3.0.1794230764949; Mon, 09 Nov 2026 05:26:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1794230764; cv=pass; d=google.com; s=arc-20260327; b=Zfi89OdNNDeQtdOVfAV9FDwFkoDmBcI1xS+Bnoc1pmWtELywKNqYNWHNie9JdT14rZ 6hjaqLlLcL2wOC8iA6TfS7+TSGMB+lJLyGDD9cdE8FuD7n6i1VV18Pcm0Wwi2gh4XRG6 wgmyWk31mD0i3FLzrk5N2ZzDhQdVcXr/8nBwfrueVd7Ca0olB1EE8UwNxlYFvuBOvnG5 PURepf3zxMH+2CJi2M+dE4TnaLSrPabVWORpnQXcheiDAaUg5yatltG6BJUPykUCZd87 jslVzJg55loxu8PIZalCg4aWuLn4YhzvXiw2d2RgzuUP7MjZN9UfuC25jU8TUTRoyH8d RcIg== 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=9FdCg15O3vz4/C6WvKx2PjQp1kVrZWkrDECEx0DJVdE=; fh=IlzoM7xapMIT9vjIu8V1YxnmOSGAT8hvLuDm+hjUGIo=; b=hKsT3ZzJ0EsB6SeWvIvvA8/vIoACm7FkQA2hcoAVbIMduj8N0QVaFum3UCXdHRHDOo EOYbNRDxfKL4Mn1ve9U96H5wPZW4EXFfA8O5VR0RsKSIQa7wLMJLTqARhQs9L1moVQJk k9Zc69nVuM/dvw9OtPwi7YmwULWkoj9BDKM5E1AhCheerIfDLU3AKCGgSg00WyDD/7lW br4vZyMI7hIpgzs2GmhK0oW8te7Hyjz9+q3cLsapey/bonAeVDM17BuI0Tnu7SZOyhvJ KoLMJKLFfgIqyrnFB2rnlmFtBYRAUO2p+vbZGDCVtXsoOJQvJCwD3BNTHmEr8Y8uBIoG UAqg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=WjdS3GBp; 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:c20f::7 as permitted sender) smtp.mailfrom=alexander.ivanov@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazlp170130007.outbound.protection.outlook.com. [2a01:111:f403:c20f::7]) by mx.google.com with ESMTPS id 00721157ae682-8b36c3adaa8si24112537b3.198.2026.11.09.05.26.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2026 05:26:04 -0800 (PST) Received-SPF: pass (google.com: domain of alexander.ivanov@virtuozzo.com designates 2a01:111:f403:c20f::7 as permitted sender) client-ip=2a01:111:f403:c20f::7; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=WjdS3GBp; 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:c20f::7 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=oytRMC7g7XD0lSXH78zJZKICeiAvD4v8C058IcCQH61D+pc58vbMki/epCawFUWBXRIfuwD3czwjofC/SzH7adrJCEFdX7ix0qywO/CCCD42sVPmIvYqRC+9Z67ts3ajLD3Y5Y7EieCkS4zFsgWxbE4Lr2k0+SXUZnHM05H0NOHok33XEVbxHOgsY127081m4DT20tlt73cpQQXXwelauYhI6oP4V83hmIvtjykAyymE3RjqVAuPtJhVRvGEAW7Idaq6yV9gdZfl/pwhD+dZQEVPhe7poNb24DsRFAiYE1D4jCZpdC5XPqJDmtqUOk6slqei4FC7yAHs2HusysXbHQ== 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=9FdCg15O3vz4/C6WvKx2PjQp1kVrZWkrDECEx0DJVdE=; b=k4dHJR46fehFQmpBb9enVzODyGWmiYI04Z7/7meZ613uke5K4qu68HWPWUrj/k6GBND/nUgLSPAz4AZbMRvnt651L4ZKnZ/42gU3xdaN3Jn/NQRueAsIkzdqtBdfbUDrkellQqUz/NZiLkKrjuZkfCCiLYHF1YM5z/cS6V7hSDdJcjw5OmrjMeMELT0q+7ZwUnxUZoSbGwb1v0KLf1fhSDsZQgazhnhybIbrl7PBoQ0VcF/meoBcplx0aLuYxnsSVcHPGW+tS/l4ngjBRE9Qq2fqW+N1haKhuNvB9c7k48vVTUMpoIGAtAQVtY0ZPLq4EuFr7o2IAVaMItUmAqtRdw== 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=9FdCg15O3vz4/C6WvKx2PjQp1kVrZWkrDECEx0DJVdE=; b=WjdS3GBpm2Z4WmdKIhM/Gcv2JwwCCh/8mAAkl7Ibe8054nFL30+ycnQ9Tv2ojn6q6WUTMIkjqBqseaQXRNhokkTE4RT//wSD7SnMWspj5SBJjjRsGDSmfjr0W8Fx+6P81Yy2xasah7pfyy1CiTP4OYomI8Mtz7UIfYlhuzUhwjdk4hLsrNnonahC3lwdrlH+aDLFYycL8oqTK4v7r2PhkC0rkb6HBf7Cur3v8Fc4YzxpU5suMDSfCJ6e+ycPoXhNf1AsWRIIViL0A4cCOO+plxgXGzqrbsil2v0s3cDtDZLnKJK284atyJAVobERIIs8QN6iYhwHKwmCyw9nLaqHmg== 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 MI7PR08MB187704.eurprd08.prod.outlook.com (2603:10a6:290:105::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.592.12; Mon, 9 Nov 2026 13:26:01 +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.0592.009; Mon, 9 Nov 2026 13:26:01 +0000 Message-ID: <1d6669e2-68b8-48c1-b923-562b96429809@virtuozzo.com> Date: Mon, 9 Nov 2026 14:26:00 +0100 User-Agent: Mozilla Thunderbird To: no-reply@sashiko.virtuozzo.com, andrey.zhadchenko@virtuozzo.com References: <20261109115856.1362416-1-alexander.ivanov@virtuozzo.com> <20261109115856.1362416-11-alexander.ivanov@virtuozzo.com> <010701a1c03b72b0-e89975ee-0b2f-4c97-957c-240c49056971-000000@eu-central-1.amazonses.com> Content-Language: en-US From: Alexander Ivanov In-Reply-To: <010701a1c03b72b0-e89975ee-0b2f-4c97-957c-240c49056971-000000@eu-central-1.amazonses.com> X-ClientProxiedBy: FR4P281CA0212.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::11) To VI0PR08MB10743.eurprd08.prod.outlook.com (2603:10a6:800:205::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI0PR08MB10743:EE_|MI7PR08MB187704:EE_ X-MS-Office365-Filtering-Correlation-Id: 59d83ab8-97e6-4413-e816-08df3e64ff4a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|23010399003|376014|1800799024|22082099003|18002099003|6133799003|10067099003|4143699003|261028144727099003|261102123227099003|261022075727099003|261022105027099003|261022115727099003|56012099006|261021121427099003|261026140227099003|261026121527099003|261009223027099003; X-Microsoft-Antispam-Message-Info: uzx+qjCHZh1TYMA0ecke34c6NhoIA81UjzaHMVEy+WTYaIfjiKmterLtpctoklQkyiGPC7CNB5DKbEqF5seiujitOy7b1KsL3GmLgUPRRO8ciPUtBSEOeHFtA/B174Bu17+xvYu96A0CQ91tgeJJxX67rLu3DjtirzbXLTb0YF3VCp01qlUlCustAEbVwkpooSCCTbYx1r9/7tVFet0U4CPbG82ArxnsaXPMXLpkWNjHAPFniImTt8zX94KJP5J24urxWIHcs/HED9NNDq04AHLvjs70dVdaOwU0VvftgTxy+wV8rvPrn3ykxvIKKx57jkTB2Njn99GuN+I+4+d5j6hatGI9Njp2OZ/xlwF/WRjYnaZMGhDCBlscyZyaTiShXwjb50uL+7EcQ2Cn5PRlUquljYnhWak+OO13brWZmpnKmc9Im8Mdvux17ux6kogZ4akJkcuvCRJ3JZ1ztOYCizk3vJV7EwMaCUS1u4GNg1kWGeRexDRNdaEKZYxpkG1GJLKfJiPEeHrwQCxSrVCu8KlUIZAeX6qgNGu96TQVxuPFKlRu/s2D8L8xDXS4LTTQ2bwNBtoPHvnCXrjTKCqz8QgqpstNIofA9ge6sXHwVI+OJJxDrBYzBg97UGKqbBzuW7P0MsrjZyaK51eUMT8hYUHZZbIxm4SKgTb3lRWHGMs= 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)(366016)(23010399003)(376014)(1800799024)(22082099003)(18002099003)(6133799003)(10067099003)(4143699003)(261028144727099003)(261102123227099003)(261022075727099003)(261022105027099003)(261022115727099003)(56012099006)(261021121427099003)(261026140227099003)(261026121527099003)(261009223027099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b3NnNU0xR1Bldk4raFZOYVlKOWh2NFVWYjlvTWRoZXVzc2VReHdIOUhDMGRi?= =?utf-8?B?OFFTRjNkQTJjTkd2QmNFK3JEVUtIOURDTkFZZ1JwOTFxZjFXUmlQeVNlSk1P?= =?utf-8?B?L0RMYmhuVTJXME5MV3FxSGtHNmdrN1hObkplekpvSExQQ0Q2OGNBMFZYclow?= =?utf-8?B?dnhmOW1WVDM5dG1Fd1NFSnJaSXZBWVZTTytEZ241WThHblRGK2ExaWUvQnlr?= =?utf-8?B?TXI4NnA5WGYzMzdvWVNUYnlpZTVod2RhVis3UjVTeUwyU2NYdE45c04rL3Iz?= =?utf-8?B?a3N3U1B6eXpoMjhGcDl4c3FYV0FaZHVGMnNQczJuKzFPYlZaelZBcUlGYzln?= =?utf-8?B?eHBISy9yMGRKVjVTR2VzYm9nRldmYmlrY1lYRG9kUGhCZVZUZk1QbkppK0xH?= =?utf-8?B?VXorR09Yd3Z2ZmpwM0RDbEp1VlN5WWYxUWMvajRNZU15VnRVWlVOYyt0K0Jk?= =?utf-8?B?RGlUK0VBeHI3SmhlRHFNUnNjN3JHZGZ3LzMzU3d3dnFuY05QR0hhOUFGTFMy?= =?utf-8?B?RlFiMmdqWGpVcnJZd3NmeDErcGZGS1lmVUo4VmRkMGs1dmtJZDJtaFZQaWFL?= =?utf-8?B?TkM4dkN0OVc2ZGQyZzlvN0VON3NmbGRicU1RZG5rblNuVnlLTmdyYXlpblN5?= =?utf-8?B?a1MrbERGWGRpcXFZVkdpZmcrajlkby8zSEdja2ZrVjJJd0pteGQvL2QvbTdw?= =?utf-8?B?NDNNS0hiaGsxbmRCejlOZXNPaTdUei9kWWRVd1ZFTXprMlRvK2FxbisrMG05?= =?utf-8?B?RVE4a3IvWG40MXpaRG1JUU1jbnB4YnhROTZLSVFxNTV3bnJJa0U0V3Jja3Nk?= =?utf-8?B?bVp1a0Vta3NWWmpsUDFyWnRJeW15NDlGVEZkUmV5dWw0bDljN2czMWZUT3Z4?= =?utf-8?B?M1hFVjdpVWt1TExMRmpzeGJWNjJYSm9KMzJmZlBhMHdXSnVSYWx0MGQ2Zy9h?= =?utf-8?B?VUR5NW9TN2VrcXN0MWsxRzlxcEw0cTRFdVUyVGx5bnQ3a3F3aW5kWFRmUGJK?= =?utf-8?B?ems3T0dKZkhMaXhJblVnR0dEVkI3M1c2U0VFQTdIbm52MFlNdm90MnZSYTZq?= =?utf-8?B?ZWJFczN2ZGh4NlgzU2tXNFg5QkdUd2xFcmwycWI2YWxWbWNwWHpJMUdnVkQ4?= =?utf-8?B?R2I1NSs3M2NEWmM4aWt4bVFPNlE1RE92THdmUmIxSnI0RHV3OTlHcHdGZ05F?= =?utf-8?B?bVY5Y1d4dzhONFhud0pRbHZWU2dDaFFpOHdHOFQ0S3FZZDZFNHVwbGx3bzZ1?= =?utf-8?B?eHdkU1kxTnlrVTlSa2lLMWpvVkFkRHhiU1RLTzBRUERwdUhibVdxUDNKN0V5?= =?utf-8?B?bU5FM1MrclhWRlZXMTl1Q3lxS3FrcXhFbTMyeWFCNEMyRjhoQmU1SUJMSmV2?= =?utf-8?B?TngyT0doYkdMa0J6eW12dit2RWxJajVPeVNpdVhsZ1dZV09veGhsaEo1bmU3?= =?utf-8?B?UEpreENXdmJ5TDFQcUhkLzk1NWFpMFd2ZnZ0WkNqSWZSWlltMVEyaThIdjly?= =?utf-8?B?a0psZmM4d09iMmRJRXF5aFhHWjVGVG5vd3pyVVpHb2lJT1oyK1RMNGR0Wm5J?= =?utf-8?B?ekxiT0M4eWh4ZFBJVEUrQjdvRVJHWHFUZURYajhVNTBWWkVVYndBOElvMDhZ?= =?utf-8?B?bFp3MkNHaHBpSllBRTJadjFpS2lyZDJBdUxVcTlVQWY3Ym1ENENrRWIwdjQy?= =?utf-8?B?U08vU29HTlFoVThud2xLTjdZVVBWd0FQeG5kTnJrNGViNmpvZmZlV0ZVNFFy?= =?utf-8?B?QkxDNktkZVM0QVg2SXdjT2x4dHJOS1VZRHVKS3VQUHc1RnNMOFREemZJbnp4?= =?utf-8?B?RUU5cklKYTlWOW1ZOXBqNnhuTCtiOWZxd01uNmppRk1rNnJ2VkRtTDNsMW9Y?= =?utf-8?B?eEdnc1NzdmR0dGgxcmpGNGhITFJVZ1dOdVZ3dmNLSmRCR1pIUkU4ZnFkK1dL?= =?utf-8?B?OFA4anVsczVGQXc5YWRaeEFRR09Dam9vMEZNdVZQbmgyN0x3c0xENm5acGkz?= =?utf-8?B?QWQrS3ZOZFR2UGxTWUxhdk4wRzdRL2ErUW16Q29zWFB4OU02a0o1czFWdElU?= =?utf-8?B?T1F4TlBoNWFJRTNDTTdjeE5HcmZpMm5QSTFQN2Y1UWMzNTdBM09jWjVVeVBN?= =?utf-8?B?ZGtIelBKQ2F6MnhKdmRUd2pDWFhlbTU5emNTY2ZHWjNJOVo5QlVGNVB1NHV4?= =?utf-8?B?VFlUTS9wbTNhaWFlcGdTUWlkKzc3RUZMS0lLTS8zNkRPTXV4djExRWJQc1VE?= =?utf-8?B?SXFhRzI0cG1uaVVDVlB1aExuUWhZbmdFVnNtUGhORGJXM014T3ZMNkFKdnJ6?= =?utf-8?B?WUpZQlpTTlFxTnFzNnhTMGdTOGpwRHhHdVI5KzdrL0RyZDJsWTczMlRENHJi?= =?utf-8?Q?Zy/LOfqJCLilozAw=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59d83ab8-97e6-4413-e816-08df3e64ff4a X-MS-Exchange-CrossTenant-AuthSource: VI0PR08MB10743.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2026 13:26:01.1985 (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: 7S/XkvGJzrWaIV0CLELXM8NFbmQfzyZRiHDomHlSI0JGsl731aiXbgiYQ9gO6RYjPgoBOnjoz2VyMqW/ReYQxNoonld5L1N+dlCKde0g2Xk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MI7PR08MB187704 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 v10 10/10] dm-qcow2: truncate unused tail of image on suspend 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 >> +/* >> + * Return the end of the last cluster with non-zero refcount. Must be >> + * called on a suspended device after md writeback. >> + */ >> +loff_t qcow2_calc_used_end(struct qcow2 *qcow2) >> +{ > [ ... ] > >> + if (!r1_entry_is_valid(qcow2, get_u64_from_be_page(r1_md->page, >> + r1.index_in_page))) >> + return -EIO; > [Severity: Medium] > r1_entry_is_valid() only checks the reserved bits and the cluster alignment > of the R1 entry. Is the refblock offset checked anywhere against the file > size or against overlap with other metadata? > > The open path does not check it either. qcow2_parse_header() and > qcow2_check_convert_hdr() do not validate R1 entries or refblock offsets. > The only reftable check there is: > > if (qcow2->reftable_max_file_size < qcow2->file_size) > goto out; > > If an R1 entry is zero or points at the wrong block, can the scan skip or > miss clusters that L2 still maps? The file would then be truncated below > live guest data. > > A refblock beyond EOF fails the read, and the scan returns -EIO and falls > back to the old behaviour. The scan trusts refcounts, as the rest of the driver does: normal I/O does not check R1 entries against other metadata either. Checking R1 offsets would not help much. A zeroed R1 entry looks the same as a range with no refblock, and a valid R1 entry can still point at a refblock full of zeros. Only a walk over all L2 tables would catch these. Refcounts that disagree with L2 are left to the image check before an RW open, the same check that covers refcounts left stale by a crash. I added this to the commit message. > >> + >> + ret = calc_r2_page_id(qcow2, &r1, &r2); > [ ... ] > >> + for (i = r2.index_in_page; i >= 0; i--, pos -= clu_size) { >> + if (get_r2_entry(qcow2, r2.md, i)) >> + return min_t(loff_t, pos + clu_size, >> + qcow2->file_preallocated_area_start); >> + } > [Severity: Medium] > The used end comes only from the on-disk refcounts. There is no cross-check > against L1/L2 offsets. If a cluster is mapped by L2 but has refcount 0, for > example after a crash, doesn't this loop cut it off? The driver already trusts on-disk refcounts: find_unused_cluster() hands out any refcount-0 cluster, so an image whose refcounts are below real usage is corrupted by the first allocating write regardless of this patch. The only new exposure is a session with no guest writes; that case is covered by the opened_dirty guard with kernel_sets_dirty_bit, and by the userspace check before RW open otherwise, as the commit message describes. Cross-checking against L2 would mean walking every L2 table on each suspend and still would not replace an image check. > >> + } >> + >> + return -EIO; >> +} > [ ... ] > >> diff --git a/drivers/md/dm-qcow2-target.c b/drivers/md/dm-qcow2-target.c >> index 1b7a75239291..7587e8f7ac0b 100644 >> --- a/drivers/md/dm-qcow2-target.c >> +++ b/drivers/md/dm-qcow2-target.c > [ ... ] > >> + if (tgt->md_writeback_error) { >> + QC_INFO(ti, "Skip shrinking to used end after md writeback error"); >> + } else if (kernel_sets_dirty_bit && qcow2->opened_dirty) { >> + QC_INFO(ti, "Skip shrinking to used end of dirty image"); >> + } else { >> + used_end = qcow2_calc_used_end(qcow2); >> + if (used_end < 0) >> + QC_ERR(ti, "Can't find used end: %pe", ERR_PTR(used_end)); >> + else >> + end = used_end; >> + } >> + >> if (end == qcow2->file_size) >> return; >> >> ret = qcow2_truncate_safe(qcow2->file, end); > [Severity: Medium] > The only in-kernel guard before this truncate is the opened_dirty check. It > applies only when kernel_sets_dirty_bit is set, which defaults to false. A > v2 image has no dirty bit, because qcow2_set_image_file_features() returns > early for version 2, so the guard can never apply to it. > > The commit message says "the scan is safe only because userspace checks the > image before an RW open". Is that precondition enforced anywhere in the > kernel? > > The dirty-bit consistency check in qcow2_check_convert_hdr() is commented > out: > > // if (!is_ro && kernel_sets_dirty_bit != > // !(hdr->incompatible_features & INCOMPATIBLE_FEATURES_DIRTY_BIT)) > // return kernel_sets_dirty_bit ? -EUCLEAN : -ENOLCK; > > qcow2_wants_check() reflects only md_writeback_error and truncate_error from > the current session. > > Suppose a crash leaves a refcount at 0 for a cluster that L2 already > references, and the image is opened RW without a userspace check. Will > qcow2_truncate_safe() then permanently cut off mapped clusters? > > The new end is stored into file_preallocated_area_start and file_size, so > the loss cannot be recovered. The old code only dropped the preallocated > area, so it could not remove mapped data. > > Could the kernel refuse the scan for images whose consistency it cannot > verify, or could the commit message explain how the userspace check is > enforced? > The precondition is not enforced in the kernel, and the kernel cannot verify it cheaply: in the default mode userspace sets the dirty bit on every RW open, so v2 and v3 are equally indistinguishable, and the only reliable check is a walk over all L2 tables on every suspend. It is not a new precondition either. find_unused_cluster() reuses any cluster with zero refcount and prepare_unused_cluster() punches a hole in it, so the scenario you describe already destroys mapped data on the next allocation. The scan widens the damage of a violated invariant, it doesn't introduce one. >> @@ -1157,7 +1170,7 @@ static void qcow2_postsuspend(struct dm_target *ti) >> int ret; >> >> qcow2_flush_deferred_activity_all(to_qcow2_target(ti)); >> - qcow2_truncate_preallocations(ti); >> + qcow2_truncate_unused_tail(ti); > [Severity: Medium] > qcow2_truncate_unused_tail() now reaches qcow2_calc_used_end(), which loops > over qcow2_md_page_read_sync(). That calls qcow2_alloc_and_insert_md_page(), > which uses kmalloc(GFP_KERNEL) and alloc_page(GFP_KERNEL). The backing-file > read can also allocate memory. > > The call chain is: > > dm_suspend()->dm_table_postsuspend_targets()->qcow2_postsuspend() > ->qcow2_truncate_unused_tail()->qcow2_calc_used_end() > ->qcow2_md_page_read_sync()->qcow2_alloc_and_insert_md_page() > > dm_suspend() does not wrap the postsuspend hooks in memalloc_noio_save(). > Can direct reclaim triggered by these allocations wait on I/O to this same > suspended dm device, for example if swap is on it? That I/O could not > complete until resume, and resume is waiting for postsuspend. > > The old postsuspend path allocated no md pages, so this exposure is new. I > did not find an in-tree user that swaps onto a qcow2 device, so this may be > theoretical. > > Would wrapping qcow2_calc_used_end() or qcow2_postsuspend() in > memalloc_noio_save()/memalloc_noio_restore(), or using GFP_NOIO in > qcow2_alloc_and_insert_md_page(), be appropriate? Not new: qcow2_preresume() already allocates md pages with GFP_KERNEL via qcow2_parse_metadata() on the same suspended device, and postsuspend already did fs I/O (truncate, header write). _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel