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 C3EEAC27C53 for ; Sun, 9 Jun 2024 21:03:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 363E76B0083; Sun, 9 Jun 2024 17:03:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 313F26B0085; Sun, 9 Jun 2024 17:03:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 202AE6B0088; Sun, 9 Jun 2024 17:03:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 01BCA6B0083 for ; Sun, 9 Jun 2024 17:03:49 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 73335C09C1 for ; Sun, 9 Jun 2024 21:03:49 +0000 (UTC) X-FDA: 82212576978.12.173AE6F Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf14.hostedemail.com (Postfix) with ESMTP id 1B120100008 for ; Sun, 9 Jun 2024 21:03:46 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=SBXq32p6; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717967027; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VdH4R7x9GIdAunxCk7uhIduQj7ZfYo4O9UETRYwJbE4=; b=mwvyFTtzXDVSmGSgOpaWmkYlNvWImU4HbRM0cnt00w762sW55Nob+uavBaUw29fkAuGFO9 bclZ3bBWWlDIV7dACCMlS/K8+RryyhWSoesnLslEyj6iDGINtbVvRp13lvlop5YKCf0V9Y 244jQ4n4B31prDErz7VV3a7OtHirkHc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717967027; a=rsa-sha256; cv=none; b=467P/ih5MtCvsE5YrPZ/hm8cgS6+we/lnef4mY8mSJV6TXUQH9mF9t3YCkfgfaNntn0u4V zOGaKY066WbqDHWSWCGYomPipsheruB6ZaCWIRb6T1dRNuihTLzq+EUGd9hVG6Otje4uuG OkLnslIYwJduGmclOva+5YfmYSpKltE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=SBXq32p6; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 5BC23CE0EDE; Sun, 9 Jun 2024 21:03:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A9DDC2BD10; Sun, 9 Jun 2024 21:03:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1717967022; bh=snGphHJUe+ClJG+1JDmteR989lcPQOPpXI409fVQX/k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SBXq32p6H/7ickhuNrFoO3gEgYoIeQr/pyGqeAlzxFbLQs0dYYgvFWKSlKBAmWrNW tAQAhRjTr7ccttDKE4J431j2piTjr3rapCyiYmk8guXH/h5Fm464h+l7JwRXF899D9 M8Qxasm9kxcjCRR8T+iPNYtCo/ZPzpWPxDbaocpM= Date: Sun, 9 Jun 2024 14:03:41 -0700 From: Andrew Morton To: Leesoo Ahn Cc: Leesoo Ahn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Rapoport Subject: Re: [PATCH] mm: sparse: clarify a variable name and its value Message-Id: <20240609140341.14ba3a1c62029771d60059ed@linux-foundation.org> In-Reply-To: <20240608152114.867961-1-lsahn@wewakecorp.com> References: <20240608152114.867961-1-lsahn@wewakecorp.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: yoxbnegy8wf1w5qrt1x41hw36nwc4wmq X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1B120100008 X-HE-Tag: 1717967026-551270 X-HE-Meta: U2FsdGVkX195aDqL5ZiEATT2C5nojqV5TayL8YJacEYtU6px18TkOoQQ+JMBfmoQcKyc5UL8C6YEEjVDE922D1krYm4k8k5Nvh3HxMX4a3f9jqzfDsoue7m5eZ7tEsHaDJiggKthRNE3p+Q5vELeL+QvQweTKnKzGPmvlhyCc/HGw/GzN1Pv2pKv0tHUzNIBFKnTtDxt/gaTHtPcR7q76Ty6lLpc9jUu1zaWki/DfZ3mlSsFpkv0OvWVBOigQr8X26zrRMuSdI4AcpDhta7LcpltkmX5CApUBvK3somyQvCQxnbdy0Qr00ivBMUBrWJykcZ9H34C5dZqgWzrC7dmq71a+4vqejs8ar1I5LmFr25sjlsJDHWvMJ9A6mJc6jAcom0lkMDmwXLgzl1zv/aU+0fHgB3yoj7qDmTX7qSVYQP7CE/jvTWkNgb/25UIx7iXEKvM58M868gd5k3TPwbPny0Fyn+aAy97+46btV862k6oCVOjJh9eJ512WAa+hY/3cOhD3dVqFiddLBPpjiH3EQiYVVEC8BZ1qoekoVUjqsEbWvsEQu0+tCPobj4Wt/t9e3dn0NOIxinJx1O9NvQ0VQxAlDNGBBONMfW8HOX7IJwWyTP+gHp2MU5ryX5yztVAQ1Mn9ODyXvxN9MaELZagIXbNVSjz6ey+VN01EFqcMkr61LuK4oDnuORo+BOYGZOrmGC6hd96iNxLwOEFJdNTP0D3dZxPYdK+9d6alsFg9HjXoSuh+yfI1a64/XQNkqNYyFyWmaKLO92mszgaPUuTRPTgeDGwl/osbXeV17RjxacGl83lnN41fVrMB0brf+3VT+jVmmx49aDQB3/+zQxRDdm16qj1wVb6HxLqtLDRYkDzqndCWK016j/xdg9QLUatVrEyvAF7CRem+OrdcIl3G8OGCxp0e3hZpyDyNsG8cZZesAw/gi+fBtWlrcpNKfL8Hch/ehlVmFiLjrJFs5s B+LLGMbq 4QfERRP3nj+Dx8/sCTJgTRwOv9vbVhXVmLISmRZlrlMNpPHqsVzJPEakm4NhmjDiqRceaTp8cW478+wr7rCtfDxI5PuLr7JuRqSiYrQrPRqzEW492aEfMb3uxUSZzJFhN/bfrvLgYApue3rPQqvNAlo8Ei4c1yVLjd9sTjW7REwa8Szn8wyyOtAaG5FQubP0+sak1nyr+z60r6cfXzxqNcShehhIQSpRL3IQhRXP/k19buc5HmbwWXjNKm1+KeaQx/lyqkMfwyO9Kv5Tne2Gd9JixMA== 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: On Sun, 9 Jun 2024 00:21:14 +0900 Leesoo Ahn wrote: > Setting 'limit' variable to 0 might seem like it means "no limit". But > in the memblock API, 0 actually means the 'MEMBLOCK_ALLOC_ACCESSIBLE' > enum, which limits the physical address range based on > 'memblock.current_limit'. This can be confusing. Does it? From my reading, this meaning applies to the range end address, in memblock_find_in_range_node()? If your interpretation is correct, this should be documented in the relevant memblock kerneldoc. > To make things clearer, I suggest renaming the variable to > 'limit_or_flag'. This name shows that the variable can either be a > number for limits or an enum for a flag. This way, readers will easily > understand what kind of value is being passed to the memblock API and > how it works without needing to look into the API details. > I think I'll cc Mike and run away ;)