Received: by 2002:aa6:da0e:0:b029:115:a171:fe4c with SMTP id z14csp1265686lkb; Wed, 7 Jul 2021 02:57:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKhs6CsJiB0faKF7Q+XEpGxYvdVKvjmGanED0Pu0zuTo7HjPbFCvAXdR/8jmoPt1Nc/sbf X-Received: by 2002:a92:1942:: with SMTP id e2mr18181545ilm.4.1625651875163; Wed, 07 Jul 2021 02:57:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625651875; cv=none; d=google.com; s=arc-20160816; b=O09UXjQZ/veK7R4/b5U90PMIGHEFHymMu1meUkxx//1aehH5j0nubLNUtmWLfWlM99 LP8DnbjzxB5vwjUerb32To/WShPsjJLkOERFSPhFAk6JEj570POHxXJSFtuFTf01jQiy n6zBWWZfjZTG38UKCFFyt21HWC4NWcDLDKuQh5JRPqIyG59BAp+xGNVighhi80oV/2V6 LVBf9SfvgAe8kOEqpGgKgxZSMQcgqUaoyhrrkRcpFdiykBZT4EUWD2re32GJXDt49PL6 cGzwbY9gabPkiZic/9KbBC7uAEfuCrLbMNz6zp5ro+P/KkXACquBckBK3zF3akU7ACUE Ownw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=+J8+H+XP2lnThul4AcwL0D7Xua4/Rywc5hBcnmemopI=; b=oyX1spFiHeDKNV5+DyqsV/jcKzREo5sjccszQDDUhPtyM5fFHDg9GCpqVHximsAg6x EvUVaI82Nhb2XMjcs2AZHnpELyh9kaae7XGTs/EpKS6fcytsNi/FaJJon566zOy43odv ecL02/pa878DoR7hXW/S7pHKU+yIc9nX0klmh0e+1F+kVgX0o5hFOEO0CW+GNM5vbxc/ kbdMMIyurbxorsbQQHa/uowam5QOdkqDHieW4pGZR1NVTcBP9ssunWUB8k2Mno4MO2jG ACO6AR6Oj7X7gVTwox+6qQMHtNJZ4XaDMSVKBVr2pbB//Ey4jO3yRYmgF8JXx60j/RJ0 1ZxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si14467314iob.0.2021.07.07.02.57.43; Wed, 07 Jul 2021 02:57:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231336AbhGGJ7u (ORCPT + 99 others); Wed, 7 Jul 2021 05:59:50 -0400 Received: from outbound-smtp25.blacknight.com ([81.17.249.193]:37755 "EHLO outbound-smtp25.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231181AbhGGJ7t (ORCPT ); Wed, 7 Jul 2021 05:59:49 -0400 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp25.blacknight.com (Postfix) with ESMTPS id 5B9BACACEA for ; Wed, 7 Jul 2021 10:57:08 +0100 (IST) Received: (qmail 30476 invoked from network); 7 Jul 2021 09:57:08 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.255]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 7 Jul 2021 09:57:08 -0000 Date: Wed, 7 Jul 2021 10:57:06 +0100 From: Mel Gorman To: Chao Yu Cc: Matthew Wilcox , Jaegeuk Kim , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org Subject: Re: [f2fs-dev] [PATCH] f2fs: initialize page->private when using for our internal use Message-ID: <20210707095706.GT3840@techsingularity.net> References: <20210705052216.831989-1-jaegeuk@kernel.org> <20210706091211.GR3840@techsingularity.net> <85bb893b-0dc4-5f57-23ec-3f84814b7072@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <85bb893b-0dc4-5f57-23ec-3f84814b7072@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 07, 2021 at 08:48:28AM +0800, Chao Yu wrote: > On 2021/7/6 17:12, Mel Gorman wrote: > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index d6e94cc8066c..be87c4be481f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3515,8 +3515,13 @@ void split_page(struct page *page, unsigned int order) > VM_BUG_ON_PAGE(PageCompound(page), page); > VM_BUG_ON_PAGE(!page_count(page), page); > > - for (i = 1; i < (1 << order); i++) > - set_page_refcounted(page + i); > + for (i = 1; i < (1 << order); i++) { > + struct page *tail_page = page + i; > + > + set_page_refcounted(tail_page); > + if (WARN_ON_ONCE(tail_page->private)) > + pr_info("order:%x, tailpage.private:%x", order, tail_page->private); > + } > split_page_owner(page, 1 << order); > split_page_memcg(page, 1 << order); > } > -- > 2.22.1 > > With above diff, I got this: > > ------------[ cut here ]------------ > WARNING: CPU: 3 PID: 57 at mm/page_alloc.c:3363 split_page.cold+0x8/0x3b > CPU: 3 PID: 57 Comm: kcompactd0 Tainted: G O 5.13.0-rc1+ #67 > > order:7, tailpage.private:d0000 > order:7, tailpage.private:d0000 > order:7, tailpage.private:d0000 > order:7, tailpage.private:200000 > order:7, tailpage.private:d0000 > order:7, tailpage.private:d0000 > order:7, tailpage.private:d0000 > > So how about adding set_page_private(page, 0) in split_page() to clear > stall data left in tailpages' private field? > I think it would work but it would be preferable to find out why the tail page has an order set in the first place. I've looked over mm/page_alloc.c and mm/compaction.c a few times and did not spot where set_private_page(page, 0) is missed when it should be covered by clear_page_guard or del_page_from_free_list :( -- Mel Gorman SUSE Labs