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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94C00C3F2CD for ; Mon, 2 Mar 2020 02:26:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 408B324699 for ; Mon, 2 Mar 2020 02:26:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NJHRWfeh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 408B324699 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D1BB56B0005; Sun, 1 Mar 2020 21:26:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF23C6B0006; Sun, 1 Mar 2020 21:26:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2F396B0007; Sun, 1 Mar 2020 21:26:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id A881F6B0005 for ; Sun, 1 Mar 2020 21:26:09 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 49B43299B3 for ; Mon, 2 Mar 2020 02:26:09 +0000 (UTC) X-FDA: 76548832458.18.basin49_8d02e74b52d17 X-HE-Tag: basin49_8d02e74b52d17 X-Filterd-Recvd-Size: 6714 Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Mar 2020 02:26:08 +0000 (UTC) Received: by mail-il1-f194.google.com with SMTP id a6so7979411ilc.4 for ; Sun, 01 Mar 2020 18:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y4qMUbngHU0JjUQMSTsOk2cYBS6dppyjH0RtlnGG11g=; b=NJHRWfehqRMtZFiO090VtWnqvM2HUpfsq9RP2Pd4nEcecHtnwqN0INK12NILkk5S5N ZMCq3Qpd3gOjOdv+RRQg6udkYVXM+mMxwJRaBv+CxUXXx+DoAb1eXK7URMBUibZ3mB0b ZcpQ/8DalYgarvb2O/oV6n+f4CTMaa6JcApciExGI4ChXr7m2QdVV4W9aQi32rxISS4J oAGUEvlvF01HpG8vzAF/eWL6GDFjod5j3i5wHUWbSYiwfEXultPPoH7SksZqOkON5z2f MF5gxmWkMyxSteXwGFHsjszqKt0rDcqmhArHP+PYap6C4Oj7MlpR5ZxoydVwSQyxHSP8 NgPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y4qMUbngHU0JjUQMSTsOk2cYBS6dppyjH0RtlnGG11g=; b=KDGZ/yk7skrAqgsV6VpEt+ePpD+RzY+NG/0mKihKixKf4sFge22NPLyhDHFMgfxDbh ntJSz60IfmOmjlNSoc/JeZYA2SIfn9JaCmHbTw/o3hjNNX4hb0A5nMaALYsWlmcHUyMD QE2pYl17y5KSZXYvnYskPTZYuQiz0UMQbjNovfHvSPrjy8fbyGIE2xBKv2JfsqnXoIsH YR6zouBI51K4odB/uF0WKEyvdCHMPDM+KG72BzXbKIlM9LUISrSbXdOyuJIgLjoGtLj2 Wkd7SL3TPIEHupsL0Ek6oIbGwIkj0unThP1Qr9QCc/cWeMELGlS9XAH0UL8pyLMgEWSM BKNg== X-Gm-Message-State: APjAAAVjrdpEH4NaoVHo1BYacy+v4ZWMgiBmWbS08IdqTeUOgGKyfT9S 1ksX4HhQTgS6Ty6of4mhlAJ6a2+iVpWW0vOZxw== X-Google-Smtp-Source: APXvYqwSQC21otYbbvTNA4Fx84pG0p1i4QlVd6wCX1RnOrC6Iskv8G9LRbH0IDYERcOvWTb4FGEqXTWs7Es3mQLaBqQ= X-Received: by 2002:a92:8cca:: with SMTP id s71mr6002884ill.179.1583115968314; Sun, 01 Mar 2020 18:26:08 -0800 (PST) MIME-Version: 1.0 References: <1582889550-9101-1-git-send-email-kernelfans@gmail.com> <1582889550-9101-3-git-send-email-kernelfans@gmail.com> <20200228134436.GP31668@ziepe.ca> In-Reply-To: <20200228134436.GP31668@ziepe.ca> From: Pingfan Liu Date: Mon, 2 Mar 2020 10:25:52 +0800 Message-ID: Subject: Re: [PATCHv5 2/3] mm/gup: fix omission of check on FOLL_LONGTERM in gup fast path To: Jason Gunthorpe Cc: Linux-MM , Ira Weiny , Andrew Morton , Mike Rapoport , Dan Williams , Matthew Wilcox , John Hubbard , "Aneesh Kumar K.V" , Keith Busch , Christoph Hellwig , Shuah Khan , LKML Content-Type: text/plain; charset="UTF-8" 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 Fri, Feb 28, 2020 at 9:44 PM Jason Gunthorpe wrote: > > On Fri, Feb 28, 2020 at 07:32:29PM +0800, Pingfan Liu wrote: > > FOLL_LONGTERM suggests a pin which is going to be given to hardware and > > can't move. It would truncate CMA permanently and should be excluded. > > > > FOLL_LONGTERM has already been checked in the slow path, but not checked in > > the fast path, which means a possible leak of CMA page to longterm pinned > > requirement through this crack. > > > > Place a check in try_get_compound_head() in the fast path. > > > > Some note about the check: > > Huge page's subpages have the same migrate type due to either > > allocation from a free_list[] or alloc_contig_range() with param > > MIGRATE_MOVABLE. So it is enough to check on a single subpage > > by is_migrate_cma_page(subpage) > > > > Signed-off-by: Pingfan Liu > > Cc: Ira Weiny > > Cc: Andrew Morton > > Cc: Mike Rapoport > > Cc: Dan Williams > > Cc: Matthew Wilcox > > Cc: John Hubbard > > Cc: "Aneesh Kumar K.V" > > Cc: Keith Busch > > Cc: Christoph Hellwig > > Cc: Shuah Khan > > To: linux-mm@kvack.org > > Cc: linux-kernel@vger.kernel.org > > mm/gup.c | 26 +++++++++++++++++++------- > > 1 file changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/mm/gup.c b/mm/gup.c > > index cd8075e..f0d6804 100644 > > +++ b/mm/gup.c > > @@ -33,9 +33,21 @@ struct follow_page_context { > > * Return the compound head page with ref appropriately incremented, > > * or NULL if that failed. > > */ > > -static inline struct page *try_get_compound_head(struct page *page, int refs) > > +static inline struct page *try_get_compound_head(struct page *page, int refs, > > + unsigned int flags) > > { > > - struct page *head = compound_head(page); > > + struct page *head; > > + > > + /* > > + * Huge page's subpages have the same migrate type due to either > > + * allocation from a free_list[] or alloc_contig_range() with param > > + * MIGRATE_MOVABLE. So it is enough to check on a single subpage. > > + */ > > + if (unlikely(flags & FOLL_LONGTERM) && > > + is_migrate_cma_page(page)) > > + return NULL; > > This doesn't seem very good actually. > > If I understand properly, if the system has randomly decided to place, > say, an anonymous page in a CMA region when an application did mmap(), > then when the application tries to use this page with a LONGTERM pin > it gets an immediate failure because of the above. No, actually, it will fall back to slow path, which migrates and sever the LONGTERM pin. This patch just aims to fix the leakage in gup fast path, while in gup slow path, there is already logic to guard CMA against LONGTERM pin. > > This not OK - the application should not be subject to random failures > related to long term pins beyond its direct control. > > Essentially, failures should only originate from the application using > specific mmap scenarios, not randomly based on something the MM did, > and certainly never for anonymous memory. > > I think the correct action here is to trigger migration of the page so > it is not in CMA. In fact, it does this. The failure in gup fast path will fall back to slow path, where __gup_longterm_locked->check_and_migrate_cma_pages() does the migration. Thanks, Pingfan