From patchwork Wed Oct 7 16:44:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11821065 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 27EC314D5 for ; Wed, 7 Oct 2020 16:44:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 350F5216C4 for ; Wed, 7 Oct 2020 16:44:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="LKBDOiNh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 350F5216C4 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 0BF2C6B005C; Wed, 7 Oct 2020 12:44:36 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id F12856B0062; Wed, 7 Oct 2020 12:44:35 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB15A6B0068; Wed, 7 Oct 2020 12:44:35 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id AFD1C6B005C for ; Wed, 7 Oct 2020 12:44:35 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 45E771EE6 for ; Wed, 7 Oct 2020 16:44:35 +0000 (UTC) X-FDA: 77345702910.15.money05_5b05ce1271d0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 1D5171814B0C1 for ; Wed, 7 Oct 2020 16:44:35 +0000 (UTC) X-Spam-Summary: 1,0,0,33d3f5ce0002e5a2,d41d8cd98f00b204,daniel.vetter@ffwll.ch,,RULES_HIT:41:152:355:379:541:968:973:988:989:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1543:1593:1594:1711:1730:1747:1777:1792:1801:2110:2194:2198:2199:2200:2393:2559:2562:2894:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:4605:5007:6119:6261:6653:7875:7903:10004:10400:11026:11658:11914:12043:12294:12296:12297:12517:12519:12679:12895:13071:13161:13229:13894:14096:14097:14180:14394:14659:14721:21060:21080:21444:21451:21627:21773:30012:30054:30056,0,RBL:209.85.221.67:@ffwll.ch:.lbl8.mailshell.net-66.201.201.201 62.8.0.100;04y8i3mjpthteoghqx9kq5sosrgntycpyo9xdj9x94e3hkb8q1iwztz97ggbowj.bssfrk6mt1468jbptf368orqtq8rwt7s6aci95k3469iryejiqfuy6uzyeurspd.w-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:177,LUA_SUMMARY:none X-HE-Tag: money05_5b05ce1271d0 X-Filterd-Recvd-Size: 5914 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 16:44:34 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id j2so2980012wrx.7 for ; Wed, 07 Oct 2020 09:44:33 -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:mime-version :content-transfer-encoding; bh=ioe0Byeg/DIJ2PK+KoHAeY/RgUBhGUsvQd2LPXMyjpk=; b=LKBDOiNhqwNLkwa9WP1zzXHrjwlM9UxdR+2aww5WQtbHhuceIwa/VXYYnC9UZ6hdtp mvYMFJ7UpZJyZnXE8eOz53fPGIesR/n7+X+8Z0F7CtzFKuDxeUJ2E389J/P0gE5voMHe oEJ9yMHSIcqvjSDbm4eT0/N3ZkXflXq1Fg4A8= 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:mime-version :content-transfer-encoding; bh=ioe0Byeg/DIJ2PK+KoHAeY/RgUBhGUsvQd2LPXMyjpk=; b=Ky0k9fFw62Ks+a2BZL/yB4A6YKqYFZ7h75Oi6QdUSKSDSNeh8oIxmhHcYYJ/JlojEY 18P8W0gNAmV8A9gWjY5nNDNxnHQJxW/b5eWtGwVi51zv5sr7N0CyYRB2LeZH8QX9o5LC +q9CP6Pg3aElwWaT4srqlFGhaTlu5YmgGboblV21KmnAXk1JXQsp7Wgkg7kEsEQGTwyT XJALB5g/ifiJcsmdPBYN2LAf4ZWRXTPYpsm5SBXwwPThFwHwB+FrTa91IHHd9KJ8buAg Mu+lAIGaJWEAkEmEJvy9cHBM/M1YAxOPgtw7Eylt7KXdN32oWq7ArX7U9atbGyO5M0tm WHIQ== X-Gm-Message-State: AOAM530RhUsEvrIQ4qleeAv1BtamPhACUYlCVAHp8pAfoVOwZ0z0XuB8 pCr49R5+MSABdLbjIjaiunq9jw== X-Google-Smtp-Source: ABdhPJzRELPHTJISw4N/fSU+gR/P4h8ZIocAzvLavw2ceiWiegfiQvvhsxcd+sZUYD7qwXN8jRsOdg== X-Received: by 2002:adf:e74d:: with SMTP id c13mr4372958wrn.45.1602089072696; Wed, 07 Oct 2020 09:44:32 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id z191sm3332280wme.40.2020.10.07.09.44.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2020 09:44:32 -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, linux-s390@vger.kernel.org, Daniel Vetter Subject: [PATCH 00/13] follow_pfn and other iomap races Date: Wed, 7 Oct 2020 18:44:13 +0200 Message-Id: <20201007164426.1812530-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 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: Hi all, This developed from a discussion with Jason, starting with some patches touching get_vaddr_frame that I typed up. The problem is that way back VM_IO | VM_PFNMAP mappings were pretty static, and so just following the ptes to derive a pfn and then use that somewhere else was ok. But we're no longer in such a world, there's tons of little races and some fundamental problems. This series here is an attempt to at least scope the problem, it's all the issues I've found with quite some code reading all over the tree: - first part tries to move mm/frame-vector.c away, it's fundamentally an unsafe thing - two patches to close follow_pfn races by holding pt locks - two pci patches where I spotted inconsinstencies between the 3 different ways userspace can map pci bars - and finally some patches to mark up the remaining issue No testing beyond "it compiles", this is very much an rfc to figure out whether this makes sense, whether it's a real thing, and how to fix this up properly. Cheers, Daniel Daniel Vetter (13): drm/exynos: Stop using frame_vector helpers drm/exynos: Use FOLL_LONGTERM for g2d cmdlists misc/habana: Stop using frame_vector helpers misc/habana: Use FOLL_LONGTERM for userptr mm/frame-vector: Use FOLL_LONGTERM media: videobuf2: Move frame_vector into media subsystem mm: close race in generic_access_phys s390/pci: Remove races against pte updates PCI: obey iomem restrictions for procfs mmap PCI: revoke mappings like devmem mm: add unsafe_follow_pfn media/videbuf1|2: Mark follow_pfn usage as unsafe vfio/type1: Mark follow_pfn as unsafe arch/s390/pci/pci_mmio.c | 98 +++++++++++-------- drivers/char/mem.c | 16 ++- drivers/gpu/drm/exynos/Kconfig | 1 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 49 +++++----- drivers/media/common/videobuf2/Kconfig | 1 - drivers/media/common/videobuf2/Makefile | 1 + .../media/common/videobuf2}/frame_vector.c | 40 +++----- drivers/media/platform/omap/Kconfig | 1 - drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- drivers/misc/habanalabs/Kconfig | 1 - drivers/misc/habanalabs/common/habanalabs.h | 3 +- drivers/misc/habanalabs/common/memory.c | 52 +++++----- drivers/pci/mmap.c | 3 + drivers/pci/proc.c | 5 + drivers/vfio/vfio_iommu_type1.c | 4 +- include/linux/ioport.h | 2 + include/linux/mm.h | 47 +-------- include/media/videobuf2-core.h | 42 ++++++++ mm/Kconfig | 3 - mm/Makefile | 1 - mm/memory.c | 76 +++++++++++++- mm/nommu.c | 17 ++++ security/Kconfig | 13 +++ 23 files changed, 296 insertions(+), 182 deletions(-) rename {mm => drivers/media/common/videobuf2}/frame_vector.c (90%)