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 9D4FAC433F5 for ; Tue, 3 May 2022 17:20:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D90626B00A5; Tue, 3 May 2022 13:20:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D19676B00A7; Tue, 3 May 2022 13:20:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6B6F6B00A8; Tue, 3 May 2022 13:20:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id A26EA6B00A5 for ; Tue, 3 May 2022 13:20:47 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 79D2B247D3 for ; Tue, 3 May 2022 17:20:42 +0000 (UTC) X-FDA: 79425096324.18.7809936 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf20.hostedemail.com (Postfix) with ESMTP id EFFDE1C008C for ; Tue, 3 May 2022 17:20:35 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id fv2so15912900pjb.4 for ; Tue, 03 May 2022 10:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9ffQfmOldbylSricKvp2FO9bq39SOCqrZpm2Itq8wUo=; b=M7B0o8W/jBNdraa+HXpW0N4QP8EtbIBaksGkOthoczQIFOAPvH0cZQ3wa74CYSAHxr c4r3CDqe/NImzllgLfLNzhZBFnch8yvVpT1GOvMqIwulyqJtDeqQNDJI+a6YfvvF/Itx wpLDh8h2WNW7g4zGpkNFssI8Vhnd01s30Yvya/5BsvhPKqpacMgnfeONFopG+cbvsBwN fg4VWW3mDk+eA+ViUd0SWSxe4W+r0pYh/p5R5PVJyUazTbm9zQcLyP1UTS2hNkKa4RMo 55x6mmBxfBNSA37fxraR4r1hgOXCrL8VywDk0O0qt6xhQ4+JXw3rmAIGEC7cQv84ros1 FUoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=9ffQfmOldbylSricKvp2FO9bq39SOCqrZpm2Itq8wUo=; b=6cBNdcTVa1PZF/kqPEvDZMe4oYkXcjh+TA6oXBQKrf+kuSsj6CF4idyObm7FvgQgHJ jv0D1yjcBzGjJmp3WPNA6MJdnoPZOBJlOkQiCKfpU7b6KUd5HXIKeSBbR/Z8Na5bU8L+ KCOUHkwYdlyacKiopun4mqldz/XOs1SWnQuxsoIz047n4e9zstxxUpZrcZXI6QKwX5O1 kPdRmv8SXxM3brISDobkGLR5spu3KbdMO1NRwcvCxBFFAFVNxR0TJvEOiZhNjQnOrPFI /3Xxg0TzhIEs5Uk/WFruYvVO3gFvNGzI4/eQh0gm+xNRuMKfLIGln0wXHB/uw9NyuOHj T/jQ== X-Gm-Message-State: AOAM530rR+yUVLTv4nGRkOhIHJUOXSmalYViV0PU9gVMIi63hPbkCREv iSS2IlX84x16YVrpWpz7Pf72BaBv1z0= X-Google-Smtp-Source: ABdhPJw9lGhOZEQ8zJlMbQe4HzmueOo9dbUNl5+pYhpmljJJw9niSLnfsjUgHueVB9u/CuMNSpEVEA== X-Received: by 2002:a17:902:a501:b0:153:f956:29f0 with SMTP id s1-20020a170902a50100b00153f95629f0mr17761940plq.120.1651598440701; Tue, 03 May 2022 10:20:40 -0700 (PDT) Received: from google.com ([2620:15c:211:201:8998:54e:9def:1e7c]) by smtp.gmail.com with ESMTPSA id c3-20020a17090a558300b001d5f22845bdsm1967254pji.1.2022.05.03.10.20.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 May 2022 10:20:40 -0700 (PDT) Date: Tue, 3 May 2022 10:20:38 -0700 From: Minchan Kim To: David Hildenbrand Cc: Andrew Morton , linux-mm , LKML , John Hubbard , John Dias Subject: Re: [PATCH] mm: fix is_pinnable_page against on cma page Message-ID: References: <20220502173558.2510641-1-minchan@kernel.org> <29d0c1c3-a44e-4573-7e7e-32be07544dbe@redhat.com> <08e9855c-395d-f40c-de3d-1ec8b644bfe8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EFFDE1C008C X-Stat-Signature: hra1qp4jsn31nxwaqcq3nuzddpdtnc4d X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="M7B0o8W/"; spf=pass (imf20.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-HE-Tag: 1651598435-13995 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 Tue, May 03, 2022 at 06:02:33PM +0200, David Hildenbrand wrote: > 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. 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. > > 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* > 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. > > > > > 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.