From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EB6AC54E71 for ; Fri, 22 Mar 2024 10:12:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E717F6B0087; Fri, 22 Mar 2024 06:12:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E477D6B0088; Fri, 22 Mar 2024 06:12:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C99CA6B0089; Fri, 22 Mar 2024 06:12:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B85466B0087 for ; Fri, 22 Mar 2024 06:12:46 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8669BA158C for ; Fri, 22 Mar 2024 10:12:46 +0000 (UTC) X-FDA: 81924261132.04.9FA9362 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2107.outbound.protection.outlook.com [40.107.8.107]) by imf25.hostedemail.com (Postfix) with ESMTP id 02EB5A0026 for ; Fri, 22 Mar 2024 10:12:42 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=tuxera.com header.s=selector2 header.b=PZN8z7l7; spf=pass (imf25.hostedemail.com: domain of anton@tuxera.com designates 40.107.8.107 as permitted sender) smtp.mailfrom=anton@tuxera.com; dmarc=pass (policy=quarantine) header.from=tuxera.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711102363; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HCN+OQrYF6SJfRyZoQ/bPZgj4nz960k4ta2LA01ldAU=; b=tUk4LcgUPrt3Warv6AhcYSiAZRSEN+W8h0juVZkSiedj3qFt3cobsKipVU7By5yDLKQq6h 9uUhDDoCXfXBjj/7NkiHe7T4Z3ZLgYRhICbxsPGccTi3n54znMHCDZx/E/JwLY7B4OdHGD dlcF5r4Zf2aW+3VDB/LfI+qRqc3lTA8= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1711102363; a=rsa-sha256; cv=pass; b=XWBSj9wqnIJ4MRJsZ6w41/NDnJLd4ueDsKeQUM1MKzo1V0MdswI/QcYE6KN5ZmwH3HmShy iHPCGXzH78I6TzhodFIxvYWRe9jkBKWRlB6JTOTDPloc6sE03Z+4Kbe0E9WW6Taa4P9eoJ eY266L/a7paL/1dmN1YOGENuqMxcHso= ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=tuxera.com header.s=selector2 header.b=PZN8z7l7; spf=pass (imf25.hostedemail.com: domain of anton@tuxera.com designates 40.107.8.107 as permitted sender) smtp.mailfrom=anton@tuxera.com; dmarc=pass (policy=quarantine) header.from=tuxera.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iO4xyOBo7XVKP5qrGPt3/E/xr9tP/8TwH9hcBG0L6VTERkMrKssMs9mTwd4vyetWb6fofFtFGBg3PifzgEVRQVrQjb5yW4MY5LZotZTmWuidQ+V3B9GNPZWBrFM412ft21HMSbJmh9iIyDm/FCdjpKjsq60f/+Uq/rNf897nIRwC9d9PccB7rt2vjSmNzU5szP82vXpGWJHKgF2CTyLlC0mbEqWUWc6QwkJB/5lVglHh2oh/7m1Xl3IaHxLjM35C+igYUgYiF5C6WZ4ZZSfpTTsj3vbgcVOzpHBnP1znL2uN4TJTXRGCkAZa8LCP7IRznpx2s8Y/D9yPZst/fBiKtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=HCN+OQrYF6SJfRyZoQ/bPZgj4nz960k4ta2LA01ldAU=; b=eWK+2VS2wC9EHX4Q91ZBacf3oVJAc9aaDApVtf/hwGWIlh8c+nxLKwNlgf5J2Ez9gYcrOBAhKjLDPPM6q5LZwtYzssAlMtddBEXfxuRXeGbDlYiNVU1aUA1X2h+9I3WkxHY6ycH2IgL3gIOh0UEyHQyv+xp+PB1bKMmXg5RYkPaXiDDwYw73eR2tI8SGNSDzpelPKms4cGBPamoWMdWwFszjc13CGQ9HDgeokp0zwkR5olvlIX+0v8gfrKWjLFK1k0EyD27drUTzz1zg9TFYZ7IH3BUrZwdV99genNorTHpKs5bqEp4e0boLeAzgFfCUmlr95yVa30qV1j1xuEgnog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=tuxera.com; dmarc=pass action=none header.from=tuxera.com; dkim=pass header.d=tuxera.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxera.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HCN+OQrYF6SJfRyZoQ/bPZgj4nz960k4ta2LA01ldAU=; b=PZN8z7l7K7JhWcqkfKWgvhOjMkuHOcSA8rtWZnN5+W+BaeBnSWOdBeWcd06O5ojHjUkU5WGwOCFVzrcU7uy1QX8KrJ7VoPl1LjfmGem0iqdbGg51vMo0Ola+trT1TJ0j8fzIEyAL4zY9wgyk20cyaPYBh9h0caJScAi9DsDmnb80H+dY50WiN+oT9xjEgKAvsIANtqih2kGcgXN0Dq+IJu5sYW5t4bCwIzcC4XDFQJIDoKUyHRa8LRV4vunzg8FApZn3uvvbGQc+YkK44tJAz/d/7A50Z4WipzSaZSOTiQzAknwKcVeQqgqpkdArTgihNhlgxYlyzyLoGAZw8U1BpQ== Received: from AS8PR06MB7239.eurprd06.prod.outlook.com (2603:10a6:20b:254::18) by GVXPR06MB8946.eurprd06.prod.outlook.com (2603:10a6:150:11e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.24; Fri, 22 Mar 2024 10:12:37 +0000 Received: from AS8PR06MB7239.eurprd06.prod.outlook.com ([fe80::2664:11aa:434c:516c]) by AS8PR06MB7239.eurprd06.prod.outlook.com ([fe80::2664:11aa:434c:516c%5]) with mapi id 15.20.7409.023; Fri, 22 Mar 2024 10:12:36 +0000 From: Anton Altaparmakov To: Ingo Molnar CC: Dave Hansen , "Rafael J . Wysocki" , Pavel Machek , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "x86@kernel.org" , "H . Peter Anvin" , Chen Yu , Pawan Gupta , Catalin Marinas , Linux Memory Management , "Rafael J . Wysocki" , "linux-pm@vger.kernel.org" , Linux Kernel , "stable@vger.kernel.org" Subject: Re: [PATCH] x86/pm: Fix false positive kmemleak report in msr_build_context(). Thread-Topic: [PATCH] x86/pm: Fix false positive kmemleak report in msr_build_context(). Thread-Index: AQHadiEQrskV1NWHjkSsYR0U0Bb8SLE3YQqAgAwy8QCAAAKjAA== Date: Fri, 22 Mar 2024 10:12:36 +0000 Message-ID: <1386E50F-7383-4666-A7DC-7AFE8D755C19@tuxera.com> References: <20240314142656.17699-1-anton@tuxera.com> <70261e2a-b87e-462e-964e-95a51ecde978@intel.com> <653BCAC0-8A79-400F-B496-23A2FA169786@tuxera.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS8PR06MB7239:EE_|GVXPR06MB8946:EE_ x-ms-office365-filtering-correlation-id: ec957ea5-f997-482e-1b99-08dc4a589946 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UqYlGfnIM2Uyo8+WnHxga2XHxknOt/Dv1aMCE4wq0qMwjm5bJKfis6vXzwYxryXqHWfeUU8dUrhP+7MbMRH3eTRD311dW8OjjuU8JeiPj8K52Y5xT037I599Kdxyx4GwDsxmCwx6Vf1v2X0gpwMxhvk+bkuVBdRZQ9efeP4KYHv1g1v5OlFvZDoBVcWRTTIAKv5sUdfNJG1SvsmztUETUJifVx9g8Eqo2FbibYwgAQ0IVky71y4MA4rO+ySAZSAe5v9QSuQt2hdiYXsiWrGZKIbpXr1penBpnFxpOfj0yuAS7lkGSWMIoE7Tkx0eTiX+sX57tNR9q7Y8X0MUOtX8vbZ0yNJ6N53Zzqi6j9gptepUkziKkOV3dj2rnZQg2/4wLXOeIbDRlB6rdSi8nAAuwJU/hJ/d+oVb6wTNyFhlImUCH7r/3/ocnXSiAQXH3Kob2OFaFbobP8wcJvPFK6v8x4Ipn5MAmJ12dU6Ns5v0G9K/0PAVXNR6id0RC4C0dUpzmm8uJTA2SSXgG71qrHyTg2VJZZRTHvOnE4+1yzFRC+m3FnIktuHX5Evhz1bU0SueDWcJWfytNRGacgJalYXvCTwwNrL+0w3Zp83DThDVzZ6wvTLyoSeKxKivnx8oJjmwgQKyJPs2xjd0+D7yjJOHpdu6YAzqGCmzg/6ZmNHaX+k= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR06MB7239.eurprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(7416005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?YznN7RgrSvw8QR/vci7qNzvHU5FPbN46TKJc8zjDhHXvbjZPeX0LDWyp8XmX?= =?us-ascii?Q?dQIrgwNsDU4Q8sT6XLI/MS6GSUmee6N20vLYFnBj83uq4te3MeKJXzi3jIyY?= =?us-ascii?Q?gVKUuGcd1ucTerTVKyl+n+DU5klutn8Glye6iYqcCuG9FVjCuIR/21or9T7g?= =?us-ascii?Q?naPpYiHDytnS+QK5kN5dob6t4+I/FK9oPcTzMTur+lt5AJcUgbIZdZpRLC9O?= =?us-ascii?Q?1oJsTTJGfwkbP9kLZh1LsGkGTHDPEnAdXVo5uzDpMdUhgHmCTjp60zGTWYit?= =?us-ascii?Q?iZtO1DCUqYrOPnjtmALh0o7Evsz2VpiHAuP8xXdtPJ4+wX9saruDVcKGzBiT?= =?us-ascii?Q?Rss1fATePjYaSBDuw/XWinHg+s0I8SeyTNH38hXPFKqP0GW7Gz8LepmD7dre?= =?us-ascii?Q?X3sAfD1Ss6Ayc/kY2evzjx0rRvTb/JB48ffsvI7TiN7DvYIZmX+3nGuprISi?= =?us-ascii?Q?w63Sy8Mbxzj7baG6LWDyhJBA44NYjgll3G9bxcKYWCIHtskNXw8OjZjN7ZRb?= =?us-ascii?Q?pVz1+Vnwo8JXWTIAAXRBjaN/qY7JYoEYdKkzRDBwEbTivh1IVb5BYo8kRhyc?= =?us-ascii?Q?75h8M++FjTXbe4qWLL9PINL9m8R9zWzXP1xxRo/StmSpzxx28AntMo7BjlYN?= =?us-ascii?Q?ghEJRn/NoLqlobKC9JcnWzM8963QVf7rdORWCfeu2bxU8rWAZak2lzeBeM0m?= =?us-ascii?Q?sIK387YQAicZFdNLe03uhVfbYZerfj0VLtKdTJiRXu6uONseMxeypMIhKOia?= =?us-ascii?Q?qgHjJ+4QUwbM90CojzAG0cWlvjSASKOALLaRhDv/NQE0kjgH4PCEV9l98y4k?= =?us-ascii?Q?4rYzSxbm5lNPvEhEbm1NNPr9IVzuZ011FygaR4dsV3jY9cF8ZZmn/WTw1s19?= =?us-ascii?Q?glqbWbNUvlEIuKuMlkosp6DG719nyp5mHlcStPhdZnEjJO/5DTcNJGgnJjxf?= =?us-ascii?Q?RQgDULTCrKd4OVGalb/codWgLXvsYERKB6eaU6zLY+ooQrlzR0It/1eodvm8?= =?us-ascii?Q?HtfzxK7qPh4dQ9JxElBwPha+FfX3aZ57uNjirBdjJWCxzuUsEicvlrOnXetB?= =?us-ascii?Q?oRX0z090ogftzTW2UmOIpfQ1XRt/qEaTHFlIMuapQx0+/UTXQ0728G3Pk20q?= =?us-ascii?Q?kMCJS4JccJxVY7nvdfr3h1gKpewcEoNpj6zgvpx7sAIc9ACbe918y5G85PP+?= =?us-ascii?Q?P1L5wQ4/uFYC2dW/g7RGbyNu/yl0MN+hoD5jHn/OQRVUj/QdQ4t4R8bBI1Sh?= =?us-ascii?Q?6dmvfwUOhJ9M12v85TSZeR5t4zr7aBk/qSgnKhji/+/C1fbhKT3bDO4/NouG?= =?us-ascii?Q?YD39nJDlSkES+uv4ENvrttGgAuIMs5KpQhdDmHGOQRZkcfwKMboi/YCJpf32?= =?us-ascii?Q?deabw6kD7ofIgjWuoHTL1aeTGtHQcb7r9NLdJ7QHrOoV/x4bVHOtMeWaYseD?= =?us-ascii?Q?4sNTqB0xFNzfG3DosbAuqOSL0CLsU+6n55rAsIVAS1CEbmwdwI0XFKlQgAY9?= =?us-ascii?Q?7HksQeL60FhaF2WNHwPzg0R4WmdvICmBRD2Ljut7UH4vKSyB4fOgrUOrPkrd?= =?us-ascii?Q?ymCWJEDTL3+Mhq9b6n/RNs5IxWhY5b34YXJwiIKw?= Content-Type: multipart/alternative; boundary="_000_1386E50F73834666A7DC7AFE8D755C19tuxeracom_" MIME-Version: 1.0 X-OriginatorOrg: tuxera.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR06MB7239.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec957ea5-f997-482e-1b99-08dc4a589946 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2024 10:12:36.8444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e7fd1de3-6111-47e9-bf5d-4c1ca2ed0b84 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vLRqg00ZNdLw43Aiu4a1R2B5r+OPajBRhrVy0tYCyz3aj0JCBFl9Tlika0l/UMVCGbUioeNPLzCTPbx5POVlqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR06MB8946 X-Rspamd-Queue-Id: 02EB5A0026 X-Rspam-User: X-Stat-Signature: zxzpenuadj8o6wtgybbppmno3x3q5s5u X-Rspamd-Server: rspam03 X-HE-Tag: 1711102362-823225 X-HE-Meta: U2FsdGVkX1/yjv6ak0WreITmH3PTostSlMQSx+kXqLQn89DMF4lBP2HhhPIXuGHU4UO0LWMxNx+cqzh4ootsIipHReK+q9TANiU/clJtW3BS1JnmCA91wGfSC734xuImKVbtl9eTeHjPj0c/GTUM+RmLlBdsiumoD39eUoQs2qjJgEH3Ngtc09IlbTwGz+Nvd1rv8PxADT+37OF4rOCnDMR6b6Y8FgSidX6RDctWo+ORMjk3HDPRJ7cw36xtb3MMyvhFbIZg+EpFgg1MzJnz1FW6ol0A30wYOJFm+b1yOQ4lPb6czBJaE1Y7towvv3fzZDPcMgvNiIigNBID7QTujrSD82n/FSteFrXEUIkK1lwLS0fvQczoL17abLP53q80ouiKA1FKiBYTiyZbm55zPFHcLI3Xsv5TncUMHoV90lIf1Ll8sQ1wUTnfYpOgqZgMcH5S4Ao534e0dra25BgZ3wSXL/vT0iIF5lEBUXfo02cbSEGp9Ofnbae3IVXi4N5KABGdusOwXL4FV4fc5eHxd72d7Mb6kHdyXaxZDN6m/cVEgBytCjXUvf6NBEzMj15b7xkV33xiH+3sEDhXRChcpqyZR3bTs5UJ35aUD5VDjyHKqGTa5GsXk7d4IvBbSKOb1BYG4FJE0VAwRZJ2jLgJLS2EXL6VO0xEf8+XUuvhwcdpnDnT0SpZM1uoJt7sU3f2tDOGLVoWFbw8OiqTL8N6apRMygvUSWUnj8BZe64+b29rTrfotqc4EIiq8Hk9Igc7k8LozVHU7x9vt9UHcv5+4pd0eOxdSEYJ5G986sQ2aKonuD/f+OKF5Ac9u83uXwrZBjjvdE/+rF/1b1BEv8SBZ2EoDP7Cty/INWJsQ7Rq58BsGU+lyQUlnPRCSJjJo17b2XQVlFUPe7sfN4w0ZsC6AnkZIYvKxClJGFRZiqsodN4tRlyZOy5sE3gYp0fyrcAZRes+PBCbeEi6BOMh85N i62ShSps 9USXj0xKd7b45hGcbd/73Qzr+J+6RF9iUnrMXsR+vlGErtZmBfquaCbYppyJXc9+VIQVM X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --_000_1386E50F73834666A7DC7AFE8D755C19tuxeracom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ingo, On 22 Mar 2024, at 10:03, Ingo Molnar wrote: * Anton Altaparmakov > wrote: Hi Dave, On 14 Mar 2024, at 15:05, Dave Hansen wrote: On 3/14/24 07:26, Anton Altaparmakov wrote: /* image of the saved processor state */ struct saved_context { - /* - * On x86_32, all segment registers except gs are saved at kernel - * entry in pt_regs. - */ - u16 gs; unsigned long cr0, cr2, cr3, cr4; u64 misc_enable; struct saved_msrs saved_msrs; @@ -27,6 +22,11 @@ struct saved_context { unsigned long tr; unsigned long safety; unsigned long return_address; + /* + * On x86_32, all segment registers except gs are saved at kernel + * entry in pt_regs. + */ + u16 gs; bool misc_enable_saved; } __attribute__((packed)); Isn't this just kinda poking at the symptoms? This seems to be basically the exact same bug as b0b592cf08, just with a different source of unaligned structure members. Yes, that is exactly the same bug. That's how we figured out the solution = in fact - it is totally the same problem with another struct member... There's nothing to keep folks from reintroducing these kinds of issues and evidently no way to detect when they happen without lengthy reproducers= . Correct. But short of adding asserts / documentation that pointers must be= aligned or kmemleak won't work or fixing kmemleak (which I expect is not t= ractical as it would become a lot slower if nothing else) not sure what els= e can be done. Given I cannot see any alternative to fixing the kmemleak failures I think = it is worth applying this fix. Unless you have better ideas how to fix this issue? What I can say is that we run a lot of tests with our CI and applying this fix we do not see any kmemleak issues any more whilst without it we see hundreds of the above - from a single, simple test run consisting of 416 individual test cases on kernel 5.10 x86 with kmemleak enabled we got 20 failures due to this which is quite a lot. With this fix applied we get zero kmemleak related failures. I turned this tidbit into the following paragraph in the commit: Testing: We run a lot of tests with our CI, and after applying this fix we do not see any kmemleak issues any more whilst without it we see hundreds of the above report. From a single, simple test run consisting of 416 indiv= idual test cases on kernel 5.10 x86 with kmemleak enabled we got 20 failures due to= this, which is quite a lot. With this fix applied we get zero kmemleak related= failures. Describing the impact of a fix in a changelog is always helpful. That's a good idea, thank you! Also, thank you for taking the patch. Alwa= ys nice not to have to maintain too many custom kernel patches! Best regards, Anton Thanks, Ingo -- Anton Altaparmakov (replace at with @) Lead in File System Development, Tuxera Inc., http://www.tuxera.com/ --_000_1386E50F73834666A7DC7AFE8D755C19tuxeracom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8097D6F9511BF74DB1829F90B49BF7E4@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Ingo,

On 22 Mar 2024, at 10:03, Ingo Molnar <mingo@kernel.org> wrote:<= /div>
anto= n@tuxera.com> wrote:
Hi Dave,
On 14 Mar 2024, at 15:05, Dave Hansen <dave.ha= nsen@intel.com> wrote:
On 3/14/24 07:26, Anton Altaparmakov wrote:
/* image of the saved processor state */
struct saved_context {
- /*
- * On x86_32, all segment registers except gs are saved at kernel
- * entry in pt_regs.
- */
- u16 gs;
unsigned long cr0, cr2, cr3, cr4;
u64 misc_enable;
struct saved_msrs saved_msrs;
@@ -27,6 +22,11 @@ struct saved_context {
unsigned long tr;
unsigned long safety;
unsigned long return_address;
+ /*
+ * On x86_32, all segment registers except gs are saved at kernel
+ * entry in pt_regs.
+ */
+ u16 gs;
bool misc_enable_saved;
} __attribute__((packed));

Isn't this just kinda poking at the symptoms?  This seems to be
basically the exact same bug as b0b592cf08, just with a different source of unaligned structure members.

Yes, that is exactly the same bug.  That's how we figured out the solu= tion in fact - it is totally the same problem with another struct member...=

There's nothing to keep folks from reintroducing = these kinds of issues
and evidently no way to detect when they happen without lengthy reproducers= .

Correct.  But short of adding asserts / documentation that pointers mu= st be aligned or kmemleak won't work or fixing kmemleak (which I expect is = not tractical as it would become a lot slower if nothing else) not sure wha= t else can be done.

Given I cannot see any alternative to fixing the kmemleak failures I think = it is worth applying this fix.

Unless you have better ideas how to fix this issue?

What I can say is that we run a lot of tests with our CI and applying 
this fix we do not see any kmemleak issues any more whilst without it we 
see hundreds of the above - from a single, simple test run consisting of 
416 individual test cases on kernel 5.10 x86 with kmemleak enabled we got 
20 failures due to this which is quite a lot.  With this fix applied w= e 
get zero kmemleak related failures.

I turned this tidbit into the following paragraph in the commit:

&nb= sp;  Testing:

&nb= sp;  We run a lot of tests with our CI, and after applying this fix we do not
&nb= sp;  see any kmemleak issues any more whilst without it we see hundreds of &nb= sp;  the above report. From a single, simple test run consisting of 416 individual = test
&nb= sp;  cases on kernel 5.10 x86 with kmemleak enabled we got 20 failures due to this,
&nb= sp;  which is quite a lot. With this fix applied we get zero kmemleak related failure= s.

Des= cribing the impact of a fix in a changelog is always helpful.

That's a good idea, thank you!  Also, thank you for taking the pa= tch.  Always nice not to have to maintain too many custom kernel patch= es!

Best regards,

Anton<= /div>

Tha= nks,

Ingo

-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/

--_000_1386E50F73834666A7DC7AFE8D755C19tuxeracom_--