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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BBBEC433EF for ; Tue, 7 Jun 2022 05:44:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234472AbiFGFon (ORCPT ); Tue, 7 Jun 2022 01:44:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233252AbiFGFom (ORCPT ); Tue, 7 Jun 2022 01:44:42 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5092BA57B; Mon, 6 Jun 2022 22:44:41 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id B899068BEB; Tue, 7 Jun 2022 07:44:37 +0200 (CEST) Date: Tue, 7 Jun 2022 07:44:37 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Alexander Gordeev , David Airlie , Tony Krowiak , Alex Williamson , Christian Borntraeger , Cornelia Huck , Daniel Vetter , dri-devel@lists.freedesktop.org, Eric Farman , Harald Freudenberger , Vasily Gorbik , Heiko Carstens , intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, Jani Nikula , Jason Herne , Joonas Lahtinen , kvm@vger.kernel.org, linux-s390@vger.kernel.org, Matthew Rosato , Peter Oberparleiter , Halil Pasic , Rodrigo Vivi , Sven Schnelle , Tvrtko Ursulin , Vineeth Vijayan , Zhenyu Wang , Zhi Wang , Christoph Hellwig Subject: Re: [PATCH 2/2] vfio: Replace the iommu notifier with a device list Message-ID: <20220607054437.GB8508@lst.de> References: <0-v1-896844109f36+a-vfio_unmap_notif_jgg@nvidia.com> <2-v1-896844109f36+a-vfio_unmap_notif_jgg@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2-v1-896844109f36+a-vfio_unmap_notif_jgg@nvidia.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On Mon, Jun 06, 2022 at 09:34:36PM -0300, Jason Gunthorpe wrote: > + if (!list_empty(&iommu->device_list)) { > + mutex_lock(&iommu->device_list_lock); > + mutex_unlock(&iommu->lock); > + > + list_for_each_entry(device, > + &iommu->device_list, > + iommu_entry) > + device->ops->dma_unmap( > + device, dma->iova, dma->size); > + > + mutex_unlock(&iommu->device_list_lock); > + mutex_lock(&iommu->lock); > + } I wonder if factoring this into a little helper instead of the very deep indentation might be a bit better for readability. > +static void vfio_iommu_type1_register_device(void *iommu_data, > + struct vfio_device *vdev) > { > struct vfio_iommu *iommu = iommu_data; > > + if (!vdev->ops->dma_unmap) > + return; > > + mutex_lock(&iommu->lock); > + mutex_lock(&iommu->device_list_lock); > + list_add(&vdev->iommu_entry, &iommu->device_list); > + mutex_unlock(&iommu->device_list_lock); > + mutex_unlock(&iommu->lock); Why do we need both iommu->lock and the device_list_lock everywhere? Maybe explain the locking scheme somewhere so that people don't have to guess, because it seems to me that just using iommu->lock would be enough right now. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id AAF6BC43334 for ; Tue, 7 Jun 2022 05:53:37 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7BBD311A1E6; Tue, 7 Jun 2022 05:53:32 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by gabe.freedesktop.org (Postfix) with ESMTPS id 14A1389CE3; Tue, 7 Jun 2022 05:53:31 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id B899068BEB; Tue, 7 Jun 2022 07:44:37 +0200 (CEST) Date: Tue, 7 Jun 2022 07:44:37 +0200 From: Christoph Hellwig To: Jason Gunthorpe Message-ID: <20220607054437.GB8508@lst.de> References: <0-v1-896844109f36+a-vfio_unmap_notif_jgg@nvidia.com> <2-v1-896844109f36+a-vfio_unmap_notif_jgg@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2-v1-896844109f36+a-vfio_unmap_notif_jgg@nvidia.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [Intel-gfx] [PATCH 2/2] vfio: Replace the iommu notifier with a device list 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: kvm@vger.kernel.org, David Airlie , dri-devel@lists.freedesktop.org, Vineeth Vijayan , Alexander Gordeev , Christoph Hellwig , linux-s390@vger.kernel.org, Matthew Rosato , Halil Pasic , Christian Borntraeger , intel-gfx@lists.freedesktop.org, Jason Herne , Eric Farman , Vasily Gorbik , Heiko Carstens , Harald Freudenberger , Rodrigo Vivi , intel-gvt-dev@lists.freedesktop.org, Tony Krowiak , Cornelia Huck , Peter Oberparleiter , Sven Schnelle Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, Jun 06, 2022 at 09:34:36PM -0300, Jason Gunthorpe wrote: > + if (!list_empty(&iommu->device_list)) { > + mutex_lock(&iommu->device_list_lock); > + mutex_unlock(&iommu->lock); > + > + list_for_each_entry(device, > + &iommu->device_list, > + iommu_entry) > + device->ops->dma_unmap( > + device, dma->iova, dma->size); > + > + mutex_unlock(&iommu->device_list_lock); > + mutex_lock(&iommu->lock); > + } I wonder if factoring this into a little helper instead of the very deep indentation might be a bit better for readability. > +static void vfio_iommu_type1_register_device(void *iommu_data, > + struct vfio_device *vdev) > { > struct vfio_iommu *iommu = iommu_data; > > + if (!vdev->ops->dma_unmap) > + return; > > + mutex_lock(&iommu->lock); > + mutex_lock(&iommu->device_list_lock); > + list_add(&vdev->iommu_entry, &iommu->device_list); > + mutex_unlock(&iommu->device_list_lock); > + mutex_unlock(&iommu->lock); Why do we need both iommu->lock and the device_list_lock everywhere? Maybe explain the locking scheme somewhere so that people don't have to guess, because it seems to me that just using iommu->lock would be enough right now.