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 438EFC61DA4 for ; Wed, 15 Mar 2023 15:35:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD3966B0071; Wed, 15 Mar 2023 11:35:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A82866B0072; Wed, 15 Mar 2023 11:35:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 923006B0075; Wed, 15 Mar 2023 11:35:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7F9B96B0071 for ; Wed, 15 Mar 2023 11:35:36 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 534D7A112B for ; Wed, 15 Mar 2023 15:35:36 +0000 (UTC) X-FDA: 80571532272.15.626E073 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf28.hostedemail.com (Postfix) with ESMTP id C8569C0017 for ; Wed, 15 Mar 2023 15:35:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BuKYIVU2; spf=none (imf28.hostedemail.com: domain of tvrtko.ursulin@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=tvrtko.ursulin@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678894534; 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=Av9XChFuyfF5EosjhRZjIwrJsrjWCwxzDRlLeX2tAtA=; b=Pe3XkUmJDuxAkyi8I2BPAfFD5hksKG1rm0VE36Zf73+GYH4m8bwJ2n0TjNhGpn+j6RIPze uWmxZkjpbwf+rUCsgwycAdhigWJmMH7EJLPw2wHLBPs6rQWAdYQLeruTyr37w9KmnymdhE d0s+YeZxhAf0ZJbJQODOC4GumQittsU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BuKYIVU2; spf=none (imf28.hostedemail.com: domain of tvrtko.ursulin@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=tvrtko.ursulin@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678894534; a=rsa-sha256; cv=none; b=BadII9XnNkFJnSnj0BqWlC+AfAZyATyKJNG5xTh46Jfb2C8navzYVIDba2YUzmUIBMhzZ7 WJLhUjeb0rLwHQu684wzDpIeSek6yG6DR7fXYOV7YNhYVStsy9egexjv6h3vciZ5SwBun9 pJo90pmVnEvlliKeOdK63ukhxCQgZ98= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678894533; x=1710430533; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=XVCvNq00AzxeDiW1CII0hPanv823+0JJywCY93Le2ww=; b=BuKYIVU2ACFVPmD6WIOnWMSNUYWD8PkqBk8CUjK2s5gHv1iUlR4aDo8T zzh8f2zv/FccxjaZhC0qgiCSYepVoW0CKBJRETYDTMf2ErwG9c18EHF8Q mjaAiE6jnWpf/yICxz/whNZ4h9tILYcGMxN70Jf0SpV1MRGXFRN3onSpq 2P/24+eEch5cuKCiFOhoP41MZjdtpvrOeW8ihZOAOSUX5E6A6AWBD6rmJ QTxrIf9Ht3a8gEsh1aUVvzYHKLoCTibuXHKMdmX9RIB0KEfyjULA3wZa7 yjath/nZenO1FRF7mXRYat9o5s+kqFDC5rByoAwgplhs1oFLrsOLI+oXi w==; X-IronPort-AV: E=McAfee;i="6500,9779,10650"; a="365422305" X-IronPort-AV: E=Sophos;i="5.98,262,1673942400"; d="scan'208";a="365422305" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 08:35:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10650"; a="1008877812" X-IronPort-AV: E=Sophos;i="5.98,262,1673942400"; d="scan'208";a="1008877812" Received: from rhdahlex-mobl2.amr.corp.intel.com (HELO [10.212.59.168]) ([10.212.59.168]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 08:35:25 -0700 Message-ID: Date: Wed, 15 Mar 2023 15:35:23 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 04/10] drm/i915: Fix MAX_ORDER usage in i915_gem_object_get_pages_internal() Content-Language: en-US To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , Vlastimil Babka , David Hildenbrand , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi References: <20230315113133.11326-1-kirill.shutemov@linux.intel.com> <20230315113133.11326-5-kirill.shutemov@linux.intel.com> <7fe9a4a0-9b30-38db-e739-1dc1f7a8f74e@linux.intel.com> <20230315152802.gr2olzji5zhu6vdo@box> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: <20230315152802.gr2olzji5zhu6vdo@box> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C8569C0017 X-Stat-Signature: r4kxjji6r1qcdaarbcir7nx7pxamrinq X-HE-Tag: 1678894533-524702 X-HE-Meta: U2FsdGVkX18xrlMIeVgpsdPs2e40/FRtZn/9BYL4azbnYhJTJpvqGpQNUMF9ezay+gMjLxIfj4S+7ACitk7DxPiR0Ze9puZsaEzAK5J161sIMM8FB9b3lVYsqBvLNFqn42ftE8bdzqYupfArjCqUL/u5scAgufXAQqneFARrwvMbd1qfEx1YpNdlrqRBqBi3kO45edwybIbwbsVb4kWUq2Sy9SJiiWxvY5eSD8oAxmVFNTCvcODAUSbrQKMAuGzhdOM88ppRu8hEl9gMUKPxz1ymS6rWQOtYDM10wzgBVDa++4oPJW4TBGH3ESIbk7oxl2q4imEczSGNLAKxwQvPPqevTY56b3A869cq8/E58GNkCvmXNqUMkye+5f7s6YjqpiTY0GNtZuk6Di1Ntb4aANVofVwNvxtL1zeuSjJt03nropA2pTum4exp9iRcShp0L+/ejTGac5UmIHzjU3EUC7tkY7btOha+pT21k5F7xrRuVaJY9Ggk5Z7xshKJWbSPIggGrm6RlptUHfBQcfBfSdUyx8LZMWCaeTntZmssvTh7cplnKXDC/7377skKsPfLFX94BLzrcbGh/mR02rh33PmVXxUptAjz73FHWjL/J5ZJh2ywD/1Qw4MlLwaWPbKQChenvHWiKpQgXfRLGcdgyflN1kns7lG+8rkt3BjTehstpTqxpV6MLun+hZbiJzlrvZ4BPA4YiDx5GqiMVPKHHgumk0ZV5gsUnLNjI1143hN+//xy8dF6Q5xGsEzSC1u2g16CCTnxMWasMqkWloAdNHGwJ2/lLo1+bRmPQVK2e3PbGKiGFALM2p/LCnfkyGzvZMZWQSuxUZ5NFQXOHLWFHbmCPRE2sug1s3z/Xt+Ero0oCXNiNiT1oeS3UEnyAZoDut4cno0EgJDCkMQ327vPDKMd2jMhIIqoMFz2KPqn5diXTZA78VAxd4lkeneojxHZF2qvFrIdqCGOeSdZOGn kmvPFsUq UwxTuVD8CBn3pFYqrAVvoh/mcp+6IZh0AnWN2MdKuwhzlabb/3X2r7WkNLxl7Zf/8uXPDzHgcQ3FoEj39tXAOGnaYYaq/NdXPn3in9ZYeUHFdtEjjfpxSs4p37FWxLJKcIbNoQhaUNPwxkEO7GbfVx/P9supox48XE/xQR5OuCxgNPVub9pJjkQlh+pObqlz0RTZ6kKEfIqOU68P8twoQssHkRGizOrivO3qE64ISpYiqgXnIwlPqWNyrc22T+60DOr6LMNjvvDskJtPrYFR0N25GSRq1UKEa4SWWqITPr6ljGBbFsm6sYYukxg== 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: On 15/03/2023 15:28, Kirill A. Shutemov wrote: > On Wed, Mar 15, 2023 at 02:18:52PM +0000, Tvrtko Ursulin wrote: >> >> On 15/03/2023 11:31, Kirill A. Shutemov wrote: >>> MAX_ORDER is not inclusive: the maximum allocation order buddy allocator >>> can deliver is MAX_ORDER-1. >> >> This looks to be true on inspection: >> >> __alloc_pages(): >> .. >> if (WARN_ON_ONCE_GFP(order >= MAX_ORDER, gfp)) >> >> So a bit of a misleading name "max".. For the i915 patch: >> >> Acked-by: Tvrtko Ursulin >> >> I don't however see the whole series to understand the context, or how you >> want to handle the individual patches. Is it a tree wide cleanup of the same >> mistake? > > The whole patchset can be seen here: > > https://lore.kernel.org/all/20230315113133.11326-1-kirill.shutemov@linux.intel.com/ > > The idea is to fix all MAX_ORDER bugs first and then re-define MAX_ORDER > more sensibly. Sounds good. Would you like i915 to take this patch or you will be bringing the whole lot via some other route? Former is okay and latter should also be fine for i915 since I don't envisage any conflicts here. Regards, Tvrtko