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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 168D3C35257 for ; Fri, 2 Oct 2020 18:06:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 82E4D2085B for ; Fri, 2 Oct 2020 18:06:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="J7kgY6cw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82E4D2085B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C62AD900004; Fri, 2 Oct 2020 14:06:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BEDE9900002; Fri, 2 Oct 2020 14:06:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ADB7D900004; Fri, 2 Oct 2020 14:06:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 7C414900002 for ; Fri, 2 Oct 2020 14:06:06 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 140373631 for ; Fri, 2 Oct 2020 18:06:06 +0000 (UTC) X-FDA: 77327764332.11.aunt45_3b1628a271a6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id D2927180F8B81 for ; Fri, 2 Oct 2020 18:06:05 +0000 (UTC) X-HE-Tag: aunt45_3b1628a271a6 X-Filterd-Recvd-Size: 5766 Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Fri, 2 Oct 2020 18:06:05 +0000 (UTC) Received: by mail-qk1-f194.google.com with SMTP id w16so2352173qkj.7 for ; Fri, 02 Oct 2020 11:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=+LaXP0gz54Jegk2Sj4FZgrVo6ri43ZoIhALcEdceV7s=; b=J7kgY6cwrb58DOoexGugRCEp3mOA3N2SuE3K7Vkq5DNITA7cVKmdZqs7c/H8mPlIXn o8UTppelOaWj/A+mIwckLvjSUAU505SsEF3y1UzB63e8RdNoL/7u/+lTbA+W+QbJg49u gjsGdY/ede4W2O1vArxPiL2+QKZNSLtPznD4UnaDnr+9U1NqECZIyPugGKiO/byu4Wsr ZiE32MDkyDjSRgUA3y85ay+ogHthqSIXcOgCRKKR9TEo8YPT5+VwXEqNByR4xXZxn6eZ DL3Xo9PmsQDfglZGmXIoeYvA5RBCHAUhpl0ys8t6dV8rIql31yOwXhGQ93xvBlsHWoj8 tkUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=+LaXP0gz54Jegk2Sj4FZgrVo6ri43ZoIhALcEdceV7s=; b=ie+JrfEvSFpJgPYFo/iwxGB6Uu3o1ftkNpLae0YVTg49AMJmAolTjeEu3umjRpKuqP oN40XoeGWb28BuRhsRuljrCOCedTIhbGPuJPMtppWW3Qc7J4pHeFAHrR7+q4USqo5CUQ 3eJ4pD2Ahn2QvAlYCxwp27IW6mJFMkoQm4eVfOgf9DhMKj/lDzIBJqHcUR+XEkZV0Zrp mKe1PlsflHSTfj1/lAfVK3VKYAJdVnucDcivGDBO1KdUjlN1DLyYIEZ/bpV62mNES3/g ulUUNwUESKIu0YeBA2swalscd9gxjGgsU4acyETX2OiZvT60IUZQgqHJ1EJxRaUaRZk3 pp3w== X-Gm-Message-State: AOAM533aQs7/mjCCqTnOQ+0L6IY7UDn7o1iElgJv4NGjIBtqWTGH5mB9 /KY2O5U5Yl5r8I6hvp2N2MvpIQ== X-Google-Smtp-Source: ABdhPJxx4jEaLX4t/GDgPp9QrFZRDhny976xDexrly3ltPkHkc73Gz3CvOBBFQXoSMUgBgbH3LKfmw== X-Received: by 2002:ae9:f70d:: with SMTP id s13mr3396635qkg.215.1601661964700; Fri, 02 Oct 2020 11:06:04 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id i62sm1604038qkf.36.2020.10.02.11.06.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Oct 2020 11:06:04 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kOPRT-006GH8-H7; Fri, 02 Oct 2020 15:06:03 -0300 Date: Fri, 2 Oct 2020 15:06:03 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , John Hubbard , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Jan Kara , Dan Williams , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org Subject: Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM Message-ID: <20201002180603.GL9916@ziepe.ca> References: <20201002175303.390363-1-daniel.vetter@ffwll.ch> <20201002175303.390363-2-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201002175303.390363-2-daniel.vetter@ffwll.ch> Content-Transfer-Encoding: quoted-printable 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, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote: > For $reasons I've stumbled over this code and I'm not sure the change > to the new gup functions in 55a650c35fea ("mm/gup: frame_vector: > convert get_user_pages() --> pin_user_pages()") was entirely correct. >=20 > This here is used for long term buffers (not just quick I/O) like > RDMA, and John notes this in his patch. But I thought the rule for > these is that they need to add FOLL_LONGTERM, which John's patch > didn't do. >=20 > There is already a dax specific check (added in b7f0554a56f2 ("mm: > fail get_vaddr_frames() for filesystem-dax mappings")), so this seems > like the prudent thing to do. >=20 > Signed-off-by: Daniel Vetter > Cc: Andrew Morton > Cc: John Hubbard > Cc: J=C3=A9r=C3=B4me Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Hi all, >=20 > I stumbled over this and figured typing this patch can't hurt. Really > just to maybe learn a few things about how gup/pup is supposed to be > used (we have a bit of that in drivers/gpu), this here isn't really > ralated to anything I'm doing. FOLL_FORCE is a pretty big clue it should be FOLL_LONGTERM, IMHO > I'm also wondering whether the explicit dax check should be removed, > since FOLL_LONGTERM should take care of that already. Yep! Confirms the above! This get_vaddr_frames() thing looks impossible to use properly. How on earth does a driver guarentee "If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures and the caller must make sure pfns aren't reused for anything else while he is using them." The only possible way to do that is if the driver restricts the VMAs to ones it owns and interacts with the vm_private data to refcount something. Since every driver does this wrong anything that uses this is creating terrifying security issues. IMHO this whole API should be deleted :( Jason