Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp2801615pxb; Mon, 6 Sep 2021 05:49:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzeCDSE/6YZiz+W1DcfJnn11h1dgWlknfFMSs+LHXtUY9cqpCr1GfSRLSbdE1SLBryCWrLZ X-Received: by 2002:a17:906:5d6:: with SMTP id t22mr13477703ejt.98.1630932568848; Mon, 06 Sep 2021 05:49:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630932568; cv=none; d=google.com; s=arc-20160816; b=TZuE+kiwqF0y7wbYA3UDorORZn99m6MehhMDtfxgFcpCYw4V6/cCx5FgytDu3r28cv l4eatOJOJNUmCjNXYC3Gi6z5WBz8ymR/zJZsj16fcUtUwyL7E4GdpCDp/xJvprSj379f LxzE0yvzajEyOaOBe/UGoKwMujZkdRfsYrOfyXi9myFR0hkzJMBDRsSbEAKfghdfLxWo 2EIul+e+PfalekGeVdt7kYZstpKkAQPbehIda1BJjQxeXplEzPQsniZWQ+tDnL4AVGXb mWYXSmo+HnSOTBEufV5Y/rbSCnPmJTphIjPfuTwQbeNew1wA/9o3PjFY28nNPEX38Ktm zP4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=9+sxM8QSdTWPvLJtL7b7Ky1eDN5bTbokw6GWlvS/KF0=; b=pZgAFkZ1DBLk75SPL7vrcdwVKabRKiugzNDhRoXhnRtactmBYQoh+wOAb25fqRI5AI zvJBgv9PAz4/YAryuTyriCjV4aNc+TVvMX6E+HmopbQgPFWySs80Fd8DQX7agcbS3WiD Fc4pTasvbRTEwsMs/FamDdPf7Hi5NYhjBJv8MPNtfGe6k20iUDVs243grDolG+k2lThF 4ijux4Y1XCtqqbCC4EM7zlOeHNWhEYJHG7D47vilMP/TieVTGkMfzSRnLoTpUgFGyhsJ FpNrqXdlBNL1guZMYHzFIEFL7OczV3n3g/tp/I+EDvcGFRNW9qXI6K7om3XRcDr3R3xO 58nA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bl4si8866023ejb.283.2021.09.06.05.49.04; Mon, 06 Sep 2021 05:49:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242260AbhIFMqW (ORCPT + 99 others); Mon, 6 Sep 2021 08:46:22 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:19011 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242199AbhIFMqV (ORCPT ); Mon, 6 Sep 2021 08:46:21 -0400 Received: from dggeme703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4H37LL6hX4zbkXS; Mon, 6 Sep 2021 20:41:14 +0800 (CST) Received: from [10.174.178.100] (10.174.178.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Mon, 6 Sep 2021 20:45:13 +0800 Subject: Re: [PATCH] mm/page_isolation: don't putback unisolated page To: David Hildenbrand , CC: , , , References: <20210904091839.20270-1-linmiaohe@huawei.com> <3b36529f-ab97-ddfe-0407-66f0cd1fd38d@redhat.com> <2d06db75-5c26-8fe2-6883-ac99056a9894@redhat.com> From: Miaohe Lin Message-ID: Date: Mon, 6 Sep 2021 20:45:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <2d06db75-5c26-8fe2-6883-ac99056a9894@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.100] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggeme703-chm.china.huawei.com (10.1.199.99) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/9/6 20:11, David Hildenbrand wrote: > On 06.09.21 14:02, David Hildenbrand wrote: >> On 04.09.21 11:18, Miaohe Lin wrote: >>> If __isolate_free_page() failed, due to zone watermark check, the page is >>> still on the free list. But this page will be put back to free list again >>> via __putback_isolated_page() now. This may trigger page->flags checks in >>> __free_one_page() if PageReported is set. Or we will corrupt the free list >>> because list_add() will be called for pages already on another list. >>> >>> Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock") >>> Signed-off-by: Miaohe Lin >>> --- >>>    mm/page_isolation.c | 6 ++---- >>>    1 file changed, 2 insertions(+), 4 deletions(-) >>> >>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c >>> index 9bb562d5d194..7d70d772525c 100644 >>> --- a/mm/page_isolation.c >>> +++ b/mm/page_isolation.c >>> @@ -93,10 +93,8 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >>>                buddy_pfn = __find_buddy_pfn(pfn, order); >>>                buddy = page + (buddy_pfn - pfn); >>>    -            if (!is_migrate_isolate_page(buddy)) { >>> -                __isolate_free_page(page, order); >>> -                isolated_page = true; >>> -            } >>> +            if (!is_migrate_isolate_page(buddy)) >>> +                isolated_page = !!__isolate_free_page(page, order); >>>            } >>>        } >>>    >> >> Thanks! >> >> Reviewed-by: David Hildenbrand >> > > To make the confusion perfect (sorry) :D I tripple-checked: > > In unset_migratetype_isolate() we check that is_migrate_isolate_page(page) holds, otherwise we return. > > We call __isolate_free_page() only for such pages. > > __isolate_free_page() won't perform watermark checks on is_migrate_isolate(). > > Consequently, __isolate_free_page() should never fail when called from unset_migratetype_isolate() > > If that's correct then we  could instead maybe add a VM_BUG_ON() and a comment why this can't fail. > > > Makes sense or am I missing something? I think you're right. __isolate_free_page() should never fail when called from unset_migratetype_isolate() as explained by you. But it might be too fragile to reply on the failure conditions of __isolate_free_page(). If that changes, VM_BUG_ON() here might trigger unexpectedly. Or am I just over-worried as failure conditions of __isolate_free_page() can hardly change? Many thanks. :) >