From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA966306D5F for ; Fri, 29 Aug 2025 10:06:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756461991; cv=none; b=lg2OWHGIME1A/zduTVEEX4O8vN7IW9kQE2tZhejz27H0Yc8bRL9ihSVqna/q0Ie2WliOQiti0IfzulvoMOsTEEt2BIcEzeremUsPU0N3QEXoKEY2bDg9PYYPu4RyaD7T9wafrCbiDzm2Rw5YEBJgF6JNq2ON3TCTKI2Mi0o5KHc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756461991; c=relaxed/simple; bh=yo0XFtlRucDU3CPmKUauZEk6meUI8I6YEGkEEcyZ+8Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YeOk+uIKR4XDqgxOMFpWVsdofnS27eLYm/WnCrMRo7Tn4Ij2S3YAnILBcQ9xZJreBfZLdCBEMGcxuniZSdSR9If0So3t1hUwFJL7TTuTsPecvUwY5UQqGnDJS4do1o0pO7yEmNrvEbhA71mZHFbpIKUzHreX2RGuFPz4wQFpAhI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=X2NbUJL9; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="X2NbUJL9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1756461988; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=lPHoMHV5vJS1QZV5L+lWiiTGuBUarel82A4quq5C180=; b=X2NbUJL9bJHXuV7eFDPLEXzYckKovoNtSRH8sORqAv9vimX0X32VEDKOIBVPMznGdpXYoO X57JAEYB0QsZo29AZTtUbuLEe8Zyt4Cpo2R9Zdb+zoqlazX3FyyctVla77iDrPmlBWzN4v Mo1p3ap9YvAATSGfXbwpeewFXZTAAQE= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-319-O0HM-yf6OdW00qFxKGRiiw-1; Fri, 29 Aug 2025 06:06:26 -0400 X-MC-Unique: O0HM-yf6OdW00qFxKGRiiw-1 X-Mimecast-MFC-AGG-ID: O0HM-yf6OdW00qFxKGRiiw_1756461985 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-45b7265febdso13075945e9.1 for ; Fri, 29 Aug 2025 03:06:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756461985; x=1757066785; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lPHoMHV5vJS1QZV5L+lWiiTGuBUarel82A4quq5C180=; b=TUvILXKnKgF264mjKYaCnm4zcjFHkzVoHj8eQisflSPgMZk3wL6NYOr5u2dojb8rRD 7ywakUisu4JmYmcoFcXaqzn7WYvc1FSNXSi7R2QRtLqjJ+2zy7V660gZFza4OaJP06JV 0+/HCzgTCPrBLCwCSb8MDGw/SodQ1T+7ijHVUIAtvLrxthlyaKk7YB3O/r1uWI9xgl9L oOBWOC/oK+0MZSHKLXFeJvOHjY9Z/+7HGOtRphbpxEBn2hJZA3iQdj3fnOx39UV0KL4c ZzotOI33jlpYwgaJ5+fj+JlBPs9XZDMBI88FV+isy4kR+5N3hzRDYdtT9YBSNT5/R53I 5RIg== X-Gm-Message-State: AOJu0YzLzcYcIW9GSsSg7PwcwFRLGNfFRVaqYo6avMvHZtL01si0ZDs9 M/06ESXtVtvZa0TxWe6XkD9HTu9lfh4I50dg4bQepagVr2aqvpk9OkdF0st8ui/ZNEmkfPSVRjM LZWWeu9ohO0tesJo9G39/yWp6JroKDOHtyD76AwTb14kZOEG07UxhyjiLlQCoyDJPMmL3rtwdrg == X-Gm-Gg: ASbGncuwPtUa8aKFswQj3+MOwoyYragCbG70zFJ1B6p67lo90oLIRKnDfmyM+AseQNU 2w5YrMJVTjZSM9LkGypWuMQnvTwyz5dvagSAk2tFiALuwFgcEtqudFEf6aS/ZwqpwCpJwMN9aCG EwG8ZLFG0T/wRB8zsIzQPAadPD/mz7mRKkHOfrrpCj9bqJPuWqFphPfQFbxccc516t+SP+rO4PR HPDSBr/IaOYfhLqB0xil9Eaj7tP3Cpcv5HYnzfV3BF5xNZ4R9Gm5p5Ns4MhY1STIuHvhz3BVtEE S8sKou8Xar+l6aoHbRl5HqH6/Fg6bm35UthZthkinw8bPCVNasU8dvZHcKGgauj8ftbboj+Ge4k 2vaTFEX4iuc9ix4ZZgoci1liJay/nDK2rVZKsYFZU0EZ+5DOucz74DHdA7e5IDvLm X-Received: by 2002:a05:6000:2082:b0:3ce:663a:c92f with SMTP id ffacd0b85a97d-3ce663af648mr3716805f8f.25.1756461984496; Fri, 29 Aug 2025 03:06:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG+cEIb1Z4u6pTtqsfT89DbTAZZhLHMJCnkgKmDWXX/Q7MNQLWv1cM4WZiGdQoi1AW0dJ7LMQ== X-Received: by 2002:a05:6000:2082:b0:3ce:663a:c92f with SMTP id ffacd0b85a97d-3ce663af648mr3716770f8f.25.1756461983963; Fri, 29 Aug 2025 03:06:23 -0700 (PDT) Received: from ?IPV6:2003:d8:2f1d:100:4f8e:bb13:c3c7:f854? (p200300d82f1d01004f8ebb13c3c7f854.dip0.t-ipconnect.de. [2003:d8:2f1d:100:4f8e:bb13:c3c7:f854]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b74950639sm85846585e9.17.2025.08.29.03.06.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Aug 2025 03:06:23 -0700 (PDT) Message-ID: <547145e0-9b0e-40ca-8201-e94cc5d19356@redhat.com> Date: Fri, 29 Aug 2025 12:06:21 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 06/36] mm/page_alloc: reject unreasonable folio/compound page sizes in alloc_contig_range_noprof() To: Lorenzo Stoakes Cc: linux-kernel@vger.kernel.org, Zi Yan , SeongJae Park , Alexander Potapenko , Andrew Morton , Brendan Jackman , Christoph Lameter , Dennis Zhou , Dmitry Vyukov , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, iommu@lists.linux.dev, io-uring@vger.kernel.org, Jason Gunthorpe , Jens Axboe , Johannes Weiner , John Hubbard , kasan-dev@googlegroups.com, kvm@vger.kernel.org, "Liam R. Howlett" , Linus Torvalds , linux-arm-kernel@axis.com, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-ide@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mips@vger.kernel.org, linux-mmc@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, Marco Elver , Marek Szyprowski , Michal Hocko , Mike Rapoport , Muchun Song , netdev@vger.kernel.org, Oscar Salvador , Peter Xu , Robin Murphy , Suren Baghdasaryan , Tejun Heo , virtualization@lists.linux.dev, Vlastimil Babka , wireguard@lists.zx2c4.com, x86@kernel.org References: <20250827220141.262669-1-david@redhat.com> <20250827220141.262669-7-david@redhat.com> From: David Hildenbrand Content-Language: en-US Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZoEEwEIAEQCGwMCF4ACGQEFCwkIBwICIgIG FQoJCAsCBBYCAwECHgcWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaJzangUJJlgIpAAKCRBN 3hD3AP+DWhAxD/9wcL0A+2rtaAmutaKTfxhTP0b4AAp1r/eLxjrbfbCCmh4pqzBhmSX/4z11 opn2KqcOsueRF1t2ENLOWzQu3Roiny2HOU7DajqB4dm1BVMaXQya5ae2ghzlJN9SIoopTWlR 0Af3hPj5E2PYvQhlcqeoehKlBo9rROJv/rjmr2x0yOM8qeTroH/ZzNlCtJ56AsE6Tvl+r7cW 3x7/Jq5WvWeudKrhFh7/yQ7eRvHCjd9bBrZTlgAfiHmX9AnCCPRPpNGNedV9Yty2Jnxhfmbv Pw37LA/jef8zlCDyUh2KCU1xVEOWqg15o1RtTyGV1nXV2O/mfuQJud5vIgzBvHhypc3p6VZJ lEf8YmT+Ol5P7SfCs5/uGdWUYQEMqOlg6w9R4Pe8d+mk8KGvfE9/zTwGg0nRgKqlQXrWRERv cuEwQbridlPAoQHrFWtwpgYMXx2TaZ3sihcIPo9uU5eBs0rf4mOERY75SK+Ekayv2ucTfjxr Kf014py2aoRJHuvy85ee/zIyLmve5hngZTTe3Wg3TInT9UTFzTPhItam6dZ1xqdTGHZYGU0O otRHcwLGt470grdiob6PfVTXoHlBvkWRadMhSuG4RORCDpq89vu5QralFNIf3EysNohoFy2A LYg2/D53xbU/aa4DDzBb5b1Rkg/udO1gZocVQWrDh6I2K3+cCs7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 28.08.25 16:37, Lorenzo Stoakes wrote: > On Thu, Aug 28, 2025 at 12:01:10AM +0200, David Hildenbrand wrote: >> Let's reject them early, which in turn makes folio_alloc_gigantic() reject >> them properly. >> >> To avoid converting from order to nr_pages, let's just add MAX_FOLIO_ORDER >> and calculate MAX_FOLIO_NR_PAGES based on that. >> >> Reviewed-by: Zi Yan >> Acked-by: SeongJae Park >> Signed-off-by: David Hildenbrand > > Some nits, but overall LGTM so: > > Reviewed-by: Lorenzo Stoakes > >> --- >> include/linux/mm.h | 6 ++++-- >> mm/page_alloc.c | 5 ++++- >> 2 files changed, 8 insertions(+), 3 deletions(-) >> >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index 00c8a54127d37..77737cbf2216a 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -2055,11 +2055,13 @@ static inline long folio_nr_pages(const struct folio *folio) >> >> /* Only hugetlbfs can allocate folios larger than MAX_ORDER */ >> #ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE >> -#define MAX_FOLIO_NR_PAGES (1UL << PUD_ORDER) >> +#define MAX_FOLIO_ORDER PUD_ORDER >> #else >> -#define MAX_FOLIO_NR_PAGES MAX_ORDER_NR_PAGES >> +#define MAX_FOLIO_ORDER MAX_PAGE_ORDER >> #endif >> >> +#define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER) > > BIT()? I don't think we want to use BIT whenever we convert from order -> folio -- which is why we also don't do that in other code. BIT() is nice in the context of flags and bitmaps, but not really in the context of converting orders to pages. One could argue that maybe one would want a order_to_pages() helper (that could use BIT() internally), but I am certainly not someone that would suggest that at this point ... :) > >> + >> /* >> * compound_nr() returns the number of pages in this potentially compound >> * page. compound_nr() can be called on a tail page, and is defined to >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index baead29b3e67b..426bc404b80cc 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -6833,6 +6833,7 @@ static int __alloc_contig_verify_gfp_mask(gfp_t gfp_mask, gfp_t *gfp_cc_mask) >> int alloc_contig_range_noprof(unsigned long start, unsigned long end, >> acr_flags_t alloc_flags, gfp_t gfp_mask) >> { >> + const unsigned int order = ilog2(end - start); >> unsigned long outer_start, outer_end; >> int ret = 0; >> >> @@ -6850,6 +6851,9 @@ int alloc_contig_range_noprof(unsigned long start, unsigned long end, >> PB_ISOLATE_MODE_CMA_ALLOC : >> PB_ISOLATE_MODE_OTHER; >> >> + if (WARN_ON_ONCE((gfp_mask & __GFP_COMP) && order > MAX_FOLIO_ORDER)) >> + return -EINVAL; > > Possibly not worth it for a one off, but be nice to have this as a helper function, like: > > static bool is_valid_order(gfp_t gfp_mask, unsigned int order) > { > return !(gfp_mask & __GFP_COMP) || order <= MAX_FOLIO_ORDER; > } > > Then makes this: > > if (WARN_ON_ONCE(!is_valid_order(gfp_mask, order))) > return -EINVAL; > > Kinda self-documenting! I don't like it -- especially forwarding __GFP_COMP. is_valid_folio_order() to wrap the order check? Also not sure. So I'll leave it as is I think. Thanks for all the review! -- Cheers David / dhildenb