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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 24F65C432BE for ; Wed, 1 Sep 2021 10:18: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 AB4B96102A for ; Wed, 1 Sep 2021 10:18:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AB4B96102A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E142B6E169; Wed, 1 Sep 2021 10:18:32 +0000 (UTC) Received: from pio-pvt-msa3.bahnhof.se (pio-pvt-msa3.bahnhof.se [79.136.2.42]) by gabe.freedesktop.org (Postfix) with ESMTPS id BF4BB6E171; Wed, 1 Sep 2021 10:18:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTP id 238573F3BA; Wed, 1 Sep 2021 12:18:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Authentication-Results: pio-pvt-msa3.bahnhof.se (amavisd-new); dkim=pass (1024-bit key) header.d=shipmail.org Received: from pio-pvt-msa3.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkRNpVQicIcb; Wed, 1 Sep 2021 12:18:28 +0200 (CEST) Received: by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTPA id 7FAC83F3AD; Wed, 1 Sep 2021 12:18:26 +0200 (CEST) Received: from [192.168.0.209] (unknown [192.198.151.52]) by mail1.shipmail.org (Postfix) with ESMTPSA id 7FFA53600BA; Wed, 1 Sep 2021 12:18:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1630491506; bh=ReO8qzvBhoEvdlzC1dSe6hXDRvAMR8muGSWBYNe+0w8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=afyZg0pDI8al5a9C/AaN5880LYKyML06ZgD+S6wxs0wGnqxc235cM+Ms3BMBw/MV6 XE8mIjVYHaQR5WSvrIiQd79g4J5G33RrLZxwqCncw2XArSq1aW1rpzJZHRDb9Nc3IY fyVcIvql6ylEtxluqObDuVhdJc7EVVntcx4qvOQE= Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) To: Jason Ekstrand , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= , Daniel Vetter References: <20210723172142.3273510-1-jason@jlekstrand.net> <20210723172142.3273510-8-jason@jlekstrand.net> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28Intel=29?= Message-ID: Date: Wed, 1 Sep 2021 12:18:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210723172142.3273510-8-jason@jlekstrand.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, Jason, A quick question below: On 7/23/21 7:21 PM, Jason Ekstrand wrote: > From: Thomas Hellström > > If our exported dma-bufs are imported by another instance of our driver, > that instance will typically have the imported dma-bufs locked during > dma_buf_map_attachment(). But the exporter also locks the same reservation > object in the map_dma_buf() callback, which leads to recursive locking. > > So taking the lock inside _pin_pages_unlocked() is incorrect. > > Additionally, the current pinning code path is contrary to the defined > way that pinning should occur. > > Remove the explicit pin/unpin from the map/umap functions and move them > to the attach/detach allowing correct locking to occur, and to match > the static dma-buf drm_prime pattern. > > Add a live selftest to exercise both dynamic and non-dynamic > exports. > > v2: > - Extend the selftest with a fake dynamic importer. > - Provide real pin and unpin callbacks to not abuse the interface. > v3: (ruhl) > - Remove the dynamic export support and move the pinning into the > attach/detach path. > v4: (ruhl) > - Put pages does not need to assert on the dma-resv > v5: (jason) > - Lock around dma_buf_unmap_attachment() when emulating a dynamic > importer in the subtests. > - Use pin_pages_unlocked > v6: (jason) > - Use dma_buf_attach instead of dma_buf_attach_dynamic in the selftests Why did we drop the dynamic importer from the selftests? Shouldn't we try to ensure compatibility with dynamic importers? /Thomas