From patchwork Tue Mar 16 15:33:03 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 12142531 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=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 4177FC433DB for ; Tue, 16 Mar 2021 15:33:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EA33D650F4 for ; Tue, 16 Mar 2021 15:33:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA33D650F4 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 8ABE98D0013; Tue, 16 Mar 2021 11:33:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 882048D0001; Tue, 16 Mar 2021 11:33:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 723D28D0013; Tue, 16 Mar 2021 11:33:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 52AD78D0001 for ; Tue, 16 Mar 2021 11:33:34 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 048208142 for ; Tue, 16 Mar 2021 15:33:34 +0000 (UTC) X-FDA: 77926131948.11.54B5955 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by imf20.hostedemail.com (Postfix) with ESMTP id 837B13C8 for ; Tue, 16 Mar 2021 15:33:24 +0000 (UTC) Received: by mail-wr1-f45.google.com with SMTP id y16so10716711wrw.3 for ; Tue, 16 Mar 2021 08:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zwe0ekXmy9t5eNr3sFs9jCzA/xhMldV8JLAydoSdCfc=; b=GzG+edIxhOWO3e0C//e9ZTvwmWIMqXUh3qVGupEH1XpIfgojiM9nr7zfSbfVnLpEX1 TppZD/lYq2BFxWK6uExvqhTf4cGvOaXXXtjYXrDDvq/txY4i5BzARGuD/BQ+Nc/vZ9CP U43D7zJSOobDqMzHTu1jMNW+6MtVYMmXPpabc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zwe0ekXmy9t5eNr3sFs9jCzA/xhMldV8JLAydoSdCfc=; b=dUVdpbdCE8NGAuCDEHV0HhxLniIhfwUPKDvI8PYr5ZhUNw2Bx8VoqNlIILqwPqmahX L5aYt3nm6RhxOqrm9+ihT0o74uvqN/Vy+UuFQUxOSN4tdHwNHC8NKUFrpdhEjcfV8ExO +XiybiRrob7oaV84SUk/g2Xn9AvZii5iBohCOV6K/8DE5W1MVZ3+FWRF/zkCJu2ITzjs +s+Ee2QEJGgDy6UVqlzyVxGCVh+4VbweoBeR9V9gJceJQ1A5sXozMy6ctqOEogNqIEVu /x3ky8E5acHrwowAzCjzDlgOJLhb8zd7/3f8bcI4+KrB/nr00Qvd9R1nXEgr56NdX2zU asEA== X-Gm-Message-State: AOAM530Zl7MDicRpFiyf9ftCu7Q+zUWaXi/eFYtB+jolVJqumOWrw+8A hC2zb3ncxNNxIsgY/zm5wov6ig== X-Google-Smtp-Source: ABdhPJxsQT1ztD0lh1/0ccaL0ZTcHbZx32nTGgPOptwOia/Vap2jPDUXToCOLm5fL6HRJJsLfse8jA== X-Received: by 2002:adf:ec0b:: with SMTP id x11mr5396504wrn.175.1615908795642; Tue, 16 Mar 2021 08:33:15 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id h22sm3985078wmb.36.2021.03.16.08.33.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 08:33:15 -0700 (PDT) From: Daniel Vetter To: DRI Development , LKML Cc: kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, Daniel Vetter , 3pvd@google.com, Jann Horn , Paolo Bonzini , Jason Gunthorpe , Cornelia Huck , Peter Xu , Alex Williamson , Daniel Vetter Subject: [PATCH 3/3] mm: unexport follow_pfn Date: Tue, 16 Mar 2021 16:33:03 +0100 Message-Id: <20210316153303.3216674-4-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210316153303.3216674-1-daniel.vetter@ffwll.ch> References: <20210316153303.3216674-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 X-Stat-Signature: xyb6pp1xa9b8n81338tbhbg5tsmzms9u X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 837B13C8 Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mail-wr1-f45.google.com; client-ip=209.85.221.45 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615908804-393341 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: Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use follow_pte()")) have lost their callsites of follow_pfn(). All the other ones have been switched over to unsafe_follow_pfn because they cannot be fixed without breaking userspace api. Argueably the vfio code is still racy, but that's kinda a bigger picture. But since it does leak the pte beyond where it drops the pt lock, without anything else like an mmu notifier guaranteeing coherence, the problem is at least clearly visible in the vfio code. So good enough with me. I've decided to keep the explanation that after dropping the pt lock you must have an mmu notifier if you keep using the pte somehow by adjusting it and moving it into the kerneldoc for the new follow_pte() function. Cc: 3pvd@google.com Cc: Jann Horn Cc: Paolo Bonzini Cc: Jason Gunthorpe Cc: Cornelia Huck Cc: Peter Xu Cc: Alex Williamson 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 Cc: kvm@vger.kernel.org Signed-off-by: Daniel Vetter Reviewed-by: Jason Gunthorpe --- include/linux/mm.h | 2 -- mm/memory.c | 26 +++++--------------------- mm/nommu.c | 13 +------------ 3 files changed, 6 insertions(+), 35 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index caec8b25d66f..304588e2f829 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1693,8 +1693,6 @@ int follow_invalidate_pte(struct mm_struct *mm, unsigned long address, pmd_t **pmdpp, spinlock_t **ptlp); int follow_pte(struct mm_struct *mm, unsigned long address, pte_t **ptepp, spinlock_t **ptlp); -int follow_pfn(struct vm_area_struct *vma, unsigned long address, - unsigned long *pfn); int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address, unsigned long *pfn); int follow_phys(struct vm_area_struct *vma, unsigned long address, diff --git a/mm/memory.c b/mm/memory.c index e8a145505b69..317e653c8aeb 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4724,7 +4724,10 @@ int follow_invalidate_pte(struct mm_struct *mm, unsigned long address, * should be taken for read. * * KVM uses this function. While it is arguably less bad than ``follow_pfn``, - * it is not a good general-purpose API. + * it is not a good general-purpose API: If callers use the pte after they've + * unlocked @ptlp they must ensure coherency with pte updates by using a + * &mmu_notifier to follow updates. Any caller not following these requirements + * must use unsafe_follow_pfn() instead. * * Return: zero on success, -ve otherwise. */ @@ -4735,25 +4738,7 @@ int follow_pte(struct mm_struct *mm, unsigned long address, } EXPORT_SYMBOL_GPL(follow_pte); -/** - * follow_pfn - look up PFN at a user virtual address - * @vma: memory mapping - * @address: user virtual address - * @pfn: location to store found PFN - * - * Only IO mappings and raw PFN mappings are allowed. Note that callers must - * ensure coherency with pte updates by using a &mmu_notifier to follow updates. - * If this is not feasible, or the access to the @pfn is only very short term, - * use follow_pte_pmd() instead and hold the pagetable lock for the duration of - * the access instead. Any caller not following these requirements must use - * unsafe_follow_pfn() instead. - * - * This function does not allow the caller to read the permissions - * of the PTE. Do not use it. - * - * Return: zero and the pfn at @pfn on success, -ve otherwise. - */ -int follow_pfn(struct vm_area_struct *vma, unsigned long address, +static int follow_pfn(struct vm_area_struct *vma, unsigned long address, unsigned long *pfn) { int ret = -EINVAL; @@ -4770,7 +4755,6 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long address, pte_unmap_unlock(ptep, ptl); return 0; } -EXPORT_SYMBOL_GPL(follow_pfn); /** * unsafe_follow_pfn - look up PFN at a user virtual address diff --git a/mm/nommu.c b/mm/nommu.c index 1dc983f50e2c..cee29d0791b3 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -111,17 +111,7 @@ unsigned int kobjsize(const void *objp) return page_size(page); } -/** - * follow_pfn - look up PFN at a user virtual address - * @vma: memory mapping - * @address: user virtual address - * @pfn: location to store found PFN - * - * Only IO mappings and raw PFN mappings are allowed. - * - * Returns zero and the pfn at @pfn on success, -ve otherwise. - */ -int follow_pfn(struct vm_area_struct *vma, unsigned long address, +static int follow_pfn(struct vm_area_struct *vma, unsigned long address, unsigned long *pfn) { if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) @@ -130,7 +120,6 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long address, *pfn = address >> PAGE_SHIFT; return 0; } -EXPORT_SYMBOL_GPL(follow_pfn); /** * unsafe_follow_pfn - look up PFN at a user virtual address