Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp7749307imm; Thu, 28 Jun 2018 08:47:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdXc73AkF6w40XiGq2LlPpEWKK4K7W02MX6FSP0tldOXRVIbB1xy7vpxBXgVjWGzMRYiklv X-Received: by 2002:a17:902:6047:: with SMTP id a7-v6mr3437444plt.188.1530200834372; Thu, 28 Jun 2018 08:47:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530200834; cv=none; d=google.com; s=arc-20160816; b=npbRarOYkf0k1f5O/wKNFbivQBKXRCmpOCT6MsxV4Ieu0n2Eru1/FN1hdqlc/bzBaD cSz/HcdTqNzA4SiLcwirxg1tK2c20W7Z5fGA8oYR1Ygzc4vWo0vVnDyy4ml3srcqL9tg tY73b7W5Oo7kE2+fzM9o5ddnN/P2nfW8/yJkSfYJkdq1UqrBCeU34cnBcphQyc+cPa6a woRLi7Lr3GHSq4VEk4zyMOOguvVukTED82KKLeTof8lZWFoi7jXut5UMjShFj1V0MRge LUdQBMKIWYbCV/odN4yl6bQXz7g37aZ9Wv39REPDh8SsGmdgws1PL/g8RxxjhSO+xpyK VUhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=Jq12nq3reiDKCYh+fPduG5hfM5jjtJBLoF53xlEMsJA=; b=PTVjNysbYNFJLFOIPW4GixI2yYbZI89Cnr5xgyH5u/a7DleW3O+RzJyomOo2X1yCH7 fkfvfOnRJ18XrYwJoiKzHr0uSQX3pTtCHTTE2fij1OfZFZMH2/CCGtXAy0dIBbN4ReUI rgamEIOFsCKhWrbvXc57joaC1UBQcrvgWa4sSyyD3iVruh7ffBCsCzv1CUxRt7K0JARk nTRV7cYgmZslS4YaDAugOJb4hOKUT7pFLTk13M5RKIHb7anVFPCBbl2QAdlS0Qian9Vl m6HeGpq7gYdcqr5d/5eR6SolfBIk1uRGBI/DxMU8o3ivRkmOdIcomumsrIJsq0BDbOhx R+1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=TebH7dpn; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2-v6si6892830plh.136.2018.06.28.08.46.59; Thu, 28 Jun 2018 08:47:14 -0700 (PDT) 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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=TebH7dpn; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934824AbeF1MMo (ORCPT + 99 others); Thu, 28 Jun 2018 08:12:44 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:46418 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933830AbeF1MMn (ORCPT ); Thu, 28 Jun 2018 08:12:43 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5SC4FlI185876 for ; Thu, 28 Jun 2018 12:12:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=Jq12nq3reiDKCYh+fPduG5hfM5jjtJBLoF53xlEMsJA=; b=TebH7dpnLtO98sKtwnjqLbKQFt52JkdOPYToZBhkAJudy8YIB3bAP2YEhPa0snth1+HN Wkr1B/rnhbv2FtWW5cGML9X4xEJpC5tmocwuQahdLn8CUfAIRbklfUEoVkIGuSW++ZHa 89cW+69Xc4wO4ERvP4BVHI20UDeJq1FpUmHa+uW2E/DgIiJtqqeLquqo4r8uhYBu1oZ8 WoQEth8HdIWWFaynUAr0+VGa65NUoc/IKVfqpDg48y09Nr5f/mWHeKTTMaq/UNz9vn8J oSIXzljs86ZNFhXMQgC9WQrlkOGk7d7nxvsvfRjDI4xN1b0oPYynDQwAaygXC2jeZc1I lQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2jukmu24mv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 28 Jun 2018 12:12:42 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w5SCCfIg002729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 28 Jun 2018 12:12:41 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w5SCCfIS000635 for ; Thu, 28 Jun 2018 12:12:41 GMT Received: from mail-oi0-f45.google.com (/209.85.218.45) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Jun 2018 05:12:41 -0700 Received: by mail-oi0-f45.google.com with SMTP id r16-v6so4435637oie.3 for ; Thu, 28 Jun 2018 05:12:40 -0700 (PDT) X-Gm-Message-State: APt69E16kIOsAYIJUotH02RcyyCVMY7+xlL3qlSNn5Bu01Sy1O5H54// qtIB7m9/i8RK9+euLeBSc/5k3d1mbxK9m/M8jXY= X-Received: by 2002:aca:3b09:: with SMTP id i9-v6mr5904844oia.156.1530187960686; Thu, 28 Jun 2018 05:12:40 -0700 (PDT) MIME-Version: 1.0 References: <20180628062857.29658-1-bhe@redhat.com> <20180628062857.29658-5-bhe@redhat.com> <20180628120937.GC12956@techadventures.net> In-Reply-To: <20180628120937.GC12956@techadventures.net> From: Pavel Tatashin Date: Thu, 28 Jun 2018 08:12:04 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 4/5] mm/sparse: Optimize memmap allocation during sparse_init() To: osalvador@techadventures.net Cc: bhe@redhat.com, LKML , Andrew Morton , dave.hansen@intel.com, pagupta@redhat.com, Linux Memory Management List , kirill.shutemov@linux.intel.com Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8937 signatures=668703 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=504 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280140 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > + if (nr_consumed_maps >= nr_present_sections) { > > + pr_err("nr_consumed_maps goes beyond nr_present_sections\n"); > > + break; > > + } > > Hi Baoquan, > > I am sure I am missing something here, but is this check really needed? > > I mean, for_each_present_section_nr() only returns the section nr if the section > has been marked as SECTION_MARKED_PRESENT. > That happens in memory_present(), where now we also increment nr_present_sections whenever > we find a present section. > > So, for_each_present_section_nr() should return the same nr of section as nr_present_sections. > Since we only increment nr_consumed_maps once in the loop, I am not so sure we can > go beyond nr_present_sections. > > Did I overlook something? You did not, this is basically a safety check. A BUG_ON() would be better here. As, this something that should really not happening, and would mean a bug in the current project.