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 D517EC433EF for ; Tue, 3 May 2022 16:02:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 227866B009A; Tue, 3 May 2022 12:02:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D7376B009B; Tue, 3 May 2022 12:02:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09F526B009C; Tue, 3 May 2022 12:02:57 -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 EB7D16B009A for ; Tue, 3 May 2022 12:02:56 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id C29BA12085F for ; Tue, 3 May 2022 16:02:56 +0000 (UTC) X-FDA: 79424900352.29.84EFA0B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id BD3B218008E for ; Tue, 3 May 2022 16:02:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651593772; 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=ZTs41GXb8wIzvyXd50RZNuQtqo7++DwnC0mSBVTVZ0s=; b=eGqrw2wC7TtiCYq40CmUepcITjb0Y5pCgfHElTYZvB5Zp0974QwpnEdL8ntg4+ZzB9oKnA RBMwzROsc1VJKxVb/TtRFLtZOpnum8NTZ05vb/IATKaYewnLjBGIIM9DNIS2/oXMvBz1b7 iPvlcxJxa3uMhWv7q0G6vGS/DgGv0o8= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-625-B4G2UBtjOZKyYrLL_eufag-1; Tue, 03 May 2022 12:02:37 -0400 X-MC-Unique: B4G2UBtjOZKyYrLL_eufag-1 Received: by mail-oo1-f70.google.com with SMTP id j15-20020a4a888f000000b00321764d8f14so10129779ooa.14 for ; Tue, 03 May 2022 09:02:37 -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=ZTs41GXb8wIzvyXd50RZNuQtqo7++DwnC0mSBVTVZ0s=; b=aVeaDKawCz6pYnObywlzUUywd4rDjmcd7foNmFU1niChmBNbL28z12bLMIXLE4ifui Jf49azymRFSXVMH7W5qHBe1qqPA/tueryryeDCaCDNvXCx+up6XtnoExycEUD+ayzmDB fFXgLKX+sJSzWZPLTqOTX4QFjCnmXZBRyzO0sBowl5BCjzwcRVNyeP12AI5BBZjWC054 fQ6Aj0BmD+/9xrbsTMjT+y0L+BMVhd1E5i06w89EXRJf8JmvM0Gfo3UmoK9mt8AV+D9O 9NjvUh5BhoUS+3CmemGHQ1GFtgdoEs80Pgm1S5BrFI6BlmJA66Sb0Zf9Kkb1amdgyOuv Bpog== X-Gm-Message-State: AOAM532rSq6cD5CzLmmB3dUcz373MzJkEeNv8odxBIxi9YIZkWtu6GrJ 2oGYGaeph9kkXQ6va8IxwSvnP7/U+BJMJtZO/BTszkID4CQt6Ed/ZAbIeEhaqXN0Fo4tPORbBb3 FMtgMY/NB7K8= X-Received: by 2002:a05:6830:4196:b0:605:e96b:bb59 with SMTP id r22-20020a056830419600b00605e96bbb59mr5973754otu.361.1651593756904; Tue, 03 May 2022 09:02:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyTlwej4kwlhDyJ+P/DSGKgzh5AIBYDo0weUFflJsTWm5t+ac0cJZYqjj6GGYNw7wRsYPLRw== X-Received: by 2002:a05:6830:4196:b0:605:e96b:bb59 with SMTP id r22-20020a056830419600b00605e96bbb59mr5973741otu.361.1651593756568; Tue, 03 May 2022 09:02:36 -0700 (PDT) Received: from [10.10.69.234] ([8.34.116.185]) by smtp.gmail.com with ESMTPSA id s18-20020a0568301e1200b006060322127csm4026733otr.76.2022.05.03.09.02.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 May 2022 09:02:35 -0700 (PDT) Message-ID: Date: Tue, 3 May 2022 18:02:33 +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 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eGqrw2wC; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BD3B218008E X-Rspam-User: X-Stat-Signature: 3zs76x8wehwuuugyj8c8fa7byhxqdt3f X-HE-Tag: 1651593767-641915 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: On 03.05.22 17:26, Minchan Kim wrote: > On Tue, May 03, 2022 at 03:15:24AM +0200, David Hildenbrand wrote: >> >>>>>> However, I assume we have the same issue right now already with >>>> ZONE_MOVABLE and MIGRATE_CMA when trying to pin a page residing on these >>> >>> ZONE_MOVALBE is also changed dynamically? >>> >> >> Sorry, with "same issue" I meant failing to pin if having to migrate and >> the page is temporarily unmovable. >> >>>> there are temporarily unmovable and we fail to migrate. But it would now >>>> apply even without ZONE_MOVABLE or MIGRATE_CMA. Hm... >>> >>> Didn't parse your last mention. >> >> On a system that neither uses ZONE_MOVABLE nor MIGRATE_CMA we might have >> to migrate now when pinning. > > I don't understand your point. My problem is pin_user_pages with > FOLL_LONGTERM. It shouldn't pin a page from ZONE_MOVABLE and cma area > without migrating page out of movable zone or CMA area. > That's why try_grab_folio checks whether target page stays in those > movable areas. However, to check CMA area, is_migrate_cma_page is > racy so the FOLL_LONGTERM flag semantic is broken right now. > > Do you see any problem of the fix? My point is that you might decide to migrate a page because you stumble over MIGRATE_ISOLATE, although there is no need to reject long-term pinning and to trigger page migration. Assume a system without ZONE_MOVABLE and without MIGRATE_CMA. Assume someone reserves gigantic pages (alloc_contig_range()) and you have concurrent long-term pinning on a page that is no MIGRATE_ISOLATE. GUP would see MIGRATE_ISOLATE and would reject pinning. The page has to be migrated, which can fail if the page is temporarily unmovable. See my point? We will try migrating in cases where we don't have to 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 information available. 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. > > 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. -- Thanks, David / dhildenb