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 42878D637D7 for ; Thu, 14 Nov 2024 02:29:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B14F36B0098; Wed, 13 Nov 2024 21:29:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC5266B009A; Wed, 13 Nov 2024 21:29:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98C986B009C; Wed, 13 Nov 2024 21:29:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7A31F6B0098 for ; Wed, 13 Nov 2024 21:29:36 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 158C5160E9C for ; Thu, 14 Nov 2024 02:29:36 +0000 (UTC) X-FDA: 82783117872.06.9CA3965 Received: from chinatelecom.cn (smtpnm6-01.21cn.com [182.42.159.233]) by imf06.hostedemail.com (Postfix) with ESMTP id BDEBE180100 for ; Thu, 14 Nov 2024 02:29:01 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of liuq131@chinatelecom.cn designates 182.42.159.233 as permitted sender) smtp.mailfrom=liuq131@chinatelecom.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731551196; a=rsa-sha256; cv=none; b=ON4uj9b+LL3+KcYSWmAhxll6MeOo/xUb1vG4lcarFXvLGF4hTQmtv7b4yYVQJATMiXKDc1 rMMCRNFliCS9YzmznpyOgcAi9DxgBDOqkaaHuArlek4EcNTpkM5uF1FHD5QBxuJgiqR+4T eVBfaeJ4eWM6zBYEm9mDMEQwPW8F3Ss= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of liuq131@chinatelecom.cn designates 182.42.159.233 as permitted sender) smtp.mailfrom=liuq131@chinatelecom.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731551196; h=from:from:sender: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: references; bh=WymKjDhA742wkrsi2Tgne1gHUZ2gOsatI8UcgNgQGWw=; b=LjbrfyFSu5GzGY9lNoWnu/Qewj+XWDlcwN2WCRkQVFEFHox/BGrb/eXYnL0M4PHxcypaSG jQYcN8LGfxrYhzHN71LbxGBmNWFXIGnpxWRlR90UZSYcRR24k0a7X5flyfHLj47tZEVmkH zCZUCbkgksIsDgOrFIGxMTqDy7Rt7iI= HMM_SOURCE_IP:192.168.139.44:0.1557565417 HMM_ATTACHE_NUM:0000 HMM_SOURCE_TYPE:SMTP Received: from clientip-40.99.74.53 (unknown [192.168.139.44]) by chinatelecom.cn (HERMES) with SMTP id 5473D100112C0; Thu, 14 Nov 2024 10:29:27 +0800 (CST) X-189-SAVE-TO-SEND: +liuq131@chinatelecom.cn Received: from ([40.99.74.53]) by gateway-ssl-dep-6977f57994-mvlbg with ESMTP id f84cc24f0c0d4249be433d436875358f for baolin.wang@linux.alibaba.com; Thu, 14 Nov 2024 10:29:30 CST X-Transaction-ID: f84cc24f0c0d4249be433d436875358f X-Real-From: liuq131@chinatelecom.cn X-Receive-IP: 40.99.74.53 X-MEDUSA-Status: 0 From: "liuq131@chinatelecom.cn" To: "baolin.wang@linux.alibaba.com" CC: "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "liuq131@chinatelecom.cn" Subject: Re: [PATCH] mm/compaction: fix the total_isolated in strict mode Thread-Topic: [PATCH] mm/compaction: fix the total_isolated in strict mode Thread-Index: AQHbNjzPixRVO6Ot3kKopSfFalJ1dg== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 14 Nov 2024 02:29:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 msip_labels: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Stat-Signature: q9urue3386ntdpujoismsfapbqmrt1gq X-Rspamd-Queue-Id: BDEBE180100 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731551341-331834 X-HE-Meta: U2FsdGVkX1/mebWRnwFSID9cWCwCHambREqtkz6LjsQERDHw1A3O73sO5Mtfo6rDb/UN+9jpd6WnV1NkRL+k++4XjIhlgmO9fvByFfaG7HqxCpSDgi/RkVksucQiQFRw/OPnFJgeKBejY+KDSiZmwjqLB7deU4tw8LDvvF1NySHpvAw/+DME3bZOTZbc06lYYyZIh58juMjls7p3HUbU6VZ2KQ1HHn50dR6hRwdgMoay2frpSclGKugPBgNPbP7MMlnDzkRrC5KPUJDWO5uuPvzuw0PDkAK2NtXyQQ3l67dCvVrEXiBdR7p+p24aqRQ1y1KYBHIk6wqp+hhxvZeBhy9VhGQIomCWM4dK/E9IKiTM8E1RGfMbYLmxT3fTnHj4xk/6Bgh+a/cOevOf8wtGikbD57tCq8T57hYZEkqmPPkRuppoyaM26lXs+PqKz8JwDEFSShMg/AR/hPOtkiFwPqPgnq9iF3Mhc+zqiGW4pUdi3dg1VpxIU66x0bDGRiUeCldo1oxbV0K28QrAIPk2O4Ov/15TdBKBlWi+kI5obagz0szLixC3+gY6rgmkl/vzMBRPNwGEIlizilGAMqAoROkgzU9WV9g1/+7FqNvsw6SVRES7rrwxi0ddgNO79GIxyfZiRlFw5n12z1vQFPBM6LducXx1x0f1h4ELhPjZUPE1S2LstVV4b2jF3t4QMVzIT5hz4bbF/UpZb7VIX348KtjstxbkAysUk+kfWlC3O0/9/oM8WFfm8/oAt1a3Xhc/W8yuuhrjh1xBmvL8T49M0Xadlqt5KnB3An+iPK5r+B9wFGsb3+u6JRpmDKeVnY//VuVC3ztaxT0tOt63BFR8Jz5cdF7ASa5M7JUUI7+dcNw7Jzdk86T0EPxWIDU350SbYcETEUeZn9od4qE80muzsyfOt8bQcq1Iy82O0siiO59/UKiRH0oXQQjgIG8Ki4bfw3bZ86dd1nrF9CziW21 /7cI0t2Y ifBZu6TGTjKY2EnSuzQlWC6xQ2BocDUt9ZM5lDWFbKmQpcFazNArH0AOzGox0AsbZ38Wykq6iOIqiA0qJKTuSpks92n3JTcAV5DlkEszEwQPqoRVLTHslGs++23XPXKe1tKiSJAuHoeekkNictHf/ePrwb1CLi9HWqgwE68tQtPymOdsgipWYt7a1Wg7q1ZJ7trK8bGyKddHz9MlWOepApc+CoR2Tihyn5DAT44WNWXIYxwe0cyhfPPv8tcP1KYATWz3JKyhL/bMPS/CY6B0RoiWdbKTicF5zJ/gJkNLlTSKAf4ZmoSZ0smPeRqEqORg9ABqG9WtNewadD58= X-Bogosity: Ham, tests=bogofilter, spamicity=0.396473, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/11/12 17:47, baolin.wang@linux.alibaba.com wrote:=0A= >On 2024/11/12 10:16, liuq131@chinatelecom.cn wrote:=0A= >> "We assume that the block we are currently processing is distributed as = follows:=0A= >> 0 1 2 511= =0A= >> --------------------------------------------------=0A= >> | | | = |=0A= >> ---------------------------------------------------=0A= >> Index 0 and 1 are both pages with an order of 0.=0A= >> Index 2 has a bogus order (let's assume the order is 9).=0A= >> When the for loop reaches index 2, it will enter the following code:=0A= >> /*=0A= >> * For compound pages such as THP and hugetlbfs, we can save=0A= >> * potentially a lot of iterations if we skip them at once.=0A= >> * The check is racy, but we can consider only valid values=0A= >> * and the only danger is skipping too much.=0A= >> */=0A= >> if (PageCompound(page)) {=0A= >> const unsigned int order =3D compound_order(page);=0A= >> if (blockpfn + (1UL << order) <=3D end_pfn) {=0A= >> blockpfn +=3D (1UL << order) - 1;=0A= >> page +=3D (1UL << order) - 1;=0A= >> nr_scanned +=3D (1UL << order) - 1;=0A= >> }=0A= >> goto isolate_fail;=0A= >> }=0A= >> =0A= >> After exiting the for loop:=0A= >> blockpfn =3Dbasepfn+ 2+2^9 =3D basepfn+514=0A= >> endpfn =3D basepfn +512=0A= >> total_isolated =3D 2=0A= >> nr_scanned =3D 514=0A= >=0A= >In your case, the 'blockpfn' will not be updated to 'basepfn+514', =0A= >because 'blockpfn + (1UL << order) > end_pfn', right? And remember the =0A= >'end_pfn' is the end of the pageblock.=0A= >=0A= >So I'm still confused about your case. Is this from code inspection?=0A= You're right, the situation where blockpfn > end_pfn would not actually occ= ur here.=0A= I encountered this issue in the 4.19 kernel, which did not have this check.= =0A= I didn't carefully examine this scenario later. Sorry about that.=0A= =0A= However, when blockpfn =3D=3D end_pfn, I believe the patch is still applica= ble,=0A= but the git log needs to be updated. Is there still an opportunity to submi= t=0A= a revised version of the patch?=0A= >> /*=0A= >> * Be careful to not go outside of the pageblock.=0A= >> */=0A= >> if (unlikely(blockpfn > end_pfn))=0A= >> blockpfn =3D end_pfn;=0A= >> =0A= >> So this can happen=0A= >> =0A= >> /*=0A= >> * If strict isolation is requested by CMA then check that all the=0A= >> * pages requested were isolated. If there were any failures, 0 is=0A= >> * returned and CMA will fail.=0A= >> */=0A= >> if (strict && blockpfn < end_pfn)=0A= >> total_isolated =3D 0;=0A= >> =0A= >> If processed according to the old code, it will not enter the if stateme= nt to reset total_isolated, but the correct handling is to reset total_isol= ated to 0.=0A= >=0A= >Please do not top-posting:=0A= >=0A= >"=0A= >- Use interleaved ("inline") replies, which makes your response easier =0A= >to read. (i.e. avoid top-posting -- the practice of putting your answer = =0A= >above the quoted text you are responding to.) For more details, see=0A= > :ref:`Documentation/process/submitting-patches.rst =0A= >`.=0A= >"=0A=