From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (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 BC03B2236F0 for ; Mon, 13 Jul 2026 06:56:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783925822; cv=none; b=rSJ3RBATNOo38n/rozslk6ObqFLpoKtVxJM5QMbeLvPL7PhRWGU0JxT/MfKG1Ga16Ghv0sTwtOL2hMzkRxXDmwbxEVhZUqZZdCPDmmjDbfRgTjQGzMEHT5Q/mhd0WMxjjpF+dedgjNujzM56aNb+DuUWfoeW2hkBarq5ECErNJw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783925822; c=relaxed/simple; bh=81b94a3Ux5h0vGMQZBrbrhzfJoUeR3UBK0gWREMzj1I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Kt5JEUCkpZ3GIvY307z61lafzXsoA9x116KU6cH3SFdrzy02Q0yWnBeInw+wy/RPzF974S7AbIHohO3qv68fvdBu8y4zs87UzPalK870HpQqb7F3UFwOpEi8hV3WP5xasSIcZxzHR7r9hHDRVNT2PGn9ed1KKt4kes4dx27Owbs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=vMUGp8iB; arc=none smtp.client-ip=91.218.175.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="vMUGp8iB" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783925817; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rQAHpQDnzihtw7jcUMgYCPB2YUVD98f2lEQKq6RVkg0=; b=vMUGp8iBd1hqNeUPKxjP4p0bJFLxsPJZdFXYfyNfrZEFB8SOrt0nsGk1PmHgAdCt7na0d3 WAOdaqiOJcYxuaKTkqzor0ti+U7UHlHUBarAj40wN3K7o83Iv5finEphcMq7v8m7SFNY+C t1J0uv9KOP7rJQiciUwn73tu3PMzjKA= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH v6 2/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20260713-mark-after-vmemmap-populate-v6-2-b945ceba29d4@iscas.ac.cn> Date: Mon, 13 Jul 2026 14:56:20 +0800 Cc: Alexandre Ghiti , Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Suren Baghdasaryan , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org Content-Transfer-Encoding: 7bit Message-Id: References: <20260713-mark-after-vmemmap-populate-v6-0-b945ceba29d4@iscas.ac.cn> <20260713-mark-after-vmemmap-populate-v6-2-b945ceba29d4@iscas.ac.cn> To: Vivian Wang X-Migadu-Flow: FLOW_OUT > On Jul 13, 2026, at 14:15, Vivian Wang wrote: > > section_activate() does not flush TLB after populating new vmemmap > pages. On most architectures, this is okay. However it is a problem on > RISC-V since there the TLB caching non-present entries is permitted, > which causes spurious faults on some hardwares. > > This seems to be most easily reproduced with DEBUG_VM=y and > PAGE_POISONING=y, which causes these newly mapped struct pages to be > poisoned i.e. written to immediately after mapping. > > Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range, > and call it after hotplugging vmemmap, which gets the possible spurious > fault handled in the exception handler. > > At least for now, the only other architecture with both > SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar > problem with newly valid PTEs. But there flush_cache_vmap() is just a PowerPC is actually unaffected here since it achieves the desired effect via vmemmap_set_pmd. However, your patch will pave the way for a great cleanup to remove PowerPC's architectural vmemmap_set_pmd, given that it already relies on flush_cache_vmap() for the required barrier operations. > ptesync. So it should be safe to do this for generic code while having > minimal performance impact. After the cleanup for the PowerPC, it will emit only once ptesync operation, so it will be a minor performance improvement. > > Suggested-by: Muchun Song > Signed-off-by: Vivian Wang Reviewed-by: Muchun Song Thanks.