From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4B2CC04A95 for ; Tue, 25 Oct 2022 08:50:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E95F8E0002; Tue, 25 Oct 2022 04:50:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 299A78E0001; Tue, 25 Oct 2022 04:50:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 188D68E0002; Tue, 25 Oct 2022 04:50:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 094258E0001 for ; Tue, 25 Oct 2022 04:50:21 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B512E80847 for ; Tue, 25 Oct 2022 08:50:20 +0000 (UTC) X-FDA: 80058850200.06.7451FCE Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf20.hostedemail.com (Postfix) with ESMTP id 2672F1C0007 for ; Tue, 25 Oct 2022 08:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666687819; x=1698223819; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=+sq3Tuq3OmApd38934B0rmhnfZ4wp2+OMxOZQWK5IZo=; b=FiurEE9uXl+HCJ91qLJFlAlzbaZCo44tMWso3pMOWl3tIV5HYWOrgml+ J8v2FKdBCfbSFO7wPyk3qfE0eXnlTBov3o2nlIpbpolu72w75dVxKsOeK VmopKQDAPvNe0JfaSd5uwF9739Vba+p4OZ/Wy/wya/7VY5L++QJK9vWbn J1sumjkRTCvMsQbWtLy6zIAcDhZpRXgLrkKSPvhrZ3wa+x9TCzUM1r7kf Kx9nPCGWkIsY7Zkd+vkx4tCREEMTGq3+4xBN8aCu7LAfwCJmjjPhau1jL Mls4FCjYPJMd6cdb1n3yglWDSGJf7/Wjd+uF1lF8bz22q/99gd5GIdQCb w==; X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="307619026" X-IronPort-AV: E=Sophos;i="5.95,211,1661842800"; d="scan'208";a="307619026" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2022 01:50:17 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10510"; a="700465631" X-IronPort-AV: E=Sophos;i="5.95,211,1661842800"; d="scan'208";a="700465631" Received: from anagimen-mobl1.ger.corp.intel.com (HELO [10.213.203.143]) ([10.213.203.143]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2022 01:50:16 -0700 Message-ID: <8d9517cc-6fba-ede0-a95f-e9b036e75ceb@linux.intel.com> Date: Tue, 25 Oct 2022 09:50:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: mm/huge_memory: do not clobber swp_entry_t during THP split Content-Language: en-US To: Mel Gorman Cc: "Matthew Wilcox (Oracle)" , Hugh Dickins , Linux MM , Matthew Auld , "Intel-gfx@lists.freedesktop.org" References: <1596edbb-02ad-6bdf-51b8-15c2d2e08b76@linux.intel.com> <20221024142321.f2etddxtqa47bib7@techsingularity.net> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: <20221024142321.f2etddxtqa47bib7@techsingularity.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666687819; a=rsa-sha256; cv=none; b=35OC920fy24yL87C5t1QL6IzKX1A8+acKqV0ioZVxVH6QSEEVXmcbo4CrdY3a0qbPB5kdV Sj0T+8GmQbd65ZZt5LwCN6NiA8juTQO+hXU8IV0m5LqUjxcQNzZUksDX9gzXPqPlM7LTGw xjYPt+pQ8F3ilro6carikDZzaa5B1YA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=FiurEE9u; spf=none (imf20.hostedemail.com: domain of tvrtko.ursulin@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=tvrtko.ursulin@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666687819; h=from:from:sender: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:dkim-signature; bh=dPen99e2SBVO7MZZEDyasidexKb8q7LpZDxhhWML5QY=; b=6CelMnqnvMfn3vLiIG8NpHzERwW+tphBFWvdf3Z3bMCXVgkQ7M/amaaqT3CIi9QHhzZitG e3q3aZfYZOTZw7KB5ZCioTzVJu9qXMFVH0o/iXXtGeB32KIlibiO/yKGdJHSLzdZ0V06V5 Pd4vvx8gExPtGjOEBcbLAxlJ2+vMXOw= X-Rspamd-Queue-Id: 2672F1C0007 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=FiurEE9u; spf=none (imf20.hostedemail.com: domain of tvrtko.ursulin@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=tvrtko.ursulin@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam04 X-Stat-Signature: obgo8mjyzyjudtsfq5gwfiy6dweqo5jb X-HE-Tag: 1666687818-637410 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 24/10/2022 15:23, Mel Gorman wrote: > On Mon, Oct 24, 2022 at 02:04:50PM +0100, Tvrtko Ursulin wrote: >> >> Hi Mel, mm experts, >> >> With 6.1-rc2 we started hitting the WARN_ON added in 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") in i915 automated CI: >> > > Thanks for the report. As shmem pages pages are allocated via vma_alloc_folio > and are compound pages, can you try the following patch please? If it > still triggers, please post the new oops as it'll include the tail page > information. > > --8<-- > From: Hugh Dickins > Subject: [PATCH] mm: prep_compound_tail() clear page->private > > Although page allocation always clears page->private in the first page > or head page of an allocation, it has never made a point of clearing > page->private in the tails (though 0 is often what is already there). > > But now commit 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t > during THP split") issues a warning when page_tail->private is found to > be non-0 (unless it's swapcache). > > Change that warning to dump page_tail (which also dumps head), instead > of just the head: so far we have seen dead000000000122, dead000000000003, > dead000000000001 or 0000000000000002 in the raw output for tail private. > > We could just delete the warning, but today's consensus appears to want > page->private to be 0, unless there's a good reason for it to be set: > so now clear it in prep_compound_tail() (more general than just for THP; > but not for high order allocation, which makes no pass down the tails). > > Fixes: 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") > Signed-off-by: Hugh Dickins > Cc: Mel Gorman > Cc: Matthew Wilcox (Oracle) > Cc: > --- > mm/huge_memory.c | 2 +- > mm/page_alloc.c | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 03fc7e5edf07..561a42567477 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2462,7 +2462,7 @@ static void __split_huge_page_tail(struct page *head, int tail, > * Fix up and warn once if private is unexpectedly set. > */ > if (!folio_test_swapcache(page_folio(head))) { > - VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, head); > + VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, page_tail); > page_tail->private = 0; > } > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b5a6c815ae28..218b28ee49ed 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -807,6 +807,7 @@ static void prep_compound_tail(struct page *head, int tail_idx) > > p->mapping = TAIL_MAPPING; > set_compound_head(p, head); > + set_page_private(p, 0); > } > > void prep_compound_page(struct page *page, unsigned int order) The patch seems to fix our CI runs. Is it considered final version? If so I can temporarily put it in until it arrives via the next rc - assuming that would be the flow from upstream pov? Regards, Tvrtko