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 AB5B01E5B63; Mon, 16 Feb 2026 10:20:18 +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=1771237218; cv=none; b=JCLl2JqFHMImEtd9IEC3r/mTvBXdq5Y/a8PUXc0o3V9z9cBf3rB0u5RV1taF2sSc10TzKHD6Y82jsl6iG6ZxKBKNoK1FHKoSohNxh9InKmZKCj7Cl5xSbHhHzv+G0+BT+HAToWVkqMe4ryvaGLraqZ+K+mj3efoMO45wy/V5w9U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771237218; c=relaxed/simple; bh=9x/wEscj0b/VkFNgRUqs2ndAExbsHqVH9Mcdh31EbY8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uACCfSYw2KCllyhZ7qLA556jXsUUokvlWFK7/+K65ofgKv1D4lMbS9ZidDqVSy1/5aDTI74aPh7iUMfc968ourIXId00K/CM0E6I1p98AuG9mXtsW2focLUrb5zzZpauMCTbXYQ0Yz7W6l8WmMXDuIPhtsuJ4D9ZLh1R5dtYQ/0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=FAD0JWgZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="FAD0JWgZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C763AC116C6; Mon, 16 Feb 2026 10:20:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1771237218; bh=9x/wEscj0b/VkFNgRUqs2ndAExbsHqVH9Mcdh31EbY8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FAD0JWgZFZvwTzFNC9F1aj9DFBEdbeVmrpYqk4L7GZ5SkhQx4iRxQHsstZodDkjT/ cXsdzBEXZnY57tt9qbJ8audAb7rt1XxGomex2d0FXrWLP6k6Omu6rCfMIGWW+64UIr 9/+dL+99Y19jzjnxT/cnOWXlS/a7FinIQuEZFlpw= Date: Mon, 16 Feb 2026 11:20:15 +0100 From: Greg Kroah-Hartman To: Huacai Chen Cc: Huacai Chen , Sasha Levin , Xuerui Wang , stable@vger.kernel.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, Tiezhu Yang Subject: Re: [PATCH for 6.6 & 6.12] LoongArch: Rework KASAN initialization for PTW-enabled systems Message-ID: <2026021602-unsalted-straining-edfb@gregkh> References: <20260215140953.1224579-1-chenhuacai@loongson.cn> <2026021631-sabbath-wrangle-3496@gregkh> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Feb 16, 2026 at 06:09:31PM +0800, Huacai Chen wrote: > Hi, Greg, > > On Mon, Feb 16, 2026 at 5:52 PM Greg Kroah-Hartman > wrote: > > > > On Sun, Feb 15, 2026 at 10:09:53PM +0800, Huacai Chen wrote: > > > From: Tiezhu Yang > > > > > > commit 5ec5ac4ca27e4daa234540ac32f9fc5219377d53 upstream. > > > > > > "kasan_early_stage = false" indicates that kasan is fully initialized, > > > so it should be put at end of kasan_init(). > > > > > > Otherwise bringing up the primary CPU failed when CONFIG_KASAN is set > > > on PTW-enabled systems, here are the call chains: > > > > > > kernel_entry() > > > start_kernel() > > > setup_arch() > > > kasan_init() > > > kasan_early_stage = false > > > > > > The reason is PTW-enabled systems have speculative accesses which means > > > memory accesses to the shadow memory after kasan_init() may be executed > > > by hardware before. However, accessing shadow memory is safe only after > > > kasan fully initialized because kasan_init() uses a temporary PGD table > > > until we have populated all levels of shadow page tables and writen the > > > PGD register. Moving "kasan_early_stage = false" later can defer the > > > occasion of kasan_arch_is_ready(), so as to avoid speculative accesses > > > on shadow pages. > > > > > > After moving "kasan_early_stage = false" to the end, kasan_init() can no > > > longer call kasan_mem_to_shadow() for shadow address conversion because > > > it will always return kasan_early_shadow_page. On the other hand, we > > > should keep the current logic of kasan_mem_to_shadow() for both the early > > > and final stage because there may be instrumentation before kasan_init(). > > > > > > To solve this, we factor out a new mem_to_shadow() function from current > > > kasan_mem_to_shadow() for the shadow address conversion in kasan_init(). > > > > The subject line AND the commit text here do not match the upstream > > commit AND the diff is different and you did not explain what changed or > > why :( > The subject line is exactly the same as the upstream commit (no difference). > > The changes in the commit message is because the text of the patch has > changed (this is why the upstream commit cannot be applied), and I > think the commit message should exactly reflect the text. No, the commit message should match exactly what is merged in Linus's tree and then the comments before your new signed-off-by should describe what is different here from what is in Linus's tree. Don't rework changelog text for stable backports, that only confuses everyone involved and it makes it look like you are doing different things than expected (i.e. attempting to get stuff that is NOT upstream merged.) thanks, greg k-h