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 8FE83C433F5 for ; Tue, 3 May 2022 17:27:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C51736B00AA; Tue, 3 May 2022 13:27:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C00AE6B00AB; Tue, 3 May 2022 13:27:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA1A76B00AC; Tue, 3 May 2022 13:27:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 9A7336B00AA for ; Tue, 3 May 2022 13:27:14 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7C595613EB for ; Tue, 3 May 2022 17:27:14 +0000 (UTC) X-FDA: 79425112788.23.3EF5367 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf31.hostedemail.com (Postfix) with ESMTP id 8456E20088 for ; Tue, 3 May 2022 17:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651598832; 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=I2T9v+noUcsp5HoZ7AYLY1QHIF7e3pPU/42dWorsxvk=; b=YliGjBoTcMt29myTvnV5CroVFM6/jDS0Hg3pIwRpjXj9tgdNjIQpPM/GYd5G6Q7NYVb9QF zRRZcAmQ8qqni8niYlWADD+sfk/AVS2zWcOjD3qeSHjnDKtEYK6CeR7AV7ApzsbQgE1VMf m3vxtYjkRpWj6T1pY8sYTij5SsVg0LA= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-596-YYRWaJQfNUWuNP_r7EFTGQ-1; Tue, 03 May 2022 13:27:11 -0400 X-MC-Unique: YYRWaJQfNUWuNP_r7EFTGQ-1 Received: by mail-pl1-f197.google.com with SMTP id i16-20020a170902cf1000b001540b6a09e3so8192958plg.0 for ; Tue, 03 May 2022 10:27:11 -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=I2T9v+noUcsp5HoZ7AYLY1QHIF7e3pPU/42dWorsxvk=; b=L++FTyJrIKgt5FSkpKBxSJMlXJb/00rnsLHqAmk8xvuvJlsY0ye+MQa7Ac34DLSJ/L HLphY24hRvL1b34OHKPLDT+kkMp4Y4Rf6Z8a7oR3L666SmVvF9JWD8kubdMu3QjhsBTm Az+jtlvcFh2j6B6LJ3/IKXaO/r0fRzUnPXP0hu7VP6JBNofBl3XlAjGfaNsyrTb2JobM cd5RlYoSMGxFT/KfClpRfsqXAM6J74lkibpuWdLlArh+YlttwYMbC2/RLu6aZ67b6dBI d518uCTqXO+315NnAqmQ8UVHFPpGk4Sw04zRC2j7gPozbLRtjcKY6PkxDsW+kUopvkQY 9Bcg== X-Gm-Message-State: AOAM533PofhWGUb5++Yx8WHso2msLietd6LKeXWrHgk2Tb5eA0+reDTv 7eRDR9pC5T8LS9eRYnF6lvDR53lFZLkk6yt+c55UJ9WRinfR4D5t44hQkcep6EShMnF6sBkk4Yx wsgYhxjf4eu0= X-Received: by 2002:a62:be14:0:b0:505:a43b:cf6e with SMTP id l20-20020a62be14000000b00505a43bcf6emr17037110pff.33.1651598830467; Tue, 03 May 2022 10:27:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVJTHu4ZFm7X+veJpuPJCnAmKetQVdl460LFzMz2t6BhT4J1SRTmS8Sr62Oo3JX2tienObCA== X-Received: by 2002:a62:be14:0:b0:505:a43b:cf6e with SMTP id l20-20020a62be14000000b00505a43bcf6emr17037088pff.33.1651598830156; Tue, 03 May 2022 10:27:10 -0700 (PDT) Received: from [10.10.69.234] ([8.34.116.185]) by smtp.gmail.com with ESMTPSA id m7-20020aa79007000000b0050dc7628189sm6742403pfo.99.2022.05.03.10.27.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 May 2022 10:27:08 -0700 (PDT) Message-ID: Date: Tue, 3 May 2022 19:27:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 To: Minchan Kim Cc: Andrew Morton , linux-mm , LKML , John Hubbard , John Dias References: <20220502173558.2510641-1-minchan@kernel.org> <29d0c1c3-a44e-4573-7e7e-32be07544dbe@redhat.com> <08e9855c-395d-f40c-de3d-1ec8b644bfe8@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: fix is_pinnable_page against on cma page In-Reply-To: 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 X-Rspamd-Queue-Id: 8456E20088 X-Stat-Signature: 6ma5mp7kq9s3nd36coh54yfxqdwtx7xi Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YliGjBoT; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf31.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1651598818-322448 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: >> GUP would see MIGRATE_ISOLATE and would reject pinning. The page has to >> be migrated, which can fail if the page is temporarily unmovable. > > Why is the page temporarily unmovable? The GUP didn't increase the > refcount in the case. If it's not migrabtable, that's not a fault > from the GUP but someone is already holding the temporal refcount. > It's not the scope this patchset would try to solve it. You can have other references on the page that turn it temporarily unmovable, for example, via FOLL_GET, short-term FOLL_PIN. > >> >> See my point? We will try migrating in cases where we don't have to > > Still not clear for me what you are concerning. > >> migrate. I think what we would want to do is always reject pinning a CMA >> page, independent of the isolation status. but we don't have that > > Always reject pinning a CMA page if it is *FOLL_LONGTERM* Yes. > >> information available. > > page && (MIGRATE_CMA | MIGRATE_ISOLATE) && gup_flags is not enough > for it? > >> >> I raised in the past that we should look into preserving the migration >> type and turning MIGRATE_ISOLATE essentially into an additional flag. >> >> >> So I guess this patch is the right thing to do for now, but I wanted to >> spell out the implications. > > I want but still don't understand what you want to write further > about the implication parts. If you make more clear, I am happy to > include it. What I am essentially saying is that when rejecting to long-term FOLL_PIN something that is MIGRATE_ISOLATE now, we might now end up having to migrate pages that are actually fine to get pinned, because they are not actual CMA pages. And any such migration might fail when pages are temporarily unmovable. > >> >>> >>> A thing to get some attention is whether we need READ_ONCE or not >>> for the local variable mt. >>> >> >> Hmm good point. Staring at __get_pfnblock_flags_mask(), I don't think >> there is anything stopping the compiler from re-reading the value. But >> we don't care if we're reading MIGRATE_CMA or MIGRATE_ISOLATE, not >> something in between. > > How about this? > > CPU A CPU B > > is_pinnable_page > .. > .. set_pageblock_migratetype(MIGRATE_ISOLATE) > mt == MIGRATE_CMA > get_pageblock_miratetype(page) > returns MIGRATE_ISOLATE > mt == MIGRATE_ISOLATE set_pageblock_migratetype(MIGRATE_CMA) > get_pageblock_miratetype(page) > returns MIGRATE_CMA > > So both conditions fails to detect it. I think you're right. That's nasty. -- Thanks, David / dhildenb