From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) (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 92D1B2F656A for ; Tue, 30 Sep 2025 10:13:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759227222; cv=none; b=VG2Sv9reUXpYhnG4B4tLr2C2ZrYGo6WNKD+gUdBIHckL+6da7vQDF47eUc7vhjkO4yH8oo3dECT7z1G9ALdgfDEJn0NzQL7xWZUNUL+4buGgjp9JY2J1IOYf9BdCgExQK9CAFUTKOG3UOmGFwj7qDJAA0Nlx76pwP6GhYpO69ho= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759227222; c=relaxed/simple; bh=mpP7G9JCL9PIhzSHc0S9qvP24/HlpcKMgjRpGUGS8CM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IcSOm//BJCZATa1aWGQk0jtmTm7iJJ1JzmKOrbo1F9BA3esSAMzoliAL0oXbpjNlx2EcYHp9fkgo5f1PvFw9AL2pAMm/p1wcdND/tDnZLPms3YXp5zZCqPMIn48Q47k3RdsiKxGFnyGQs8pC8W2jdT5lGgNmUgnGq0AxeN9+czA= 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=iAeOnS8f; arc=none smtp.client-ip=95.215.58.179 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="iAeOnS8f" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1759227217; 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=hZmqSQC1HjW/If1x8PYxKuOR/oWq1mejmSvIWyDl9Gk=; b=iAeOnS8fKLsSALcaZT1eCR+NEP2Qc+GEKd9yDnqSeZ4USGAs7Z4te+iKr6fGiraaAMLx7h kFbfnHSm1htYKvpBBXMnL1fzMM8sD4Tp+n5dXTz48B4vubJgAfbuEqM1XNA6kfCL0sZHtM VnYdniHNblgwbzdi/vzQOd6qjS2ct50= Date: Tue, 30 Sep 2025 18:13:22 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 1/1] mm: prevent poison consumption when splitting THP Content-Language: en-US To: David Hildenbrand , "Zhuo, Qiuxu" Cc: "Luck, Tony" , Jiaqi Yan , "akpm@linux-foundation.org" , "lorenzo.stoakes@oracle.com" , "linmiaohe@huawei.com" , "ziy@nvidia.com" , "baolin.wang@linux.alibaba.com" , "Liam.Howlett@oracle.com" , "npache@redhat.com" , "ryan.roberts@arm.com" , "dev.jain@arm.com" , "baohua@kernel.org" , "nao.horiguchi@gmail.com" , "Chen, Farrah" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Zaborowski References: <20250928032842.1399147-1-qiuxu.zhuo@intel.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2025/9/30 16:53, David Hildenbrand wrote: > On 30.09.25 03:48, Lance Yang wrote: >> On Tue, Sep 30, 2025 at 3:07 AM David Hildenbrand >> wrote: >>> >>> On 29.09.25 18:30, Zhuo, Qiuxu wrote: >>>> Hi Tony, >>>> >>>>> From: Luck, Tony >>>>> [...] >>>>> Subject: RE: [PATCH 1/1] mm: prevent poison consumption when >>>>> splitting THP >>>>> >>>>>> Miaohe mentioned in another e-mail that there was an HWPoisoned flag >>>>> for the raw error 4K page. >>>>>> We could use that flag just to skip that raw error page and still use >>>>>> the zeropage for other healthy sub-pages. I'll try that. >>>>> >>>>> That HWPoisoned flag is only set for raw pages where an error has been >>>>> detected. Maybe Linux could implement an >>>>> "is_this_page_all_zero_mc_safe()"[1] that would catch undetected >>>>> poison >>>> >>>> This sounds like a great suggestion to me. >>>> Let's see what others think about this and the name (though the name >>>> already LGTM 😊). >>> >>> The function name is just ... special. Not the good type of special >>> IMHO. :) >>> >>> Note that we'll be moving to pages_identical() in [1]. Maybe we would >>> want a pages_identical_mc() or sth. like that as a follow up later. >>> >>> >>> So in any case, make that a follow-up work on top of a simple fix. >> >> Yeah. IIRC, as David suggested earlier, we can just check if a page is >> poisoned using PageHWPoison(). >> >> Perhaps we should move this check into pages_identical()? This would make >> it a central place to determine if pages are safe to access and merge ;) > > I would have to go into memcmp_pages(). Would be an option, but not sure > if we should rather let callers deal with that. > > For example, in some cases it might be sufficient to just check if the > large folio has any poisoned page and give up early. FWIW, one idea I had was to create a unified pre-flight checker, like folio_pages_identical_prepare(struct folio *folio). A caller could use it before a loop of pages_identical() calls to pre-check a folio :)