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 0C800C74A5B for ; Tue, 21 Mar 2023 07:57:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BE666B0075; Tue, 21 Mar 2023 03:57:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96E886B0078; Tue, 21 Mar 2023 03:57:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8364B6B007B; Tue, 21 Mar 2023 03:57:43 -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 7373A6B0075 for ; Tue, 21 Mar 2023 03:57:43 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 35A8A16107B for ; Tue, 21 Mar 2023 07:57:43 +0000 (UTC) X-FDA: 80592151206.03.A73B7DD Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf30.hostedemail.com (Postfix) with ESMTP id 24B758000A for ; Tue, 21 Mar 2023 07:57:40 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=K0kBe0Un; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=LAmaTyfE; dmarc=none; spf=pass (imf30.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679385461; 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=1q9SltzaNL/CztkM+LEm5N5o8JYoAuWjcQL502qSi0w=; b=iPeROA4DI1aOZ2hbtFvH4h3lvROdXmUM8Rpk50k1BP1xCEhD2kZV1dF+qsS0OjqE+R9728 r9YtnBluOpbumE706orzIS0K5XsRoAvN7w8nJ1eG0IjQlqcWN6PtqIGlHPniXBJYInIm1A IqhBYw23z3QUxwYmOe6ThmJIOnsjZrQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=K0kBe0Un; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=LAmaTyfE; dmarc=none; spf=pass (imf30.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679385461; a=rsa-sha256; cv=none; b=grViclFpm6xoSmjMlH8O6F8zL64x6AKXfjDd8ZlKLyKoTAez/sy4rZfJqT9QvCGYqR6bNK aUDscPHZa4vdE48iWTsbsLGUYaQSYJzwVoDxm0l8NdhbQUOWbeuqCYKJk3yob3Zq2ks0d6 XAwaU3hM0pDOTHKYXO2n72HSni1XAtI= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id F2BFA21A70; Tue, 21 Mar 2023 07:57:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1679385460; h=from:from:reply-to: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; bh=1q9SltzaNL/CztkM+LEm5N5o8JYoAuWjcQL502qSi0w=; b=K0kBe0Un7tE4Cxf+WG+rdePp4x/6z//9O/xOeH9XdEcw4anU+TNkPzIyWaKWz0siSLyLye jZc8L8LJ2kJMBnq949X7XfqTIjrrlAyg4qgAd4e5+HD89NX4uW8RGA3x9v4ecV6hrIiliQ WNlKmBLQ4UBw6hK+HnBVgSEx40xquAw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1679385460; h=from:from:reply-to: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; bh=1q9SltzaNL/CztkM+LEm5N5o8JYoAuWjcQL502qSi0w=; b=LAmaTyfErAm6uEygmOyqEzjKDteTqxKMzkzqWmv18w2U144b0aZxpThEtv02aMUCLGg13Q ZBznbMg1cRMgVtAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C92CA13440; Tue, 21 Mar 2023 07:57:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id VeI9MHNjGWSFOAAAMHmgww (envelope-from ); Tue, 21 Mar 2023 07:57:39 +0000 Message-ID: <71905d5b-9e83-c123-f81b-de595bb06fe0@suse.cz> Date: Tue, 21 Mar 2023 08:57:39 +0100 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: Tvrtko Ursulin , "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , 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> <20230315153855.aeqyxncf3k6yqipl@box> <4be7cbc0-dab5-eecc-1cea-8a6ffb831f10@linux.intel.com> From: Vlastimil Babka In-Reply-To: <4be7cbc0-dab5-eecc-1cea-8a6ffb831f10@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 24B758000A X-Stat-Signature: amxcc9i7teoeap5s5ntgf13jii4nz17w X-HE-Tag: 1679385460-572114 X-HE-Meta: U2FsdGVkX1+ct9+Xphttc84+EpbF0z0ooyryWlikrUWB8946fajagj38d1ZKdc+iCH7OmJ/YAV9DtUGUy8IYMQvT25+P9xA/Hi9/pU6ugYL4mcYnIPSEOc7XN35EG0PEibRkRpM2oJKggnRoKthxvNftKAw14qkyYE+kY3cZ3sQDYh815RNjjdYP0VtnPLXaIWE8aaSSNqB6/UFstrIEGk5VTtsgaKFB0MdrsfpFLs0tBrDzXGTEihLkqarrmmwMsfvKMY1sghdks1sUGNYcu6YRtFdueExviKKCQv6u9TD1iiiZWWcuk2d3IMw+DkttwsbVV8KYoTZ6IhLQWmXq9W9oavY7dYxFHbxnXdYI6jhoqEobwqbcsCTMPucrSrXQnsfN5FrI/ThzHWGRaS/JKkOzPy97jNVir/AkilGGj7n3QGbDp8eb9kl6IOZK4mIBSWStEDH0/3hhU3QUis1XJcTispr6gQfBnrObXshc9IR0lk5V2yOar1KroxfdZa3f1S4tvPutAvyUCJj0O68HC7HXv1u3g+0kSViyW8a1gH2UA4X2xqs35Jk2UV1tyzMN4ybSgYsRndwsOTjQxxp6y7Mc6ZOwJM3muHr9rCjHU/HAduH+5hpW71f3YaOnuuRuJhz8RirWsZQBXH83y53EOnLbKWa0IBszZZSYG912NzB7D0rp2qiaWjDvnp7dr7lTRqBT8IXNgQ9USpihVsPA6nelhECersSK0eMAdp1J+XL1R29JBpTq5bUq39lBYGbUA8KnRi680lzR7wQcBhNSELAOHa5iHDvZ/kJ9UEaE8I3Nlbpd70b2suArncneZsTcaG1iDt4AVVY2ziH2QQkWxl+ybPW6EG6SpL5wJudRqYeAZtSvoWASP0Ciw9LK7pyTKt1NA6BcSWbAdOqIK57pqgTqWTJEZBff//8IpC+AQUsdiD+iRKl8a2Tp6OvyPwJAF3serSnXEUanDiKeHkv 8Bl1hD+j AglEDpXx+lN3Lv3Y1M8/raU6lk365Nk8+OlCMyfE6zz+hsfoFfBWUX6XbdqtksnhXO+FrWdS5tqfQqi/GyA57L+vOjiKgw3OuEKDPYJiSS/087iTAACq38vxwlx9WE0vnS6fn2Z61exQ7/PcZWvasGZvZ2hbVDg2TVp88693WpzMp53wBwHu63F9xhUlL1fL5PN7uYvpU2iWwOk4t+gd1kEQDx2xisdY2x69UY4fWhxMWxa1tp29ZuQX/pm3jyGPH+Ttwyqcd00+Rg81OiM0fPnhbHjOg3xuDaGUOQAMfL7TfTUFxt4FHrINcOWEhgW1O10C300bSTYYSf3V6Q4t4NHDBRw== 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 3/16/23 09:55, Tvrtko Ursulin wrote: > > On 15/03/2023 15:38, Kirill A. Shutemov wrote: >> On Wed, Mar 15, 2023 at 03:35:23PM +0000, Tvrtko Ursulin wrote: >>> >>> 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. >> >> I think would be better to get it via mm tree. > > Ack for that. But as I saw that by the end of the series you also change > this back as you redefine MAX_ORDER to be inclusive you could even > simplify things and just not do anything for i915. I am pretty sure we > never call this helper for > 4M allocations otherwise we would have seen > this warn. I think it's better the Kirill's way as the redefinition patch then isn't also a silent bugfix. In case some of the bugfixes would need to be backported to stable (maybe you don't seen the warn, but something else will change and start seeing it?), it's better if they are separate. > Regards, > > Tvrtko >