Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Thu, 12 Oct 2023 10:50:16 -0300
From:   Jason Gunthorpe <jgg@ziepe.ca>
To:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc:     Brett Creeley <brett.creeley@amd.com>,
        "yishaih@nvidia.com" <yishaih@nvidia.com>,
        "kevin.tian@intel.com" <kevin.tian@intel.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "dan.carpenter@linaro.org" <dan.carpenter@linaro.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "shannon.nelson@amd.com" <shannon.nelson@amd.com>
Subject: Re: [PATCH v2 vfio 2/3] pds/vfio: Fix mutex lock->magic != lock
 warning
Message-ID: <20231012135016.GJ55194@ziepe.ca>
References: <20231011230115.35719-1-brett.creeley@amd.com>
 <20231011230115.35719-3-brett.creeley@amd.com>
 <591f90f071454dcd82d8de1178241e3c@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <591f90f071454dcd82d8de1178241e3c@huawei.com>
Precedence: bulk

On Thu, Oct 12, 2023 at 09:00:09AM +0000, Shameerali Kolothum Thodi wrote:

> > Also, don't destroy the mutex on close because the device may
> > be re-opened, which would cause mutex to be uninitialized. Fix this by
> > implementing a driver specific vfio_device_ops.release callback that
> > destroys the mutex before calling vfio_pci_core_release_dev().
> > 
> > Signed-off-by: Brett Creeley <brett.creeley@amd.com>
> > Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
> 
> Reviewed-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> 
> Looks like mutex destruction logic needs to be added to HiSilicon driver as well.
> From a quick look mlx5 also doesn't destroy the state_mutex.

FWIW, mutex_destroy is a debugging feature, it is nice if you can do it, but
not a bug if it is missing..

Jason