From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 B627841B361 for ; Wed, 1 Jul 2026 15:25:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782919534; cv=none; b=cRFlG3SlRelUEtXqoAMMbxLo5wj1kir941DHlgJx1yTuUIBo8y4bvIpWaXN2cT5rXjHU1qW9Ax84N1C3UK139ttuXWC3mE+nwMaHDrRVzTX4KULZIMRvhBDFY6tj8JmOZSb2/K/mAfnYyS1SKGTO2oxBRJiYw+MkjkQOjGI/zvA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782919534; c=relaxed/simple; bh=9fypG0DzqSTGTSU6Y0262mHt9ZcnWRjgkk5MvgFVJmQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=FmE5sq26a7gD3nRDzxHXU+18xMuF8To3C3uHkxfjx0D2KIc5soipzS5ViL+TM+yGmCbURd9sWeH2BzmP+ATfDDzexaj09+WYVZKtlqFNwghFAs8l8eFPgC4brqQX6Pho6HlW8eVYI1JMipabsHl85ce114W2C9RGGpF7Stujab8= 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=sjCG3GIb; arc=none smtp.client-ip=91.218.175.178 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="sjCG3GIb" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782919530; 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=H7i2gxVfdyLMw0EmDv5vkqlxZHu7upnqw28TbwSHmLg=; b=sjCG3GIbFnGZzS/i7r3lSRl+vIlTgGaZZaQyALM04jublH7FiI6uvxqzlgaoCSbxGTug8Q A6MH6TB6uDQgqhlaLT+z+xdj5MLy0+FyZQohT/e6aaw6ezoAuMrLA9vFENdJ7el94AplnS b4Q19qp1+xp63ebDSC0U5B2Wc3Ymjm0= From: Lance Yang To: riel@surriel.com Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, yang@os.amperecomputing.com Subject: Re: [PATCH] mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established Date: Wed, 1 Jul 2026 23:24:57 +0800 Message-Id: <20260701152457.29836-1-lance.yang@linux.dev> In-Reply-To: <20260701134622.3152896-1-riel@surriel.com> References: <20260701134622.3152896-1-riel@surriel.com> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Wed, Jul 01, 2026 at 09:46:22AM -0400, Rik van Riel wrote: >__split_folio_to_order() copies the hwpoison state onto each new >sub-folio while splitting a folio to a non-zero order. It did so via > > if (handle_hwpoison && page_range_has_hwpoisoned(new_head, new_nr_pages)) > folio_set_has_hwpoisoned(new_folio); > >*before* clear_compound_head(new_head)/prep_compound_page(new_head, ...) >turn @new_head from a tail page into a proper folio head. > >PG_has_hwpoisoned is a FOLIO_SECOND_PAGE flag, so folio_set_has_hwpoisoned() >resolves to folio_flags(folio, 1). With the new compound_info-based >page-flags layout, folio_flags() asserts the page is not a tail: > > VM_BUG_ON_PGFLAGS(page->compound_info & 1, page); > VM_BUG_ON_PGFLAGS(n > 0 && !test_bit(PG_head, &page->flags.f), page); > >At the original call site @new_head still has the tail marker >(compound_info bit 0 set, PG_head clear), so on CONFIG_DEBUG_VM kernels >this hits: > > kernel BUG at include/linux/page-flags.h:354 > folio_flags+0x82 > folio_set_has_hwpoisoned > __split_folio_to_order > __split_unmapped_folio > __folio_split > truncate_inode_partial_folio (shmem hole-punch / MADV_REMOVE) > >Reproduced by syzkaller: hwpoison-inject a few subpages of a large shmem >folio, then MADV_REMOVE (fallocate punch hole) on the same range, which >splits the partial folio to a non-zero order. Hmm, a bit weird ... for shmem, hwpoison-inject should call try_to_split_thp_page(..., 0), i.e. a uniform split to order-0, no? So MADV_REMOVE should no longer see a large poisoned folio. Am I missing something, or is there a syzkaller link? >Move the folio_set_has_hwpoisoned() call to after >clear_compound_head()/prep_compound_page(), where @new_folio is a real >order-new_order head folio (handle_hwpoison implies new_order != 0, so a >second page always exists). The flag still lands on the same struct page >(page[1] of the new folio); only the ordering relative to compound-head >setup changes, satisfying the FOLIO_SECOND_PAGE precondition. > >Signed-off-by: Rik van Riel >Assisted-by: Claude:claude-opus-4-8 >Fixes: fa5a06170036 ("mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order") >--- Anyway, I used a local split_huge_pages_pid() hack to create this exact situation: a large shmem folio with PG_has_hwpoisoned set and a poisoned subpage before the non-uniform split. The BUG is gone with this patch :) Tested-by: Lance Yang