Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3328122pxb; Mon, 6 Sep 2021 18:59:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJCMBJ1rfudKjw0pq7isnjtJW7pMFy2RULeSjD7EbCXzkW3CjIV+zzBimemlsJUqp4CIMZ X-Received: by 2002:a17:906:4c8c:: with SMTP id q12mr16376500eju.254.1630979959910; Mon, 06 Sep 2021 18:59:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630979959; cv=none; d=google.com; s=arc-20160816; b=I6Yt8qKlUZs18rSuviURvngebo3+nolO5OwAaCH7OpYwky1FXj+vsoP7onNQa8WeIz AODIK4ALLkUXh6sVixgkDYB/Ex4MqNInxgu/ISOPYEAJAK8pS/1PzreX5LIZ8DK28xI5 niPZkQ4a5CAzJERiQ6nvaFnuaNj1q7n7Tq5n1uVVZF91DYAGn4aS9FGtlEqaPvI2TFWC nfRQVuB7OzbnTXk7goQ3wTekDWfa1y0ac8oIVPPPIRjgOKaHwLsKS2KQ7afIaCf6qqxw TjwBfmSNTUCQE5XgVCN0cYyZB506nLkzri9ySPsl9GMDpoUzNlNwpMb9byiTnIbSrzEL UuPw== 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=IftDL7kQXi8K/IN92hXA1mcKUaHcE3hppxgD1UV6Pqs=; b=i6lUSp8FZYvw+JAgY+msA6QUtq9n7l2DDXaHTmucBEHydEwx563UR5lKLE413bwVng Bz19vqLPuV19Xh+Wh0ScPE+YcvFzb2k2PshdSRMdiy8Sp6O/M1S2i/g8dJVzBtWxNtKH 0Jyox2YPRKDG8RgwAesI5sUm5CTPgrF8gwLk9g1XpytMc5VRg6ru2cvr3zlSdmR1ngDd 8Uv1V0Pueext2UP+Y6mlsKA8FxfFFRRHmvmfuJnRYNm4azLb8rDh4wMW0aUNzA/8QdnH ZEPBE1y/yvHAorVDCs1YxGt1skaL65s8WN+RY1fIiHiGdYT1D3mEbFic/TTA3AqoeHjb yGKg== 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 qf40si8681868ejc.117.2021.09.06.18.58.55; Mon, 06 Sep 2021 18:59:19 -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 S238375AbhIGBsH (ORCPT + 99 others); Mon, 6 Sep 2021 21:48:07 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:15244 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229967AbhIGBsG (ORCPT ); Mon, 6 Sep 2021 21:48:06 -0400 Received: from dggeme703-chm.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4H3Sm06lzdz1DGpB; Tue, 7 Sep 2021 09:46:08 +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; Tue, 7 Sep 2021 09:46:58 +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: <57392d12-9a6c-dbb5-3c3e-39ed9ab7c31c@huawei.com> Date: Tue, 7 Sep 2021 09:46:57 +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: 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:49, David Hildenbrand wrote: > On 06.09.21 14:45, Miaohe Lin wrote: >> 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? > > Maybe > > isolated_page = !!__isolate_free_page(page, order); > /* >  * Isolating a free page in an isolated pageblock is expected to always >  * work as watermarks don't apply here. >  */ > VM_BUG_ON(isolated_page); Should this be VM_BUG_ON(!isolated_page) ? > > > VM_BUG_ON() allows us to detect any issues when testing. Combined with the comment it tells everybody messing with __isolate_free_page() what we expect in this function. > > In production system, we would handle it gracefully. > Sounds reasonable. Will do it in v2. Many thanks for your suggestion and effort!