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 7DF1EC433EF for ; Thu, 20 Jan 2022 18:03:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CF0D6B00A1; Thu, 20 Jan 2022 13:03:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07DEF6B00A4; Thu, 20 Jan 2022 13:03:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E889F6B00A5; Thu, 20 Jan 2022 13:03:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id D8BFE6B00A1 for ; Thu, 20 Jan 2022 13:03:58 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9E6DF9367C for ; Thu, 20 Jan 2022 18:03:58 +0000 (UTC) X-FDA: 79051438956.11.208D857 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf07.hostedemail.com (Postfix) with ESMTP id 0BC7C4003D for ; Thu, 20 Jan 2022 18:03:48 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id h12so6623700pjq.3 for ; Thu, 20 Jan 2022 10:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hBdSBn0aY8P5b7CcUgLLwj8ITEo8ulwTDyDNKsj3JU4=; b=a8aewc0V/Mxa2wZG0otBO8Z8iDIGHB/+3V8bw2mJ2XqPnqJ++PYfOnsG42TIZAwmqc YyV98avkWwkZDb6Iaz+XVg7VcoZ7PbAysz/vC05oTQ3r01xOWu1hfo/cJMdXdA88EeD7 kilKiQyJczONi7FpcV9v7l58pXiQBuOvjs5cXgXH7mpNn1FZNAxGRQ4vxUxByCgmG/zT +p8VWIM+3swreGU1vQe79490Ru1O3NR1TCvWyoBZ77JTZQLf1ObcHdLln06qRp5C8DMt 5q4UT5Y2+l5dS6l6zT03ArlGHFXfK4jMFqhsYuexjlTWK0VeM6NGovoJx0g63VzbD++Q 7SaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hBdSBn0aY8P5b7CcUgLLwj8ITEo8ulwTDyDNKsj3JU4=; b=BbBwgNAwiPLOkvooXDZjxRjYLoBg7Hig8lhEvVjv497C0Ps1Nh0/VdU7PqvNpt+lcR 3IEnNLkcXlzKsMZ6O0mJqCPUx4CtcAXrOv4E/wBDxVj/ogafYa1HFfU3g2GgIn7GZTLv z+KgIIUYOvGYjLx7RNDNiorsgZWiptLoMbC3tozJRP6ACOZfA0hfVUo+OLChfSyRw4Fg rVKqyf9QGsZDlI+RkiCHiInVChmcVLZntvEoC+hc5O+yk2p+Vq2kcKa0b/gZugCwPftP g5xk5dKASTp0eaaZ6TdTJf2sbWqtKYdlXmTBSwN5CVbHBYgW1gccQ60Q//0uGfmO7Fhk MMBQ== X-Gm-Message-State: AOAM5317NxUQhTUM28CmKsGJkKsYKnqhbBP8nKDE+SnGQohRLHJoDfKM jlYOf0+jz0/aKvonagBsASA= X-Google-Smtp-Source: ABdhPJzV4sADT3tD7ij7Xb6ez768vZE0npHBW1XWFtG1IZst812poZLDRzFTqJm2siEIPk7w+lZi1g== X-Received: by 2002:a17:90a:4305:: with SMTP id q5mr12283473pjg.222.1642701827779; Thu, 20 Jan 2022 10:03:47 -0800 (PST) Received: from smtpclient.apple ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id w10sm3589790pfn.153.2022.01.20.10.03.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jan 2022 10:03:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: [RFC][PATCH v2 1/5] mm: Avoid unmapping pinned pages From: Nadav Amit In-Reply-To: <20220120160822.666778608@infradead.org> Date: Thu, 20 Jan 2022 10:03:44 -0800 Cc: Ingo Molnar , Thomas Gleixner , juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, Steven Rostedt , bsegall@google.com, Mel Gorman , bristot@redhat.com, Linux Kernel Mailing List , Linux-MM , linux-api@vger.kernel.org, X86 ML , pjt@google.com, posk@google.com, avagin@google.com, Jann Horn , tdelisle@uwaterloo.ca, mark.rutland@arm.com, posk@posk.io Content-Transfer-Encoding: 7bit Message-Id: References: <20220120155517.066795336@infradead.org> <20220120160822.666778608@infradead.org> To: Peter Zijlstra X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 0BC7C4003D X-Stat-Signature: pneoqa1iug745wfagxu34z3cp9wpp4br Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=a8aewc0V; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-HE-Tag: 1642701828-81067 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 Jan 20, 2022, at 7:55 AM, Peter Zijlstra wrote: > > Add a guarantee for Anon pages that pin_user_page*() ensures the > user-mapping of these pages stay preserved. In order to ensure this > all rmap users have been audited: > > vmscan: already fails eviction due to page_maybe_dma_pinned() > > migrate: migration will fail on pinned pages due to > expected_page_refs() not matching, however that is > *after* try_to_migrate() has already destroyed the > user mapping of these pages. Add an early exit for > this case. > > numa-balance: as per the above, pinned pages cannot be migrated, > however numa balancing scanning will happily PROT_NONE > them to get usage information on these pages. Avoid > this for pinned pages. > > None of the other rmap users (damon,page-idle,mlock,..) unmap the > page, they mostly just muck about with reference,dirty flags etc. > > This same guarantee cannot be provided for Shared (file) pages due to > dirty page tracking. > > [ snip ] > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -106,6 +106,12 @@ static unsigned long change_pte_range(st > continue; > > /* > + * Can't migrate pinned pages, avoid touching them. > + */ > + if (page_maybe_dma_pinned(page)) > + continue; > + > + /* > I have a similar problem with userfaultfd changing protection for DMA-pinned pages. For userfaultfd it is important to know how many pages were actually modified. I am working on a vectored UFFDIO_WRITEPROTECTV that aborts once a pinned page is encountered, but also returns the number of pages that were properly protected. I still need to do some work to send patches for that as it requires further changes (to return the number of pages that were handled). But for the matter of your patch, is it possible to make this test generic (not migration specific) and rely on a new flag in cp_flags? I can of course make this change later if you prefer it this way.