From patchwork Sun Apr 2 16:48:19 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Osipenko X-Patchwork-Id: 7603 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1839087vqo; Sun, 2 Apr 2023 10:13:52 -0700 (PDT) X-Google-Smtp-Source: AKy350aQZr5wjxHw0mdwu6gMnKmQSSmQuL6VFEvpuZsxqsRMFkcEzF4BDsEwowl05A1d9kTrmV3e X-Received: by 2002:aa7:d713:0:b0:501:d52d:7f88 with SMTP id t19-20020aa7d713000000b00501d52d7f88mr31919853edq.10.1680455632111; Sun, 02 Apr 2023 10:13:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680455632; cv=none; d=google.com; s=arc-20160816; b=DjexTF/VRVcj5EGmR/Da7tOsgC8Ql8Tm5YqAe8MObZ8HK3YAFNBhYUxXWeawLSHH7M +L43PjMeWOxKtnOLp8Lt26lX6m8wE9lFRuSO0SAFJXmrriP0Lb3Nmq1VNrbt2LGThHGk 3D2gHze69DvMJH0i3NIqfuJVWS/8IYqG8QvXnif6K+tWlVZN9vawspCDNpswYZz8zBwf 5vXv2Mx/Nz1MyQrQORNtCVSxaFE4Z74tCSioftFoQiEFFbWpf8xT8OvqYu6ZF00yx7Z7 T6NtD59mRStud4O3zdJ+7g0ZMHKEbAqVfjzB3HsulMlc7t+SBlnq/vLdkA7eoM+ViH8o 0YXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=oKK3n+b0HqLgr0c0CzNQucNb5dE2k9uuRjxQeWpcN/M=; b=WUmnySFlLVkzLupBbmzuZR5NEaTRvZNP04EaBYihT/FSHBbk+GIkOfZpOdAGdmzqI0 kdB5YHRGR7baAyrvu/tXa/X2WuMGavjtz0re6eQijqhkDER15heqQGkcR2YCfPncW5Lj FUe/2zoYQ8FF+4xW0SJgg6CUbmh2oy/Ut8UyQ50mIV55ZO4ZfyJKxa53OKah22E5Cnhh 8Si6QRJDcwc4qM8VLysnf0kHo3u3dUs81hA/lOrrVjaR9uLE/IlK7YprasWNWfA51g6T bUSp99EAbqw86rULB1QSZjaesArXs/V2DIP5re+UGW6ye+cGf/BKgRAQ/rRM24dZ+509 Aw2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=PM3m6hys; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l8-20020aa7d948000000b004ad7933f8efsi5787501eds.618.2023.04.02.10.13.27; Sun, 02 Apr 2023 10:13:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=PM3m6hys; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230463AbjDBQtR (ORCPT + 99 others); Sun, 2 Apr 2023 12:49:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbjDBQtP (ORCPT ); Sun, 2 Apr 2023 12:49:15 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58963DBD0; Sun, 2 Apr 2023 09:49:14 -0700 (PDT) Received: from workpc.. (109-252-124-32.nat.spd-mgts.ru [109.252.124.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id 55288660209A; Sun, 2 Apr 2023 17:49:10 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1680454152; bh=kjTtuZafxqQ//qonolfaG0xTHClDJ/0hYqwWpo1/w0k=; h=From:To:Cc:Subject:Date:From; b=PM3m6hysogG6uCz7g8USUVA1IMYM+iGZA6+yIjQgSO72di64cd3XcPWbSoQK4u17A NF5dj16eH5qZED1KNKFanlRxxAm33kiySG/ZCfeQQZSLmMavJo8DDfRdGdUvPbwQz9 3nGTOktieV1US0uEoj0ZjpqwQ+9Ar6n/VfJlqv0TI7F33tXQfLmGOs0QruTBvHrey4 QVLQZR5Vhn6IF2ASDNZtrHeH/7STOxqrfwrMOLISeiNaNhPDHttDYeIQoC1TTNGYIr cf2lOEToXQJSC39ChYTfcECrx5g5hpr1s3eW8kQ/gWWgcrTeAi4enC2cynT8Psd2kT yJwrl4uuH9k8Q== From: Dmitry Osipenko To: Sumit Semwal , =?utf-8?q?Christian_K=C3=B6nig?= , Benjamin Gaignard , Liam Mark , Brian Starkey , John Stultz , Gerd Hoffmann , Daniel Vetter , Jani Nikula , Arnd Bergmann , Greg Kroah-Hartman , Thomas Zimmermann , Tomi Valkeinen , Thierry Reding , Tomasz Figa , Marek Szyprowski , Mauro Carvalho Chehab , Srinivas Kandagatla , Amol Maheshwari Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-arm-msm@vger.kernel.org, kernel@collabora.com Subject: [PATCH v1 0/7] Move dma-buf mmap() reservation locking down to exporters Date: Sun, 2 Apr 2023 19:48:19 +0300 Message-Id: <20230402164826.752842-1-dmitry.osipenko@collabora.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762085445050671296?= X-GMAIL-MSGID: =?utf-8?q?1762085445050671296?= This patchset makes dma-buf exporters responisble for taking care of the reservation lock. I also included patch that moves drm-shmem to use reservation lock, to let CI test the whole set. I'm going to take all the patches via the drm-misc tree, please give an ack. Previous policy stated that dma-buf core takes the lock around mmap() callback. Which meant that both importers and exporters shouldn't touch the reservation lock in the mmap() code path. This worked well until Intel-CI found a deadlock problem in a case of self-imported dma-buf [1]. The problem happens when userpace mmaps a self-imported dma-buf, i.e. mmaps the dma-buf FD. DRM core treats self-imported dma-bufs as own GEMs [2]. There is no way to differentiate a prime GEM from a normal GEM for drm-shmem in drm_gem_shmem_mmap(), which resulted in a deadlock problem for drm-shmem mmap() code path once it's switched to use reservation lock. It was difficult to fix the drm-shmem problem without adjusting dma-buf locking policy. In parctice not much changed from importers perspective because previosly dma-buf was taking the lock in between of importers and exporters. Now this lock is shifted down to exporters. [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114671v2/shard-snb5/igt@prime_vgem@sync@rcs0.html [2] https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/drm_prime.c#L924 Dmitry Osipenko (7): Revert "media: videobuf2: Assert held reservation lock for dma-buf mmapping" Revert "dma-buf/heaps: Assert held reservation lock for dma-buf mmapping" Revert "udmabuf: Assert held reservation lock for dma-buf mmapping" Revert "fastrpc: Assert held reservation lock for dma-buf mmapping" Revert "drm: Assert held reservation lock for dma-buf mmapping" dma-buf: Change locking policy for mmap() drm/shmem-helper: Switch to reservation lock drivers/dma-buf/dma-buf.c | 17 +- drivers/dma-buf/heaps/cma_heap.c | 3 - drivers/dma-buf/heaps/system_heap.c | 3 - drivers/dma-buf/udmabuf.c | 2 - drivers/gpu/drm/drm_gem_shmem_helper.c | 217 ++++++++---------- drivers/gpu/drm/drm_prime.c | 2 - drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 - drivers/gpu/drm/lima/lima_gem.c | 8 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 - drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +- .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +- drivers/gpu/drm/tegra/gem.c | 2 - .../common/videobuf2/videobuf2-dma-contig.c | 3 - .../media/common/videobuf2/videobuf2-dma-sg.c | 3 - .../common/videobuf2/videobuf2-vmalloc.c | 3 - drivers/misc/fastrpc.c | 3 - include/drm/drm_gem_shmem_helper.h | 14 +- 18 files changed, 123 insertions(+), 193 deletions(-)