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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F219CE7AB0 for ; Mon, 9 Sep 2024 07:11:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9C556B0095; Mon, 9 Sep 2024 03:11:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4CFF6B00B5; Mon, 9 Sep 2024 03:11:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A13F86B00B6; Mon, 9 Sep 2024 03:11:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 82C936B0095 for ; Mon, 9 Sep 2024 03:11:35 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 31E30C1D97 for ; Mon, 9 Sep 2024 07:11:35 +0000 (UTC) X-FDA: 82544329350.28.40ADB0C Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by imf17.hostedemail.com (Postfix) with ESMTP id 8EE9040008 for ; Mon, 9 Sep 2024 07:11:32 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Kn5DlPgl; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.16 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725865780; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v3PGzL/SLO79BLbYB0NKT/dLd9pksiR8+NcYZBzixQw=; b=y02UHpe2T+k2wUAtic9yZ2zAO8D9xT4VVIWecHIwpxcX+q4Q49XhcukFEeSOBWwt0j8czZ 59ERGbd6Pq+5I4E8o9hkQE3EHQyTRv8DDoU/DYSNwWbpOtooLOSYldkJNvP24qoA6M6NJh 8rvSFwuGX86C297m//3yoS6wXtvXsYY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725865780; a=rsa-sha256; cv=none; b=BPbdCpTkUSiU6dPpx24R1r1WykQO/CiGrdIGKHVfRYtDoL/6GfowCYRhUbkada0tQ08ovw Acvisoi9FF2JHM/sWFJjj1LxFtFET3QCDghxq772rrza59SLqEWWyLObrRlHvGdf/+zPqn sxC/LYOfCInSEFthZ7Od3lUOBMDZ9GQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Kn5DlPgl; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.16 as permitted sender) smtp.mailfrom=ying.huang@intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725865892; x=1757401892; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=HEiW+hKYJvZs6VW5BHpJq8GDxL0+eQcdyn+G9+ESbDs=; b=Kn5DlPglIuKBVD+BdyZ6UMPe0UuDzgkjN23brDexEbFxN492eHBecD8D F/Cowj4eoF5UxG30lbw30KWDjtjhQsUPxUJ1DneMQWk7mCaweXX13ahoA 4MH4OZFlyyUBGqC9v8pgUgiA6qdRVJtvhc4jVSR8Zx05BgZPANybpA1Nr mQXviPe1grcmqVNAKS45tq3Ead7A84lZ3nKQSVDtubGsSCMYPdlrskcye YqZFrJ3qRoojJRobkeRavYLsj9kP6vZXjRtKsWOsUa5j9UgAeadlaOatk 6bODji0at6em4OaQ/oIy3oFN23dZ3tEthHk8HyTqP3NX6/spovDXij2Rr Q==; X-CSE-ConnectionGUID: XLJSuEdqQhe5ctEJkvIBzw== X-CSE-MsgGUID: bkPqK1P0RxehjvPZzVd1Yg== X-IronPort-AV: E=McAfee;i="6700,10204,11189"; a="13435586" X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="13435586" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 00:11:30 -0700 X-CSE-ConnectionGUID: X8dz3/fEQK2RNTLfS6HrmA== X-CSE-MsgGUID: BCPV/t7FTOuLZ9dwvweIQQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,213,1719903600"; d="scan'208";a="66256125" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 00:11:27 -0700 From: "Huang, Ying" To: David Hildenbrand Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, Dan Williams , Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Alistair Popple , Andy Shevchenko , Bjorn Helgaas , Baoquan He Subject: Re: [PATCH -v3 2/3] resource: Make alloc_free_mem_region() works for iomem_resource In-Reply-To: <28bbd51b-cc47-4468-9523-45dab25d20dd@redhat.com> (David Hildenbrand's message of "Mon, 9 Sep 2024 09:04:17 +0200") References: <20240906030713.204292-1-ying.huang@intel.com> <20240906030713.204292-3-ying.huang@intel.com> <28bbd51b-cc47-4468-9523-45dab25d20dd@redhat.com> Date: Mon, 09 Sep 2024 15:07:54 +0800 Message-ID: <878qw11f05.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8EE9040008 X-Stat-Signature: tmod1desxaugsq1im6u7tfogyog4s1z9 X-Rspam-User: X-HE-Tag: 1725865892-821435 X-HE-Meta: U2FsdGVkX1+JvxHywfcoPeaFhEP2Se3laQV7HsiNOSFEiKBaBzMC7j0dg2AIx5xWPE9WQ0djhvZ+AsMmxTe+aLPPvYVX0ITuSVwLOXNWDWfANkCxU4Pe/NUklyHX4hwfixvPsYbP/R0tu9crVZMaO6uWOwNMet7kjZ5Pehf12lVWOEA5EXhfDU+8IPSMmMiTZz3HlEzDu362jt+8Hp8eDUjKomtS/UfIoT2Eo8DD6rFeYYYWhRBOJnhf0df7uGcZH7vfT5B2jrz1jNarIGQgrjX0+FDh/QZ+foPACSXEJQkyJh6EvX7bLw7F6UrAQv9v7CLnVAUmN99rIEnBIf9Y+nBVbG0XyeyEIZOYPt80fUea2q4NtGxaVF2DXSwqkNP9mV72kJz0MUPEdF1v39q4nnkOHRoLdMVE9DfMdU0T0fmj5YGyqgXnnpPzSOknix682T54P2lYDlqD3Lxw6I/k8gU7srW385AWOGlVxzw2OsZdNjBcA9D8W6q6dFMcs9zUx8zwlWwzRv7E8IismgFApQT+jNrGnDTJyfa/ucY/GFH95/ZljAXOne+rJrRATPKPL/7wfqlBTynBi2Dzg7oqiX41YgiWVNcWymPw++zKDPl7INGaUCkLfaFOx7U3ECFqnWVoJs8SCgw6ugx6fF7EJ1u9GbZeAwHh32bROWRDlOyN2XoP6RcD+3TWYyfwR2czkb/26TM0ZEEM6fKGeWBOmRaurNpO5K3IdFiVqM+oB+H0pV5E/DwcgVt/AT2pfoMHaBPTwQLqhmQ9bAyXCduLs0kFRyXPgHrVyjjBJel0XkLQ2Iiivlz0clcS7OKFx66MKiLz9gJM6ZkdZvL66pVlnB47h6nfcg8H3ACHr1pw28LcD2dxLFYb71k6RcROXkIP9zKtmeNJL6jrSh0Y0wiziFM5ezaLT/YVVzPz3OZJym9hJ2BKjKNvwDLXUBUWRwl73UUAIqnNIii9s3fXPU4 DmEU0F40 miLF1GmJMWYYaA8q0IksldbrnFgO/AoXse1GdyneB3uoxqK3DebiB1phBzdlFXZchwOrvFfQ9t+kCVzUxcWcPIyAqbDr5WmD7UdXf1rIDPQz2G/psAKCMN7jtfsEfkhAhlZKjJ2AJ+IYPgN/ryie7xcLkRStdjfoXRSUgJwoty3TtQY5MYq2EHS3qVe+GXGqOkO7fkZosB+YUJhII4nqbMbWXjb2YHHgVnLbhwCsTriZl6hFyiHmWNM5stgxgQWo+NioFZPxivufw+3TGi16iumSKPxZF5oEjcW3WCwSkaYLt6e26N23HPLOTDloqNVnJ+AJwEL7GqL/t0NgNRgD79ZXvcJXluY/1BH64Q4osrtXbGjbtbazaPtYTTA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, David, David Hildenbrand writes: > On 06.09.24 05:07, Huang Ying wrote: >> During developing a kunit test case for region_intersects(), some fake >> resources need to be inserted into iomem_resource. To do that, a >> resource hole needs to be found first in iomem_resource. >> However, alloc_free_mem_region() cannot work for iomem_resource now. >> Because the start address to check cannot be 0 to detect address >> wrapping 0 in gfr_continue(), while iomem_resource.start == 0. To >> make alloc_free_mem_region() works for iomem_resource, gfr_start() is >> changed to avoid to return 0 even if base->start == 0. We don't need >> to check 0 as start address. >> Signed-off-by: "Huang, Ying" >> Cc: Dan Williams >> Cc: David Hildenbrand >> Cc: Davidlohr Bueso >> Cc: Jonathan Cameron >> Cc: Dave Jiang >> Cc: Alison Schofield >> Cc: Vishal Verma >> Cc: Ira Weiny >> Cc: Alistair Popple >> Cc: Andy Shevchenko >> Cc: Bjorn Helgaas >> Cc: Baoquan He >> --- >> kernel/resource.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> diff --git a/kernel/resource.c b/kernel/resource.c >> index 235dc77f8add..035ef16c1a66 100644 >> --- a/kernel/resource.c >> +++ b/kernel/resource.c >> @@ -1873,7 +1873,7 @@ static resource_size_t gfr_start(struct resource *base, resource_size_t size, >> return end - size + 1; >> } >> - return ALIGN(base->start, align); > > You should add a comment here. But I do find what you are doing here > quite confusing. Sure. And sorry for confusing words. > Above you write: "We don't need to check 0 as start address." -- why? > To make the code extra confusing? :) After the change, we will not return "0" from gfr_start(). So we cannot check "0" as start address. And I think nobody need to check "0", so it should be OK to do that. > /* Never return address 0, because XXX. */ > if (!base->start) > retrn align; > return ALIGN(base->start, align); > > > And i still haven't understood XXX. For whom exactly is address 0 a problem? Because the following lines in gfr_continue() /* * In the ascend case be careful that the last increment by * @size did not wrap 0. */ return addr > addr - size && addr <= min_t(resource_size_t, base->end, (1ULL << MAX_PHYSMEM_BITS) - 1); If addr == 0, then addr < addr - size. gfr_continue() will return false, and we will not check any address. >> + return ALIGN(max(base->start, align), align); >> } >> static bool gfr_continue(struct resource *base, resource_size_t >> addr, -- Best Regards, Huang, Ying