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 DB8FACDB482 for ; Tue, 17 Oct 2023 10:46:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35ACE8D000F; Tue, 17 Oct 2023 06:46:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30A288D000C; Tue, 17 Oct 2023 06:46:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F8528D000F; Tue, 17 Oct 2023 06:46:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0DC558D000C for ; Tue, 17 Oct 2023 06:46:43 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9A7A74103D for ; Tue, 17 Oct 2023 10:46:42 +0000 (UTC) X-FDA: 81354625044.14.2ABC7B8 Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by imf25.hostedemail.com (Postfix) with ESMTP id 70046A000E for ; Tue, 17 Oct 2023 10:46:40 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=ucw.cz header.s=gen1 header.b=r0HGqmvv; spf=pass (imf25.hostedemail.com: domain of pavel@ucw.cz designates 46.255.230.98 as permitted sender) smtp.mailfrom=pavel@ucw.cz; dmarc=pass (policy=none) header.from=ucw.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697539601; 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=m671g35jVHurr8wOcj+WlvlYKhYnYhlvUxsN6VNvRGY=; b=U2DFedOB3P+mTelK+gFCPMliNUX8dbFlIohfYTEXbqs/0Rgc1QyTOFJ4zc/he7p7KMGpEb 1PKFlcw7hsbQbewz56RNl+93h7KReYZYDowl2X1WlYbw5FxYJi/TnCcN/e8aI4L5AoADKl NqRtwibwasREJEFTFkqf1oFf9f3AIEM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697539601; a=rsa-sha256; cv=none; b=O106NkTEWXB1JAa1ohAPcmS4r1UVa/GVfwyfGfsfnqMjY+4N8ozbM+eLSnsQ/8BzR8Sf2Z zTue/4Cq7jVTVCWutcwb7p7BiiovPxn2lAE//41eRRlsTyL2YCFNJkOqlmDNObhveEgeLy oViaDSG7c1TeH9SiYn3rne69pVjdmMA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=ucw.cz header.s=gen1 header.b=r0HGqmvv; spf=pass (imf25.hostedemail.com: domain of pavel@ucw.cz designates 46.255.230.98 as permitted sender) smtp.mailfrom=pavel@ucw.cz; dmarc=pass (policy=none) header.from=ucw.cz Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 59C431C006A; Tue, 17 Oct 2023 12:46:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1697539597; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m671g35jVHurr8wOcj+WlvlYKhYnYhlvUxsN6VNvRGY=; b=r0HGqmvvNd5g7CMrbD4jPXD4pgEr6r1Gm6it6Yn8e+jW1rZb4R31EB/0rxa/Ub2tjKQADj GRrPxQw0JGiR3agauWaIPg7A95d06Vso54rp2fJU8pY/eMGv2az94kcMMbS3XZrbhFkUm0 Vw2I4WKWfM46jsXvzxoxKX1AHMG8KR0= Date: Tue, 17 Oct 2023 12:46:36 +0200 From: Pavel Machek To: Paolo Bonzini Cc: Mikulas Patocka , "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , Vlastimil Babka , David Hildenbrand , quic_jhugo@quicinc.com, snitzer@kernel.org, dm , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/10] Fix confusion around MAX_ORDER Message-ID: References: <20230315113133.11326-1-kirill.shutemov@linux.intel.com> <3c25ec6f-cd33-9445-a76f-6ec2c30755f5@redhat.com> <86e7f97a-ac6b-873d-93b2-1121a464989a@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U9ipWO248TbRr+D3" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 70046A000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ggujnfomws19dpigu4btpsfqzqr9s194 X-HE-Tag: 1697539600-654214 X-HE-Meta: U2FsdGVkX18JU+XZOBgN8WdNu6LkhmKtgxR5xR3wDYWSrfsJRQvrKq0Q7pfzJc4nnnmqArgL/Nm7wwJkEr4JvICCLGA2tarD1PsiZFkvyz+JXkk/G+8k5v7RuY490cSnBrfemJ4MfZw79KVhqHc+nxug1747ec1Q+WrzINCvWF2fmn907UPXpWZOHl++T3ER4Fcj4OxNZV3Px2/Ka+KJwVQImAUqx9lhHCL83nDOKOr6J+3K5l+RazWsxmtRJ2GB/xGnUP7RvOHM7Ihiq3sWCDiYknL47EKg/6ar0Q3gzLJPMA39wBXQQm54utIPhynYNx4KlJs0poaOP1g8tOCUCafwLM7IDdqxHpIj6jrHyEnZlXKrIyWUt9TpVDNvyCuPA9LyHRTxrc9pxrZuMIjtKK4Oo5YIoG1sAzTmBfKWbya/KtZ5kjhAKcxHKr71/9S0QvhyI7cjEnijmWwWpHVYaqHRj4VBDnqIiRXyvbME/TBSzuRpCxgkZa/vn6MNkwrwHFzLefoTnulMWP1ZYn603E2NfmxRQGq3NdxXKG4onFk/VQqpn/QSAFsNVtXACRtgd5fYQGNCQoeP+pN1yeBk1NjVEkUzGNYsVjqbTopnBeztn2hlhL29eqTR9h2Bov4xlKJYqn3wWJpwrs3TvnHCMXueD1pFcRxSM68WHlOmQ6R6j8fK15NNMM4b5cAaLry99B+V2QzvlnQdXHpZf3xdBqehkNWsCumkVv5IkpkGOMUOOfbyAaQmVQzw0BUMafHLMkIwdzba8aJly+U3Jyi7jC/WxI2KpDOQXZOddYXx6otpbfu2KL7NaBS4uNoGQdEZ4v1DZS+yare5GE8jwD/ZlohoxgxKgIP0pPzk8Vf+F6nIPaiE6SHyo3fdsPXibzT+0nuhRtJCYvVfYnTDHpyiTTsXp6VOxxEt71SK3NwGSpb2SuaitLvDK+C0AMvSwFMqLo1kyFCYhQFhQOgtQWR 8/gSD9/e FGRttX6v6L/rsRd/M5MkUfcfDYQ1nIMK+Vd6QUz5M3Zb7Wa05rsvxLFGBq3rTVOJAmQtzXfB/8Ceo3gQ8730Azj7KXKORZfphTFwEiPu/TfeGo35rZEnx0tIzUKzw3gDCa68vGYx+zfnPxMjxBFc9w6FWw21eRwMvBxl0PsMFXVLEVSMhOvz1wey3+mFWsRRObvu1SwyzSTy7kgkJoRUf3vpZlw/sRqsADlJRA1iH+17qxYkhPEseIuXjxFdBWjazyOE1 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: --U9ipWO248TbRr+D3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu 2023-09-28 18:57:18, Paolo Bonzini wrote: > On 9/28/23 09:50, Mikulas Patocka wrote: > > > > Fix the bugs and then change the definition of MAX_ORDER to be > > > > inclusive: the range of orders user can ask from buddy allocator is > > > > 0..MAX_ORDER now. > > I think that exclusive MAX_ORDER is more intuitive in the C language - > > i.e. if you write "for (i =3D 0; i < MAX_ORDER; i++)", you are supposed= to > > loop over all allowed values. If you declare an array "void > > *array[MAX_ORDER];" you are supposed to hold a value for each allowed > > order. > >=20 > > Pascal has for loops and array dimensions with inclusive ranges - and it > > is more prone to off-by-one errors. >=20 > I agree it's somewhat confusing either way but the ship has sailed, the > patch has been included in Linux for several months. Just make sure people don't backport it to stable. Fixes: (the commit that causes the semantic change) should do the trick. BR, Pavel --=20 People of Russia, stop Putin before his war on Ukraine escalates. --U9ipWO248TbRr+D3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCZS5mDAAKCRAw5/Bqldv6 8tIGAJsFJix/mB5VZ3yp+Ypy6TLK4hgW0QCfcfJ3sDGET1Vosz3XWgzgTqljj6A= =mKaU -----END PGP SIGNATURE----- --U9ipWO248TbRr+D3--