From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B47B5378D87 for ; Sat, 28 Mar 2026 12:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774701562; cv=none; b=bO/0RyZJVPFlGpNDFE2Ez+AuVLZGWOWMd13Ck/cB820uuzFEgWSzdGEa9OcZv0JWEM5GTaaLWY+HjXzaWwCSyS9cBE+fCWMWpANlbQDDhl2ekPs/ZgwjoRYrF0ic+aD+7xkIFoCxcqQQ7KKvn97dhPvOAesToj2fSxRxmjIe7aQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774701562; c=relaxed/simple; bh=Y1Nt1x3pMYxVj/GuEWqq+A9TIEMyeLTBsVLOk/EyMyU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=d7aeqtFeqFO4WB/kP04Ql9D+0xqk74W+7iBP5KI9pJ8OizldBFr8hG0aC135ORLOYQX7cK4O4uaPujkTF782rbjyd9X29z0oVQGkb9I1sd8mvGbkOpXVWGyO9FWNYewqIZWu2qibDvbzcZDPdkMoj07IsUt4hukU4I8fgubQMLM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SyAUFcsU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SyAUFcsU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FDD9C2BC9E; Sat, 28 Mar 2026 12:39:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774701562; bh=Y1Nt1x3pMYxVj/GuEWqq+A9TIEMyeLTBsVLOk/EyMyU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SyAUFcsUIqQR84zy//HN5c8Z2nThVT8O3omGXMgqvNmq6RxNW9V5l5CPFT/Qvtyfw nXwbYfHQGoTq60NZu/3E5WWgi0D46xSl4rwPqyv6p+Bf93+9iAWwVvghCNiSLtl7U4 zRfe9Ede76nRNm/9fu3OdBHFHtHrQQE/yF/7i77IITvFmME3DLzNw07Pm9GAhJFZ+Y OJYl0SAv+juQWWQzHnkhCvkDlmW/NuuR84ge+NUz9z6xNc9Ju0q4Io7Y8DEeG9/Dnt qXVmdvXAjTNss1ruWCzFg1lDlOMJJhc/jw1T1k2dHUC/I5eENWGThN0/NioHEY0ijG f8qXqRNfWkJIA== Date: Sat, 28 Mar 2026 15:39:15 +0300 From: Mike Rapoport To: Borislav Petkov Cc: x86@kernel.org, Bert Karwatzki , Dave Hansen , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/alternative: delay freeing of smp_locks section Message-ID: References: <20260328081634.797552-1-rppt@kernel.org> <20260328114118.GAace-Xu8bEKacpCtZ@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260328114118.GAace-Xu8bEKacpCtZ@fat_crate.local> On Sat, Mar 28, 2026 at 12:41:18PM +0100, Borislav Petkov wrote: > On Sat, Mar 28, 2026 at 11:16:34AM +0300, Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" > > > > On UP systems alternative_instructions() frees memory occupied by smp_locks > > UP systems? > > I don't understand - Bert's machine is a SMP. Argh, I misread the 'if (!uniproc_patched' :( > > section immediately after patching the lock instructions. > > > > With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled this happens before the > > memory map is fully initialized and the struct pages representing the freed > > memory might get overwritten by deferred initialization of the memory map. > > > > Move freeing of smp_locks section to an initcall to ensure it will happen > > after the memory map is fully initialized. > > > > Signed-off-by: Mike Rapoport (Microsoft) > > Tested-By: Bert Karwatzki > > I don't understand even more: why have we not hit this before? That memory was never actually freed, it remained reserved because free_init_pages() calls free_reserved_area() but does not update memblock. > No Fixes: tag? It's as old as CONFIG_DEFERRED_STRUCT_PAGE_INIT (v4.2) or even before that. If you think that fixing this leak is important enough to backport, it affects all mainlined stable releases. > Something must've changed for this to fire... Yes, I added a WARN() in free_reserved_area() to lure such cases and prevent them in the future. I'll wait a bit for more comments before rewriting changelog and reposting. > -- > Regards/Gruss, > Boris. -- Sincerely yours, Mike.