Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1157645pxv; Fri, 25 Jun 2021 06:42:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBGpEdRCLKqTQFqhXjfL0NiLAYFyNqCYt/NEqUGiDn/t01WhsdUmxqw9Q2+433jjmUIXRG X-Received: by 2002:a17:906:b11:: with SMTP id u17mr10700641ejg.124.1624628570266; Fri, 25 Jun 2021 06:42:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624628570; cv=none; d=google.com; s=arc-20160816; b=KomPT6s/TeIPSpLvB03yxXfWhmXCT9nhczyxpeEUtURMEvw7E5L4u4TRMWdB9zThuA minBrv/iVvr4Km6RZBFiZY3m0hINzccOaH5TYMyBu8nSI/tmhGHuOaniV1GEzR001cYE FUZDK5MvBOtM2UJMXxNbQDMncC0v4VV0B0V52TRwXe/wDO5PlLlU1DFDGJD0EeAMPsv/ FXlcseTWKohngRvM7CSGtKA4yVIuUknPLlzz6CL+a30NFvD36HQQD0L2VBQD1YUulCIT QLKw5BlC96/2T40rRN+OprOH4Ulz7Tpo+Z3UiCghclN0EqdmdQjvQgV74HqvCi2qSWOB hYIA== 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=KalqiGXC2poVrRVyGSqVOQHT8Kox76wlczgYUH1NCxg=; b=tiRtRe9Jnx0/thfEXl6dX6AHa+IMitKHjFkzh7Z5cccfeMJaV32JWnhWHXTImSacyH pNx7t81E6JvUynHNRr1QE636hwL1QyUzdK7OLAptd3YjZLVh7sjhRf7WG/Mvu2vcg7Vd n5wHoOKTS47gA9YM2SF+8IiQZ50lOqzoAngnFbfG1Y67ohCfztWRpioL5RyWU51ev+Ag 214G+uunD5ZUjZ+cL1x5lvbPNWGyp80wrvAY7qcHGluejI5bFoXW/AoBfaOwOQAjMyYJ QjafYQh7QRLJ5ympMvixjL7Vky92gDyCCZRDJP6hESMUOXkKMRwi/DE5coZ3r5AxgelZ muUg== 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 h19si6289564ejl.666.2021.06.25.06.42.26; Fri, 25 Jun 2021 06:42:50 -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 S230088AbhFYNly (ORCPT + 99 others); Fri, 25 Jun 2021 09:41:54 -0400 Received: from elvis.franken.de ([193.175.24.41]:49749 "EHLO elvis.franken.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbhFYNlw (ORCPT ); Fri, 25 Jun 2021 09:41:52 -0400 Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1lwm3G-0005Tx-00; Fri, 25 Jun 2021 15:39:22 +0200 Received: by alpha.franken.de (Postfix, from userid 1000) id 93769C071C; Fri, 25 Jun 2021 15:39:09 +0200 (CEST) Date: Fri, 25 Jun 2021 15:39:09 +0200 From: Thomas Bogendoerfer To: zhanglianjie Cc: linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, tangyouling@loongson.cn Subject: Re: [PATCH] mm: Fix the problem of mips architecture Oops Message-ID: <20210625133909.GA2565@alpha.franken.de> References: <20210624032212.24769-1-zhanglianjie@uniontech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210624032212.24769-1-zhanglianjie@uniontech.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 24, 2021 at 11:22:12AM +0800, zhanglianjie wrote: > The cause of the problem is as follows: > 1. when cat /sys/devices/system/memory/memory0/valid_zones, > test_pages_in_a_zone() will be called. > 2. test_pages_in_a_zone() finds the zone according to stat_pfn = 0. > The smallest pfn of the numa node in the mips architecture is 128, > and the page corresponding to the previous 0~127 pfn is not > initialized (page->flags is 0xFFFFFFFF) > 3. The nid and zonenum obtained using page_zone(pfn_to_page(0)) are out > of bounds in the corresponding array, > &NODE_DATA(page_to_nid(page))->node_zones[page_zonenum(page)], > access to the out-of-bounds zone member variables appear abnormal, > resulting in Oops. > Therefore, it is necessary to keep the page between 0 and the minimum > pfn to prevent Oops from appearing. > > Signed-off-by: zhanglianjie > --- > arch/mips/kernel/setup.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c > index 23a140327a0b..f1da2b2ba5e9 100644 > --- a/arch/mips/kernel/setup.c > +++ b/arch/mips/kernel/setup.c > @@ -653,6 +653,8 @@ static void __init arch_mem_init(char **cmdline_p) > */ > memblock_set_current_limit(PFN_PHYS(max_low_pfn)); > > + memblock_reserve(0, PAGE_SIZE * NODE_DATA(0)->node_start_pfn); > + which platform needs this ? This look it should be better fixed in the platform memory registration code. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]