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.9 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,USER_AGENT_GIT 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 AF50DC41604 for ; Wed, 7 Oct 2020 16:44:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 005D8206FC for ; Wed, 7 Oct 2020 16:44:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="LKBDOiNh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727948AbgJGQoe (ORCPT ); Wed, 7 Oct 2020 12:44:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727903AbgJGQoe (ORCPT ); Wed, 7 Oct 2020 12:44:34 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16FACC061755 for ; Wed, 7 Oct 2020 09:44:34 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id n15so2989348wrq.2 for ; Wed, 07 Oct 2020 09:44:34 -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=KC4M2Mj6QE/3vWDCCHDP9B0kSD2gsOBmeN66OBLosoQyu+xiW8N+aEh2IZs/JeHJTh gysMX8Korb8PMdjOMJiqWV2kHuMFbKm73jiKzJOcLnrG/hUhXvlrU9s+QWQQazzs1yOb /AcI7KMzKu6CuZ6tKBk8mxKBLsxfGxyyxwHu2+2IWXdw2C+K9CsGKIHO+VmF3hxMNCP2 PJ9H/0yb/MqgR+uqxL5wqbaubVJxABOtXBrUTxAXU1RrRrBftu4zHJ/JUpzMsRYH4sE7 3mpcBPNa2CLpwswq2QMtDpqgQyYFOM6sOXso7hThwJCfc3vlx23msCAhSIJ/yF494IHF Y5pQ== X-Gm-Message-State: AOAM5306Pa6U/qzBeR8RtUIa9RtHGEy8HQRuWIxAtGT5ONxo4/ektb3g aL29d/Ex+UyEAcyPsVMgqmO19Q== 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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%) -- 2.28.0 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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 D0960C4741F for ; Wed, 7 Oct 2020 16:46:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 52CFB206BE for ; Wed, 7 Oct 2020 16:46:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hUyiIG6C"; 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 52CFB206BE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=FCRLV6U3MTn95PMyNjSm+N0vO2vFXgzmXRXeIOmU5sY=; b=hUyiIG6Cceoy40w54E+MXtPgl3 0UxwhQGGwBINAYJqffojzmorlWERz7zWLv7zt9ct2sWbvEG4Jr5JPnxEFsnq4YWVguGzxK+0fqZAH HNg1wcEu7DzokQrQLmfHQDEwIuwzLxv5yjkfAmiqnEarRkqQm32iTXrFCIgyUwiCvrquKeMiIfWBm SVK4RN4YqLrn2xiwfoRK9+/WPwSV/Cv1loylqbC8fGstDbsmO9f7Gb/XO9vYCCl0X+yo8QgABC15X cMfmmeei8xzamCo3SgrskUH0+g4iu+zOo24VqlazZzMcFIzWoo1yVX1m3vE1Ul8gbRhk25nHvPwNr uT2Ez/VA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQCYQ-00017S-6w; Wed, 07 Oct 2020 16:44:38 +0000 Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQCYM-000158-5W for linux-arm-kernel@lists.infradead.org; Wed, 07 Oct 2020 16:44:35 +0000 Received: by mail-wr1-x441.google.com with SMTP id h7so2991595wre.4 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=aQkjs6pl95+x0Vpqa6qRJpOi3Yf+GR/hrZita3EJKBE4I9e6QG3LDDqB60QuV+FjK1 klzOuwblYtx7iLEfmqMwPcbnx5lxB/221ibayLkB1xG9IhJ7rghpxuvcLnWiJng6c3vS CTF8/sqcPGoNddHOObKItkc/IsVPi4iPAbkQ6BCV7LHyInxpRBPPPg6vToJKAdufFmZr xc5FSaHBj+Y3UNey20B8tLbWt6mjcksCI/CNje4YW6ybMHcX09NhjSGQCOFlVT0j0rws ViqxIRDqxFYIviL2tq6cchmcQz8d6nr+2Ch4uMVtTA9mXBuW7N3FWh5KnC7bBYwroW5P tPug== X-Gm-Message-State: AOAM532meXl0/jxCfCyrK1D0xCaHAxbvJ7xjSnUOIcG0NQoG7HEdOG2z 8fgyuaaRhaiF0wTMnvWK6EzKDg== 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 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201007_124434_395727_A129DC5F X-CRM114-Status: GOOD ( 18.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, kvm@vger.kernel.org, Daniel Vetter , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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%) -- 2.28.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 D2B1CC4727E for ; Wed, 7 Oct 2020 16:44:36 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4FDE5216C4 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 4FDE5216C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A4D1A6E0EB; Wed, 7 Oct 2020 16:44:35 +0000 (UTC) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by gabe.freedesktop.org (Postfix) with ESMTPS id 613E26E0EB for ; Wed, 7 Oct 2020 16:44:34 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id t10so3006430wrv.1 for ; Wed, 07 Oct 2020 09:44:34 -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=jkUc0/ugtUHyGHeBV8376cuUHVg4egbdrvPuyOFlicLEVBKJL1wyAnn+2rXItMRVhm /b14dy1oNOBO4Fb9a4OZyU7Jw74WJ7+H8+NzIhNHsxl6+m5YzbucXCZKHJIBQ0rIwZc4 lqRpPIjrSHuXrE+RDCHJfn6rMP8MS6bmy6uxos00vXzag46mNaTPHAnBOh8UkBuuPjI7 n1zAB9BijZsCimUR1kR9WbJNHdcdpT6TQRaZi0RzbHHZqLj6+QIsyDCpSoIk8KZh5iLR IBT0FMhHYtWYDZypKBI+qK5rgj4F0XKPP7uEZu+npOJxFnME3EZrsAsycDBbKj04kKY/ UixQ== X-Gm-Message-State: AOAM5314xm2dmppITMk1zgFcWsoQF9mmyKCLjYO6krDdG/Jexr5Uy7FF L79BH4spW5sqP9qvfjskN9BtsimOvV6M+C/A 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 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-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, kvm@vger.kernel.org, Daniel Vetter , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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%) -- 2.28.0 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel