Received-SPF: pass (google.com: domain of linux-kernel+bounces-103524-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Anton Altaparmakov <anton@tuxera.com>
To: Dave Hansen <dave.hansen@intel.com>
CC: "Rafael J . Wysocki" <rafael@kernel.org>, Pavel Machek <pavel@ucw.cz>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>, Chen Yu
	<yu.c.chen@intel.com>, Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>, Linux Memory Management
	<linux-mm@kvack.org>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Ingo
 Molnar <mingo@kernel.org>, "linux-pm@vger.kernel.org"
	<linux-pm@vger.kernel.org>, Linux Kernel <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <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: AQHadiEQrskV1NWHjkSsYR0U0Bb8SLE3YQqA
Date: Thu, 14 Mar 2024 15:45:44 +0000
Message-ID: <653BCAC0-8A79-400F-B496-23A2FA169786@tuxera.com>
References: <20240314142656.17699-1-anton@tuxera.com>
 <70261e2a-b87e-462e-964e-95a51ecde978@intel.com>
In-Reply-To: <70261e2a-b87e-462e-964e-95a51ecde978@intel.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?WiBd/WSYE4WNWpxzJwO2IEwKDABaiGCHFiZPB5l53GjVUmkw2+oM5IuaYo2n?=
 =?us-ascii?Q?uE6JRx5nHoQS9+FlM5i0sDFsbW93Mlp5eX0Zt+CVDrVbe65jECRAOxy1+WfL?=
 =?us-ascii?Q?T4LvDViHr+zdZ75lLt9SIAFujuo7en2D1AJI2kgI3RQ8blF0MMw95v44ZGit?=
 =?us-ascii?Q?+1ZQ/2OdqJl0ZKEtLFebvcZXyLUhE6UDwEsZoxC5aDgi9GvIEeNUKnqOZqXx?=
 =?us-ascii?Q?7vYPjnRoYAADj3NPUdqo20PlVgkHXzNFRY5Qe0xVANrwlH9DnCnPRw2PiB9B?=
 =?us-ascii?Q?EVClTIGBjny1uxND4ZFcvN648mkTTq7MjyhDWGQzZv4GEt3lu/pLuluZmnoP?=
 =?us-ascii?Q?shv/+j9HQI3ZfOq1OAvmcZqS7J2r42apMUN8/Xy5Qnz/wkXZYcZw+TzPA3nq?=
 =?us-ascii?Q?iN8b0cqjPv2SpvwTYUy2ooAAFtO7x4g3X22mH10OGVNaWYcgaxoZN+3jBB2K?=
 =?us-ascii?Q?WnxbpTa8Ia2vAoXGHgyRUav6ULvRZEC0T6j1JN+xi6R8fWM3MYgkub3egpWp?=
 =?us-ascii?Q?rRqiueUJYwrMXyUUq+mc8wYwvELIl/+B+J3OU+agSqYxN627y01s0kT5HdDX?=
 =?us-ascii?Q?AIVKUORi4sSVHGj5ERTq8lhiWjlwS3YRCN6oh56TXT9l+XzY1H4v2UzphEcl?=
 =?us-ascii?Q?+QswbNEk6gkXHgMZJsQrIoPhg5qA1DOtxsp602iiYtB50TE7zP6x+i/o8+4R?=
 =?us-ascii?Q?k/8FO0PWFfvKeDzFxY8IeuwwqbsQj2+CEv/5Am6WLxLgC78L5GPTqDXt6Na7?=
 =?us-ascii?Q?GnoSEj8UGEW21ZUvuQWguQ5QlpkDlmv/ewZpLjZLchYvHWtKNoXaEqwxBvHq?=
 =?us-ascii?Q?5md4OA1kfgVu/DnveWPTktBeLMlX0VpAcaaRjpZe+G7aFo9KBVSjj4CgJJc+?=
 =?us-ascii?Q?Ry5Yt0/DOddmlaLn6MvDMjdUr4RhJURJUmkffb+vLKYLCibDBZ2D08cNjk8F?=
 =?us-ascii?Q?VQNRVvNtzx70ZhG//Cxg0AgjkIWZuTxvvtjhumqtMPsGc3sK+FNBrScpqG0f?=
 =?us-ascii?Q?ZnZvD3IuJlWioZxKBCNlB+CkrrwFpEJSurwpHpm5lcYEUkRP7yl2DefitvCd?=
 =?us-ascii?Q?RYnbxMFfv9hPLGo8l/lZ1XMrdcYAmvpYhQkIcVABmX1Ssa+/AiGl6wTYUnKy?=
 =?us-ascii?Q?/INQHFy5T7hpjTF6I87EmUkRO/aOoACHj71gMZWaRU+tV3WXSmVPs8SLzB9B?=
 =?us-ascii?Q?uQdBG//8GG9HutUinNN+d+ZI1T1+RzR9nSODiQEEe54D9lrGwsJkPl6D0O/Z?=
 =?us-ascii?Q?7Q4iJzMpGDfQOVOHPBkV3SMtkM1XZmwRfwPOcZH4WK5s7eEhz8ZIgGecNs6R?=
 =?us-ascii?Q?IZXhAhC6p/D9FPDZN63xnEMoDRkuR/5hPaDhep5sVD2KihjpwVOZr/UOLCbi?=
 =?us-ascii?Q?gip+Lp2MJ+/J3ov9k6nsS0otoh179Z0vRCA+CJBMBfleEiVwlqPu9CI4K/qv?=
 =?us-ascii?Q?z5XNROgWQJGgGlBpM1GbLgfVYYL3P6TfA6mILtmSUXIWrOPFDSrBt6X2ojhv?=
 =?us-ascii?Q?fKHn+RUUTRwkm8rTxuj6uuU4ooz95Cny8sPxUyV6ZZtqu6u5D7/xZzqH7sFk?=
 =?us-ascii?Q?GTzVKDo7Bs3N5rWm8+YWBt0kZw3QbkEKtV6wcpup?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5EBCB49079CC674890FFC0406646BE57@eurprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
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: ba1b3b2a-4e8d-4de4-552f-08dc443dcf80
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2024 15:45:44.4159
 (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: 1yQNlXEZ6PYOUfM3UEAuC637C2laLH83UWxxJB373skPx3XSPnMbZpEkHpvFExSxudjcMVYfEkRq4CtxT2CSEw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR06MB7766

Hi Dave,

> On 14 Mar 2024, at 15:05, Dave Hansen <dave.hansen@intel.com> wrote:
>=20
> 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));
>=20
> 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 reproduce=
rs.

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 hun=
dreds of the above - from a single, simple test run consisting of 416 indiv=
idual test cases on kernel 5.10 x86 with kmemleak enabled we got 20 failure=
s due to this which is quite a lot.  With this fix applied we get zero kmem=
leak related failures.

Best regards,

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