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 A4CF6C369AB for ; Sat, 19 Apr 2025 00:55:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4EC7B6B0006; Fri, 18 Apr 2025 20:55:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49DD26B0007; Fri, 18 Apr 2025 20:55:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 364F36B0008; Fri, 18 Apr 2025 20:55:30 -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 181796B0006 for ; Fri, 18 Apr 2025 20:55:30 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1D476BE5A2 for ; Sat, 19 Apr 2025 00:55:30 +0000 (UTC) X-FDA: 83348975220.27.5F992B8 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf29.hostedemail.com (Postfix) with ESMTP id 0A11F120008 for ; Sat, 19 Apr 2025 00:55:26 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745024128; a=rsa-sha256; cv=none; b=eg9VFzdRkgllxW0YO9eWsRJKGzR7dPUsvWE+aeFK60FFAnvfK92w20oRpTyFKp8TOC5mmj V9Wy56fRHDg6SxeEBnmD1BNOA6oh2mf7Hj+TrrX7syRezR3dwf11N1rgvFb+Rk2+1T/nx1 9vlaUrU2uVR89zkmt3ZrsGTvNpoItbg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745024128; 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; bh=xQXRtXyrp0txtwaWLS78pF1fMSrmLRryljxY2YsZRIU=; b=RYfIpv35R2exRcuu2q0tEc1q1nW3jMbhNMVUTkPt3yn8RQ/9dZFcofiZbQcHJekY9VQyoj YrAeE9fx0NIsq0ojj6Q9Ivz0Zo1QAe6RSHmXKZ5yTDdi2Szp8Ez3rGVngueY1W92XN7E1H U+I7RukMY6wRod3yhymLHFmFCxDo5ts= Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4ZfY3n2FrJz5vMB; Sat, 19 Apr 2025 08:51:33 +0800 (CST) Received: from kwepemo200002.china.huawei.com (unknown [7.202.195.209]) by mail.maildlp.com (Postfix) with ESMTPS id ADCB6140156; Sat, 19 Apr 2025 08:55:22 +0800 (CST) Received: from [10.174.179.13] (10.174.179.13) by kwepemo200002.china.huawei.com (7.202.195.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 19 Apr 2025 08:54:39 +0800 Message-ID: Date: Sat, 19 Apr 2025 08:54:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] mm/contig_alloc: fix alloc_contig_range when __GFP_COMP and order < MAX_ORDER To: Zi Yan , Andrew Morton CC: , , , , References: <20250312084705.2938220-1-tujinjiang@huawei.com> <20250417195935.2ac19ac5f92add5931b6fa5a@linux-foundation.org> <6E553AA1-5B53-4E52-9940-3B8E0DE36FC1@nvidia.com> From: Jinjiang Tu In-Reply-To: <6E553AA1-5B53-4E52-9940-3B8E0DE36FC1@nvidia.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.13] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemo200002.china.huawei.com (7.202.195.209) X-Rspamd-Queue-Id: 0A11F120008 X-Stat-Signature: dfe51uce8cmcygo9w5y8gka3pnwtqysb X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1745024126-465243 X-HE-Meta: U2FsdGVkX1/nVATlDpEcGI2Cz3QdiEid9AJ+TkKsKrn4E2jutCsMchFCZSUgdKIxlKvdJR8LaOeAhRSPGvczrw8g9Sa/JZY5jWlA5JvFK4SKwssrt/7eEvgHTZ82IRiyyf37QM1XBIWS9gt6oN5llcETjkg9FYd0gA/9rFHrniVFdWgiBS34wwX+pK+FNzZcRyul5INbLrOrIiyoRZXMygRcxMdzCThtSqPiNnmSQOY1k052zrpUP0+oYyrbfrq9LF9CINb1wMslIAm9X5PIQfW3MlRVKVEhC/6G9jE9GmVHy41ljvKrZblJ+D/cAu2okR8tb04TxjbVPOItS34shZ+tvRlEbd+MUnRCH15mL0y7dgE3ZofiYrvujq7L5cvnid9X3uLNBHok7V+8EvfIdUUG4lmsrLFQj3tY9L+WSWgGX0HxtzwItplrhkVcNJzE9Mub/6KDay5IC8u0JJ9Lx5A6Mf29m0qpUFFgECEhe5cozCm99gl2o1MeYMMehG4iFtVfTODsZoz4D7ym3gRRi+aeEMYLUteBSfFfe36aMJ1+f51gZ5IUaK+/SeyJAjbeRJdXpxAUA0N0+OJrfx28JE8Pv9/oLb/YXzLUAz5AxMVyVQmQRfCUieRbU65ksGi5lIffpXtjEcE4syKYXBbE5mG8CZU/Bfon7gHzqVy7EAPO6Gvu0eKNYXJOr/zUo2t6ZFhMOECP/MJrioeOIgXPkr4dJJv2G8etFVoem1EMrWFfpBKLGBmdCGWAZo1fydAAvRFyMa77wIvU7HtOF/XTctAikgA/3OReAJeT6cUqu1nlOLhFJCFEeFYNCXhpbuhbiCMoaGvOaILG7y0otqrgBDrlUidd1jhWzbM41D1diBYQl5HcI86AOXFR+Zy5pIvxFx8/mUi3e5F1zc66wiWj9Ki+tH5bJX8eWIxzCRUB0sk9oPlRoaLrEYXDiwcEe7FgD3NPqFlIsNTSBJtPtIW p7gbbL8S AAzzGunFRe+YUSEpz/OU1JwKCLTM4EOPZvMce/kFcwwfR1IlUtEKsVfF69HbijM4GSfMmVBehADnBSBDJzFk7izipWWNzWESSWcrpuPYZ1zOgmYHyiReK/Xe/rmPoM9+HVuiz1uIIbTwl0R1C7hkVimUA/3FOE09ciUtsd3G96BiqI7d3iWrEk/0OlazevCR0DJXZZtXdLUBefhRMROgKmwiCGCgpqKxzTPAl 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: 在 2025/4/19 5:32, Zi Yan 写道: > Hi Jinjiang, > > On 17 Apr 2025, at 22:59, Andrew Morton wrote: > >> On Wed, 12 Mar 2025 16:47:05 +0800 Jinjiang Tu wrote: >> >>> When calling alloc_contig_range() with __GFP_COMP and the order of >>> requested pfn range is pageblock_order, less than MAX_ORDER, I triggered >>> WARNING as follows: >>> >>> PFN range: requested [2150105088, 2150105600), allocated [2150105088, 2150106112) >>> WARNING: CPU: 3 PID: 580 at mm/page_alloc.c:6877 alloc_contig_range+0x280/0x340 > Basically, you are using alloc_contig_range() to allocate a compound page > that can be allocated from buddy allocator, since order is < MAX_ORDER. > What is the use case? Why is alloc_contig_range() used? In CMA case, alloc_contig_range() is used to allocate from requested pfn range, and the order may be < MAX_ORDER. > >>> alloc_contig_range() marks pageblocks of the requested pfn range to be >>> isolated, migrate these pages if they are in use and will be freed to >>> MIGRATE_ISOLATED freelist. >>> >>> Suppose two alloc_contig_range() calls at the same time and the requested >>> pfn range are [0x80280000, 0x80280200) and [0x80280200, 0x80280400) >>> respectively. Suppose the two memory range are in use, then >>> alloc_contig_range() will migrate and free these pages to MIGRATE_ISOLATED >>> freelist. __free_one_page() will merge MIGRATE_ISOLATE buddy to larger >>> buddy, resulting in a MAX_ORDER buddy. Finally, find_large_buddy() in >>> alloc_contig_range() returns a MAX_ORDER buddy and results in WARNING. >>> >>> To fix it, call free_contig_range() to free the excess pfn range. >> This has been in mm-hotfixes for a month without issue. Is there any >> reviewer interest? >> >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -6528,7 +6528,8 @@ int alloc_contig_range_noprof(unsigned long start, unsigned long end, >>> goto done; >>> } >>> >>> - if (!(gfp_mask & __GFP_COMP)) { >>> + if (!(gfp_mask & __GFP_COMP) || >>> + (is_power_of_2(end - start) && ilog2(end - start) < MAX_PAGE_ORDER)) { >>> split_free_pages(cc.freepages, gfp_mask); > This does not look right to me. When a compound page is requested, > alloc_contig_range() should give a compound page, but split_free_pages() > will make the free page as a list of contiguous order-0 pages. > > I do not think we should keep this patch. > > Jinjiang, let me know if I miss anything. After split_free_pages(), below code is execucted to collapse the contiguous order-0 pages to a compound page.   if (start == outer_start && end == outer_end && is_power_of_2(end - start)) {         struct page *head = pfn_to_page(start);         int order = ilog2(end - start);         check_new_pages(head, order);         prep_new_page(head, order, gfp_mask, 0);         set_page_refcounted(head);   } Thanks. > >>> /* Free head and tail (if any) */ >>> @@ -6536,7 +6537,15 @@ int alloc_contig_range_noprof(unsigned long start, unsigned long end, >>> free_contig_range(outer_start, start - outer_start); >>> if (end != outer_end) >>> free_contig_range(end, outer_end - end); >>> - } else if (start == outer_start && end == outer_end && is_power_of_2(end - start)) { >>> + >>> + outer_start = start; >>> + outer_end = end; >>> + >>> + if (!(gfp_mask & __GFP_COMP)) >>> + goto done; >>> + } >>> + >>> + if (start == outer_start && end == outer_end && is_power_of_2(end - start)) { >>> struct page *head = pfn_to_page(start); >>> int order = ilog2(end - start); >>> > > Best Regards, > Yan, Zi