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 EB097C433EF for ; Thu, 12 May 2022 07:10:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 537C66B0074; Thu, 12 May 2022 03:10:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E7C46B0075; Thu, 12 May 2022 03:10:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 388B36B0078; Thu, 12 May 2022 03:10:26 -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 2C4996B0074 for ; Thu, 12 May 2022 03:10:26 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id F2FFC80256 for ; Thu, 12 May 2022 07:10:25 +0000 (UTC) X-FDA: 79456217610.19.4579C65 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 38141400B4 for ; Thu, 12 May 2022 07:10:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652339424; 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; bh=YS0S6KH7SUmuANQj1TttUhl1vOvBYTpy060LSdzgn98=; b=c77D/yZOys0xmF+PaHrOaBkBm98R3ExJ4OUHY19RcVDtcXGJQc0J+QAnTonpF5v8VAtOT5 lTRsvDf2naaXQKvy1JwHO3hzV1iAJ2D0uwVIgpC1hfOEOakWi6suqtfuWNeTL8R9eFCaQ9 +jiy4oDBWeOfLoP2FoyuPQj06xs4wIM= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-627-4KYMdlq6My-lEoeYoMjmbw-1; Thu, 12 May 2022 03:10:23 -0400 X-MC-Unique: 4KYMdlq6My-lEoeYoMjmbw-1 Received: by mail-wm1-f71.google.com with SMTP id u3-20020a05600c210300b0039430c7665eso1321643wml.2 for ; Thu, 12 May 2022 00:10:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=YS0S6KH7SUmuANQj1TttUhl1vOvBYTpy060LSdzgn98=; b=NaQaZpb10xC+hfkESVfAQ8uB5XOD13PTbyKcfEpmeLPyy3PsuCuE2Zl3tyi7iluWt4 rpk7ljP2E012mzDPluRtuIA/3tgvbusXd7dBqmg5MLwfmHVUyUC81hJv6S6SmQ/eRVCU t2pfVXGAU6WLj9BpjpivJoMoXxG3CpDLRxqsfs/YnSOFdTm3wD1gd9WB/jvlY3lZP+3Q 1YJw+p4+LYvoqtJwBkGlCfTTVv0Tuwd3z/urx7MbeLlwJIaFeijj50Z8Go0lRuHKJo8/ JDSoKPOSDtKRQvEvizrvwkvcExeJO0jv7KCSHtEXEcxmOZHabsDXqHfRnzQMaXv1rLZZ XM9Q== X-Gm-Message-State: AOAM533N2Sc15Co737F1G4dOoyColqP4RYdYyTqntxy08HL3bOT2m4Ju aFmNqgtxjcnDHy4IkPY+Uxap/L5G43NrS2wNwdo4h35/1DOsRdkP2QRrQY6WBgcTNaJ9kylS1J2 YzoOZbBAREnk= X-Received: by 2002:a5d:4052:0:b0:20a:d8b9:9d4b with SMTP id w18-20020a5d4052000000b0020ad8b99d4bmr25334658wrp.612.1652339422543; Thu, 12 May 2022 00:10:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybzz24sWU+LbkUCCmAALDO44blzojf0G/oD1KhTr1Rqygw7Qu9PimEjzomDbhyFzgqJYEPIg== X-Received: by 2002:a5d:4052:0:b0:20a:d8b9:9d4b with SMTP id w18-20020a5d4052000000b0020ad8b99d4bmr25334634wrp.612.1652339422228; Thu, 12 May 2022 00:10:22 -0700 (PDT) Received: from ?IPV6:2003:cb:c701:d200:ee5d:1275:f171:136d? (p200300cbc701d200ee5d1275f171136d.dip0.t-ipconnect.de. [2003:cb:c701:d200:ee5d:1275:f171:136d]) by smtp.gmail.com with ESMTPSA id r6-20020adfdc86000000b0020c5253d8bdsm4144439wrj.9.2022.05.12.00.10.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 May 2022 00:10:21 -0700 (PDT) Message-ID: Date: Thu, 12 May 2022 09:10:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 To: Miaohe Lin Cc: ying.huang@intel.com, hch@lst.de, dhowells@redhat.com, cl@linux.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, mike.kravetz@oracle.com, naoya.horiguchi@nec.com, Minchan Kim References: <20220425132723.34824-1-linmiaohe@huawei.com> <20220425132723.34824-3-linmiaohe@huawei.com> <525298ad-5e6a-2f8d-366d-4dcb7eebd093@redhat.com> <4cf144a9-fff5-d993-4fcb-7f2dfa6e71bb@redhat.com> <924de987-202b-a97e-e6d2-6bdab530f190@huawei.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 2/4] mm/migration: remove unneeded lock page and PageMovable check In-Reply-To: <924de987-202b-a97e-e6d2-6bdab530f190@huawei.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="c77D/yZO"; spf=none (imf01.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 38141400B4 X-Stat-Signature: uaghmtpybbnqyz5d9uho3bf93x5gbp9j X-HE-Tag: 1652339413-577789 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: >> If PG_isolated is still set, it will get cleared in the buddy when >> freeing the page via >> >> page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; > > Yes, check_free_page only complains about flags belonging to PAGE_FLAGS_CHECK_AT_FREE and PG_isolated > will be cleared in the buddy when freeing the page. But it might not be a good idea to reply on this ? > IMHO, it should be better to clear the PG_isolated explicitly ourselves. I think we can pretty much rely on this handling in the buddy :) > >> >>> >>>> >>>> >>>> Also, I am not sure how reliable that page count check is here: if we'd >>>> have another speculative reference to the page, we might see >>>> "page_count(page) > 1" and not take that path, although the previous >>>> owner released the last reference. >>> >>> IIUC, there should not be such speculative reference. The driver should have taken care >>> of it. >> >> How can you prevent any kind of speculative references? >> >> See isolate_movable_page() as an example, which grabs a speculative >> reference to then find out that the page is already isolated by someone >> else, to then back off. > > You're right. isolate_movable_page will be an speculative references case. But the page count check here > is just an optimization. If we encounter speculative references, it still works with useless effort of > migrating to be released page. Not really. The issue is that PAGE_FLAGS_CHECK_AT_FREE contains PG_active and PG_unevictable. We only clear those 2 flags if "page_count(page) == 1". Consequently, with a speculative reference, we'll run into the check_free_page_bad() when dropping the last reference. This is just shaky. Special casing on "page_count(page) == 1" for detecting "was this freed by the owner" is not 100% water proof. In an ideal world, we'd just get rid of that whole block of code and let the actual freeing code clear PG_active and PG_unevictable. But that would require changes to free_pages_prepare(). Now I do wonder, if we ever even have PG_active or PG_unevictable still set when the page was freed by the owner in this code. IOW, maybe that is dead code as well and we can just remove the whole shaky "page_count(page) == 1" code block. Ccing Minchan, who added clearing of the pageflags at that point. -- Thanks, David / dhildenb