Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3292210ybl; Mon, 20 Jan 2020 20:49:30 -0800 (PST) X-Google-Smtp-Source: APXvYqyd8+zayz27Oj87pKgAOT1olqdiJTWx0EkGleYBMLh/zw+Y2jR7tLDIRmCTVf2Uge9tOR3J X-Received: by 2002:a9d:4d8d:: with SMTP id u13mr2184746otk.299.1579582170503; Mon, 20 Jan 2020 20:49:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579582170; cv=none; d=google.com; s=arc-20160816; b=DwaG25kM9Gdi5qrQxmz+wsPWp7LoxWTNPg8/QUbhtrmqd+bXdy9Mp1htX1ueh1GaeZ sJMG4axus6itIyta+uQPaOjatJ4gTd/VzudDoxuPDMU0O+JyEipCXQ7RczW9tadTvzL5 UqeoYAN/afYMhBr6blSkG/PHE1GUyXxNMzyXVcadoHaleGBEmH4R58jbDoX+VczzdSJI yIIKPnh+tl85dmV/F87ofOGHqQNOyRJlZZ8Dwzmv6oEsByimB9+2e7qRbrzNrr0UB2Po Y4773X/N3G11taD060MwG2ynpPAGpfd2pDIDpcms/jXgkgD6cD9ZGBa3FBfVWytnlnl/ OueQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=KXgE+gJ4aKfiFHJ1hfnIfAQ49N14a4/53W2nNsliWIU=; b=bSr0g6e+ld7aK61MNnIcpulz2i1Hd7f6vMQQpG6aGC2lh60JaKii4+Z6QddOV1Vfww Sl2HtwWO4zBILncRYxVCyl2tpZGiaTtopMhhx7l+rx5c4CWpI/hMM9Y6/5uxHQTTT9Da paiHAQmnr++jpJX7aqiGZAmXwWuN5U4axGWNreRYs+RyasCXVe2b9lsUxtDCZBsS9kNc pssIO0tdyRpq34tT8V6EioYqnMd7bhdaOH4fo9rUJwCXa6H24ebHhZHBZx27LOTtBLtg owjkQo+Nq83B5F2LODzf6CVVYR7f9euVri/tlqTRmOvC8lXKgkxITH3xChyqo4d62u83 w+wA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si19743110oib.246.2020.01.20.20.49.17; Mon, 20 Jan 2020 20:49:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728680AbgAUEsS (ORCPT + 99 others); Mon, 20 Jan 2020 23:48:18 -0500 Received: from foss.arm.com ([217.140.110.172]:38196 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727829AbgAUEsS (ORCPT ); Mon, 20 Jan 2020 23:48:18 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CE70A31B; Mon, 20 Jan 2020 20:48:17 -0800 (PST) Received: from [10.162.16.78] (p8cg001049571a15.blr.arm.com [10.162.16.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6A10B3F52E; Mon, 20 Jan 2020 20:48:16 -0800 (PST) Subject: Re: [Patch v2 4/4] mm/page_alloc.c: extract commom part to check page To: Wei Yang Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rientjes@google.com References: <20200120030415.15925-1-richardw.yang@linux.intel.com> <20200120030415.15925-5-richardw.yang@linux.intel.com> <3987ae0f-cbfc-1066-c78f-c5c6efc570ed@arm.com> <20200120123621.GE18028@richard> From: Anshuman Khandual Message-ID: Date: Tue, 21 Jan 2020 10:19:38 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200120123621.GE18028@richard> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/20/2020 06:06 PM, Wei Yang wrote: > On Mon, Jan 20, 2020 at 12:13:38PM +0530, Anshuman Khandual wrote: >> >> >> On 01/20/2020 08:34 AM, Wei Yang wrote: >>> During free and new page, we did some check on the status of page >>> struct. There is some common part, just extract them. >> >> Makes sense. >> >>> >>> Besides this, this patch also rename two functions to keep the name >>> convention, since free_pages_check_bad/free_pages_check are counterparts >>> of check_new_page_bad/check_new_page. >> >> This probably should be in a different patch. >> > > In v1, they are in two separate patches. While David Suggest to merge it. > > I am not sure whether my understanding is correct. Keeping code refactoring and renaming separate is always better but its okay, will leave it upto you. > >>> >>> Signed-off-by: Wei Yang >>> --- >>> mm/page_alloc.c | 49 ++++++++++++++++++++++++------------------------- >>> 1 file changed, 24 insertions(+), 25 deletions(-) >>> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> index a7b793c739fc..7f23cc836f90 100644 >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -1025,36 +1025,44 @@ static inline bool page_expected_state(struct page *page, >>> return true; >>> } >>> >>> -static void free_pages_check_bad(struct page *page) >>> +static inline int __check_page(struct page *page, int nr, >>> + const char **bad_reason) >> >> free and new page checks are in and out of the buddy allocator, hence >> this common factored function should have a more relevant name. > > Hmm... naming is really difficult. Do you have any suggestion? > Probably something like bad_page_fetch_reasons() and also this helper can be expanded to include an additional argument 'bool free' which can test either PAGE_FLAGS_CHECK_AT_FREE or PAGE_FLAGS_CHECK_AT_PREP. This way bad_page_fetch_reasons() is where all possible reasons are evaluated including page->flags based and then final 'int nr' can be returned once and for all. bad_flags does not seem to be needed. Wondering what it adds more in bad_page() when page->flags gets printed universally through __dump_page(). In case it is still required, it can be derived from 'bad_reasons' evaluated in bad_page_fetch_reasons().