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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7565C43613 for ; Fri, 21 Jun 2019 23:42:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9D6C02089E for ; Fri, 21 Jun 2019 23:42:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561160569; bh=9jNNQ6ZuBBOjZIW3HIow9t4gY+OUpSdjtQl5zrDEMdQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=qNC0aWmAAJmUztrLIk3m7XaET2m4M54hq6iTeo2tl4sEnEMnLKRQMuRpLOyoF5Sjj eownFLV7+VGXtCb+GyIm33XFevqo1Npk0oTbNNI3AsXOfbYfwUP9GC3b2+T1kgL16+ eiLEd2+ybFaKbPeKtCkOhhZkd5qmNdojEm7J3DGA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726052AbfFUXmt (ORCPT ); Fri, 21 Jun 2019 19:42:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:48462 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbfFUXms (ORCPT ); Fri, 21 Jun 2019 19:42:48 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CC20B2084E; Fri, 21 Jun 2019 23:42:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561160568; bh=9jNNQ6ZuBBOjZIW3HIow9t4gY+OUpSdjtQl5zrDEMdQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RDDEklul7g0TwzW9+rYABCiLxD3N9O7GjpeOksdPT5+/ufp4LUGpriR31HgIwLS4N su+rzFDliqa/VpGbuq7WC+iq0nUGUObMkXCICTQFtPxehIJZ4EugjMAlfNTPpNEqd2 UO3XDcH6k2EANV4YmvD/OKPZrb5GXc3G08Mo32mA= Date: Fri, 21 Jun 2019 16:42:46 -0700 From: Andrew Morton To: David Hildenbrand Cc: Qian Cai , linux-kernel@vger.kernel.org, Dan Williams , linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, Andrew Banman , Anshuman Khandual , Arun KS , Baoquan He , Benjamin Herrenschmidt , Greg Kroah-Hartman , Johannes Weiner , Juergen Gross , Keith Busch , Len Brown , Mel Gorman , Michael Ellerman , Michael Neuling , Michal Hocko , Mike Rapoport , "mike.travis@hpe.com" , Oscar Salvador , Oscar Salvador , Paul Mackerras , Pavel Tatashin , Pavel Tatashin , Pavel Tatashin , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Rashmica Gupta , Stephen Rothwell , Thomas Gleixner , Vlastimil Babka , Wei Yang Subject: Re: [PATCH v3 0/6] mm: Further memory block device cleanups Message-Id: <20190621164246.9a2354a571da41950bb74562@linux-foundation.org> In-Reply-To: <1c2edc22-afd7-2211-c4c7-40e54e5007e8@redhat.com> References: <20190620183139.4352-1-david@redhat.com> <1561130120.5154.47.camel@lca.pw> <1c2edc22-afd7-2211-c4c7-40e54e5007e8@redhat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, 21 Jun 2019 20:24:59 +0200 David Hildenbrand wrote: > @Qian Cai, unfortunately I can't reproduce. > > If you get the chance, it would be great if you could retry with > > diff --git a/drivers/base/memory.c b/drivers/base/memory.c > index 972c5336bebf..742f99ddd148 100644 > --- a/drivers/base/memory.c > +++ b/drivers/base/memory.c > @@ -868,6 +868,9 @@ int walk_memory_blocks(unsigned long start, unsigned > long size, > unsigned long block_id; > int ret = 0; > > + if (!size) > + return; > + > for (block_id = start_block_id; block_id <= end_block_id; > block_id++) { > mem = find_memory_block_by_id(block_id); > if (!mem) > > > > If both, start and size are 0, we would get a veeeery long loop. This > would mean that we have an online node that does not span any pages at > all (pgdat->node_start_pfn = 0, start_pfn + pgdat->node_spanned_pages = 0). I think I'll make that a `return 0' and I won't drop patches 4-6 for now, as we appear to have this fixed. From: David Hildenbrand Subject: drivers-base-memoryc-get-rid-of-find_memory_block_hinted-v3-fix handle zero-length walks Link: http://lkml.kernel.org/r/1c2edc22-afd7-2211-c4c7-40e54e5007e8@redhat.com Reported-by: Qian Cai Tested-by: Qian Cai Signed-off-by: Andrew Morton --- drivers/base/memory.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/base/memory.c~drivers-base-memoryc-get-rid-of-find_memory_block_hinted-v3-fix +++ a/drivers/base/memory.c @@ -866,6 +866,9 @@ int walk_memory_blocks(unsigned long sta unsigned long block_id; int ret = 0; + if (!size) + return 0; + for (block_id = start_block_id; block_id <= end_block_id; block_id++) { mem = find_memory_block_by_id(block_id); if (!mem)