Message ID | 20230529223935.2672495-1-dmitry.osipenko@collabora.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp1807274vqr; Mon, 29 May 2023 15:52:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5UzYtJA3TSBLP+1WVZn+8Egh0rJz9fheKP1X6dBezTAYurk/qV2hzHixWVPP3+a7HjYWS7 X-Received: by 2002:a05:6a20:2451:b0:10b:bf2d:71bb with SMTP id t17-20020a056a20245100b0010bbf2d71bbmr406880pzc.27.1685400725724; Mon, 29 May 2023 15:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685400725; cv=none; d=google.com; s=arc-20160816; b=okWix6JFOLASV+iM9uTxqOhOhmM8nMxzozKLzB7aFqm84Eh5W6v6BWXKEjJ/jarGuS zQGSD+6vdmbiBic5em2i4Ca2o672akbd170cmyzox5jA/g7yiTENnZVlEMiA+jgKyTvB larjRf9GcKryh6KR+LingEvQPoto6WVdvpS5kbxGQ/n7yA0IG6dDySy5T/BhLaSpn45M LgnnIATj6gaDDxaZUUvO2UfFUBJY4Slc84wgC5nsUktemu/g9JyHj5MNRsSb9eK2U3lR Lw7K2BRzBISzqhnRsb8QJrjBuY8Yl5X6kNJhHZhSOkVvWHM8WhT/dn0bci9r3Pl88hQQ TksQ== 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=QOKwlema9h3dIjPZswil3h8vbktvHrNNGRG34wQgzPE=; b=rPwi84gC0MpkUjPX80XdPKExJSEmY3YAQRs4X9B7uycgpQJ9h0HwODi/apg2r3QRvb ThVcWAXlf/Kt2yXyCufnC69vgMrquH+9uThZrYvYs2DnwtQSmArUSGaRAgQ2WXybgDUm +SZLdsADr6hC7FJp8TVbUwYHjPXTSDoFt2TyXAsLkArWeBGy/hnkcxMZDaRPL1O/7pwl LOCH636sfFvjn0TvArtXvk5BzcmFLYqbppLpXrKcafusB9KTBBJrEBYhYjX3fxkQPbmX xSi6Yr6hjaxcgSyUCZsqRVVxHwanLlKcFj1x9oMfCk5va9CHyX//UnPkCcTUnbBwGFkQ t4rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=faMfm4Xp; 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 4-20020a630204000000b0053f9a37c607si1263868pgc.711.2023.05.29.15.51.53; Mon, 29 May 2023 15:52:05 -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=faMfm4Xp; 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 S229461AbjE2WqT (ORCPT <rfc822;callmefire3@gmail.com> + 99 others); Mon, 29 May 2023 18:46:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229772AbjE2WqQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 29 May 2023 18:46:16 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DD9EEC; Mon, 29 May 2023 15:46:09 -0700 (PDT) Received: from workpc.. (109-252-150-34.dynamic.spd-mgts.ru [109.252.150.34]) (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 8BD46660217A; Mon, 29 May 2023 23:46:06 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1685400368; bh=N/iL1JRZHbQ9J5wEpHGjUIuREtcko5e+/wiJaOIi8L4=; h=From:To:Cc:Subject:Date:From; b=faMfm4XpdfToTxpu3jT424GwfpAwTcRALVJbPia7nobOTK4KdKtdeUe+SlfmvgfUZ QRk9lDQA1yvalx230xcPasAAqkZKbr5DtHewOxourFeUyLQ5bXDGF37PgKJ9kvDI3U EO7hBjoXzDiDOnEumIfe4pQazIy/Q/O06CP+k7EZT0Q6bEMjTLgQNZmIUxKRLTGQRW +7h25FSiVbycEBPTJGM2iKahpEpbwCIhIr072NGyAppUyrs7UK0Ju+3QR67LgYQdON bha23Hn57uvoGHGEUxiH/xyjLTcELOdOQAoaZA0OYjQXxxnC84UNh/pZX4NqBtlF9a CETKWVEJ9TUuQ== From: Dmitry Osipenko <dmitry.osipenko@collabora.com> To: Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, Benjamin Gaignard <benjamin.gaignard@collabora.com>, Brian Starkey <Brian.Starkey@arm.com>, John Stultz <jstultz@google.com>, Gerd Hoffmann <kraxel@redhat.com>, Daniel Vetter <daniel@ffwll.ch>, Jani Nikula <jani.nikula@linux.intel.com>, Arnd Bergmann <arnd@arndb.de>, Thomas Zimmermann <tzimmermann@suse.de>, Tomi Valkeinen <tomba@kernel.org>, Thierry Reding <thierry.reding@gmail.com>, Tomasz Figa <tfiga@chromium.org>, Marek Szyprowski <m.szyprowski@samsung.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Emil Velikov <emil.l.velikov@gmail.com> 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, kernel@collabora.com Subject: [PATCH v4 0/6] Move dma-buf mmap() reservation locking down to exporters Date: Tue, 30 May 2023 01:39:29 +0300 Message-Id: <20230529223935.2672495-1-dmitry.osipenko@collabora.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767270751652681118?= X-GMAIL-MSGID: =?utf-8?q?1767270751652681118?= |
Series |
Move dma-buf mmap() reservation locking down to exporters
|
|
Message
Dmitry Osipenko
May 29, 2023, 10:39 p.m. UTC
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 Changelog: v4: - Added dma_resv_assert_held() to drm_gem_shmem_get_pages(), making assert consistent with the put() variant. Suggested by Emil Velikov. v3: - Added r-b from Hans Verkuil to the videobuf2 patch. - The v2 fastrpc patch was already applied, not including it anymore. Though, the cover-letter says that I'd want to apply all the patches via the drm-misc tree to keep the proper ordering of the changes. - Previously Intel's CI gave a flake failure to v2, want to re-test it again. v2: - Added ack from Christian König to the DRM patch. - Dropped "fixes" tag from the patches, like was requested by Christian König. The patches don't actually need a backport and merely improve the locking policy. - Dropped "reverts" from the patch titles to prevent them from auto-backporting by the stable bot based on the title. - Added r-b from Emil Velikov and placed the drm_WARN in the drm-shmem patch like he suggested in a comment to v1. - Corrected drm-shmem patch dma_resv_lock(obj->resv) inconsistently used with dma_resv_unlock(shmem->base.resv). Now shmem->base.resv variant is used for all locks/unlocks. Dmitry Osipenko (6): media: videobuf2: Don't assert held reservation lock for dma-buf mmapping dma-buf/heaps: Don't assert held reservation lock for dma-buf mmapping udmabuf: Don't assert held reservation lock for dma-buf mmapping drm: Don't 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 | 210 ++++++++---------- 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 - include/drm/drm_gem_shmem_helper.h | 14 +- 17 files changed, 119 insertions(+), 187 deletions(-)
Comments
On 5/30/23 01:39, Dmitry Osipenko wrote: > 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 Applied to misc-next