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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 9EE88C4363A for ; Mon, 12 Oct 2020 14:01:20 +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 127C220838 for ; Mon, 12 Oct 2020 14:01:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 127C220838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk 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 071056E434; Mon, 12 Oct 2020 14:01:18 +0000 (UTC) Received: from fireflyinternet.com (unknown [77.68.26.236]) by gabe.freedesktop.org (Postfix) with ESMTPS id DAC396E059; Mon, 12 Oct 2020 14:01:15 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 22691944-1500050 for multiple; Mon, 12 Oct 2020 15:01:11 +0100 MIME-Version: 1.0 In-Reply-To: References: <20201009102132.22770-1-chris@chris-wilson.co.uk> <160249974352.30484.764236348954464063@build.alporthouse.com> Subject: Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper From: Chris Wilson To: Daniel Vetter Date: Mon, 12 Oct 2020 15:01:09 +0100 Message-ID: <160251126986.3847.17805869986165580043@build.alporthouse.com> User-Agent: alot/0.9 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: intel-gfx , dri-devel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Quoting Daniel Vetter (2020-10-12 14:55:07) > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson wrote: > > > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > > userspace that may then be used as an in-memory surface and transported > > > > across dma-buf to other drivers. Since it's introduction, > > > > drm_gem_shmem_helper now provides the same shmemfs facilities and so we > > > > can trim vgem to wrap the helper. > > > > > > > > Signed-off-by: Chris Wilson > > > > --- > > > > drivers/gpu/drm/Kconfig | 1 + > > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 ++------------------------------ > > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > > > Nice diffstat :-) > > > > > > Reviewed-by: Daniel Vetter > > > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > > expectation is that we hand the faulthandler off to shmemfs so we can > > release the module while the memory is exported. > > That sounds like a broken igt. Once we have refcounting for > outstanding dma_fence/buf or anything else we'll block unloading of > the module (not unbinding of the driver). Which one is that? The dma-buf is closed; all that remains is the mmap. Then from the perspective of the module, there is no reference back to the module since we delegate handling of the mmap back to the owner, the shmemfs builtin. That allows us to remove the module as its object code is no longer required. -Chris _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 CEDFAC43457 for ; Mon, 12 Oct 2020 14:01:18 +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 582842080D for ; Mon, 12 Oct 2020 14:01:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 582842080D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BCD476E059; Mon, 12 Oct 2020 14:01:17 +0000 (UTC) Received: from fireflyinternet.com (unknown [77.68.26.236]) by gabe.freedesktop.org (Postfix) with ESMTPS id DAC396E059; Mon, 12 Oct 2020 14:01:15 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 22691944-1500050 for multiple; Mon, 12 Oct 2020 15:01:11 +0100 MIME-Version: 1.0 In-Reply-To: References: <20201009102132.22770-1-chris@chris-wilson.co.uk> <160249974352.30484.764236348954464063@build.alporthouse.com> From: Chris Wilson To: Daniel Vetter Date: Mon, 12 Oct 2020 15:01:09 +0100 Message-ID: <160251126986.3847.17805869986165580043@build.alporthouse.com> User-Agent: alot/0.9 Subject: Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx , dri-devel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Quoting Daniel Vetter (2020-10-12 14:55:07) > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson wrote: > > > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > > userspace that may then be used as an in-memory surface and transported > > > > across dma-buf to other drivers. Since it's introduction, > > > > drm_gem_shmem_helper now provides the same shmemfs facilities and so we > > > > can trim vgem to wrap the helper. > > > > > > > > Signed-off-by: Chris Wilson > > > > --- > > > > drivers/gpu/drm/Kconfig | 1 + > > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 ++------------------------------ > > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > > > Nice diffstat :-) > > > > > > Reviewed-by: Daniel Vetter > > > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > > expectation is that we hand the faulthandler off to shmemfs so we can > > release the module while the memory is exported. > > That sounds like a broken igt. Once we have refcounting for > outstanding dma_fence/buf or anything else we'll block unloading of > the module (not unbinding of the driver). Which one is that? The dma-buf is closed; all that remains is the mmap. Then from the perspective of the module, there is no reference back to the module since we delegate handling of the mmap back to the owner, the shmemfs builtin. That allows us to remove the module as its object code is no longer required. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx