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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 D9F21C388F9 for ; Sun, 1 Nov 2020 10:31:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8EE62071E for ; Sun, 1 Nov 2020 10:31:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="PXdr311j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8EE62071E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 45C826B005C; Sun, 1 Nov 2020 05:31:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 40C186B006C; Sun, 1 Nov 2020 05:31:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 322706B006E; Sun, 1 Nov 2020 05:31:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 06A7B6B005C for ; Sun, 1 Nov 2020 05:31:02 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 94BDB8249980 for ; Sun, 1 Nov 2020 10:31:02 +0000 (UTC) X-FDA: 77435481564.14.quill18_0f01e60272a6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 760C618229818 for ; Sun, 1 Nov 2020 10:31:02 +0000 (UTC) X-HE-Tag: quill18_0f01e60272a6 X-Filterd-Recvd-Size: 5938 Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Sun, 1 Nov 2020 10:31:01 +0000 (UTC) Received: by mail-ot1-f68.google.com with SMTP id k3so9869448otp.1 for ; Sun, 01 Nov 2020 02:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cMohUdqA3mHu1aHkJyF+q3c+LPomnH+bJbyOS5Pjj34=; b=PXdr311jw4o1TK1cA/6mrlvkDVtMBlyy1XYbMpIt3vJC7ClXj7DZJYo+vKllfO49H/ YgcjzcGc1VpCnfRMFbloI4quCQ5ndPF+idmxEJoWrUJWkpgS76TUc1DHlMSxRDqofJvd l2sKUL2WW0wKA2NYOf2SZx1Y6sFEl/LXBFDeg= 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=cMohUdqA3mHu1aHkJyF+q3c+LPomnH+bJbyOS5Pjj34=; b=Rm+pCUyg5gSfNkPXmX2Zcampe9EoyjwwCbk57LPBpeddaDi8/NyjPMSa7OXfnuaL+b ZdVBpJ6DxbAAkrlZRsUkKqKhYzR7E9ihUFzatkjr/wMOjeuDkIG1Uy+KxQVhrpqYn3id ISc5MpSqoaB9U6TPdlYxHmnrRZKUgFOK6cIPk1bGHiKAByr7LDma6PjVWU7sP1+K6UeL EGzc/0skpvh7kGMlPcJDh0wtvZ1FZM3JskIx3RX7UYSMljerxClHMd6/J4Ciroe4LFxN MGpI7q2Zm4BuzCap/j7eO9CgRgD1UaxnBnAs/nTIF8VlSDOIM/RQtE2oiPQWkxqapeB0 12gg== X-Gm-Message-State: AOAM533B8UxKc8Lqdp0uozJsf80Cg8+2AE1ODdW6ryrUB6roCXXe5eiJ b8Gd7mas5kVTKIa+sHwZ859bk4Y/T4aPO3b9tXS32g== X-Google-Smtp-Source: ABdhPJxxfl/j7Y56O7SvvjDInbgd1Huz0SnDjNzTDNqX3oHxJ8qJKEvsr7nAV6GfCrUUP0r8bqY++IYBOL0aDpBKvjo= X-Received: by 2002:a05:6830:1647:: with SMTP id h7mr8739299otr.281.1604226660644; Sun, 01 Nov 2020 02:31:00 -0800 (PST) MIME-Version: 1.0 References: <20201030100815.2269-1-daniel.vetter@ffwll.ch> <20201030100815.2269-6-daniel.vetter@ffwll.ch> <446b2d5b-a1a1-a408-f884-f17a04b72c18@nvidia.com> <1f7cf690-35e2-c56f-6d3f-94400633edd2@nvidia.com> In-Reply-To: <1f7cf690-35e2-c56f-6d3f-94400633edd2@nvidia.com> From: Daniel Vetter Date: Sun, 1 Nov 2020 11:30:49 +0100 Message-ID: Subject: Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM To: John Hubbard Cc: DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , Daniel Vetter , Jason Gunthorpe , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Tomasz Figa , Mauro Carvalho Chehab , Andrew Morton , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Dan Williams 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 Sun, Nov 1, 2020 at 6:22 AM John Hubbard wrote: > > On 10/31/20 7:45 AM, Daniel Vetter wrote: > > On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote: > >> On 10/30/20 3:08 AM, Daniel Vetter wrote: > ... > >> By removing this check from this location, and changing from > >> pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up > >> losing the check entirely. Is that intended? If so it could use a comment > >> somewhere to explain why. > > > > Yeah this wasn't intentional. I think I needed to drop the _locked > > version to prep for FOLL_LONGTERM, and figured _fast is always better. > > But I didn't realize that _fast doesn't have the vma checks, gup.c got > > me a bit confused. > > Actually, I thought that the change to _fast was a very nice touch, btw. > > > > > I'll remedy this in all the patches where this applies (because a > > VM_IO | VM_PFNMAP can point at struct page backed memory, and that > > exact use-case is what we want to stop with the unsafe_follow_pfn work > > since it wreaks things like cma or security). > > > > Aside: I do wonder whether the lack for that check isn't a problem. > > VM_IO | VM_PFNMAP generally means driver managed, which means the > > driver isn't going to consult the page pin count or anything like that > > (at least not necessarily) when revoking or moving that memory, since > > we're assuming it's totally under driver control. So if pup_fast can > > get into such a mapping, we might have a problem. > > -Daniel > > > > Yes. I don't know why that check is missing from the _fast path. > Probably just an oversight, seeing as how it's in the slow path. Maybe > the appropriate response here is to add a separate patch that adds the > check. > > I wonder if I'm overlooking something, but it certainly seems correct to > do that. You'll need the mmap_sem to get at the vma to be able to do this check. If you add that to _fast, you made it as fast as the slow one. Plus there's _fast_only due to locking recurion issues in fast-paths (I assume, I didn't check all the callers). I'm just wondering whether we have a bug somewhere with device drivers. For CMA regions we always check in try_grab_page, but for dax I'm not seeing where the checks in the _fast fastpaths are, and that all still leaves random device driver mappings behind which aren't backed by CMA but still point to something with a struct page behind it. I'm probably just missing something, but no idea what. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch