linux-kernel - Re: [PATCH vfio 1/2] hisi_acc_vfio_pci: Change reset_lock to mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2023 20:46:12 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
Cc:     Brett Creeley <brett.creeley@....com>,
        "yishaih@...dia.com" <yishaih@...dia.com>,
        liulongfang <liulongfang@...wei.com>,
        "kevin.tian@...el.com" <kevin.tian@...el.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "shannon.nelson@....com" <shannon.nelson@....com>
Subject: Re: [PATCH vfio 1/2] hisi_acc_vfio_pci: Change reset_lock to
 mutex_lock

On Fri, Nov 24, 2023 at 08:46:58AM +0000, Shameerali Kolothum Thodi wrote:
> > diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > index b2f9778c8366..2c049b8de4b4 100644
> > --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> > @@ -638,17 +638,17 @@ static void
> >  hisi_acc_vf_state_mutex_unlock(struct hisi_acc_vf_core_device
> > *hisi_acc_vdev)
> >  {
> >  again:
> > -	spin_lock(&hisi_acc_vdev->reset_lock);
> > +	mutex_lock(&hisi_acc_vdev->reset_mutex);
> >  	if (hisi_acc_vdev->deferred_reset) {
> >  		hisi_acc_vdev->deferred_reset = false;
> > -		spin_unlock(&hisi_acc_vdev->reset_lock);
> > +		mutex_unlock(&hisi_acc_vdev->reset_mutex);
> 
> Don't think we have that sleeping while atomic case for this here.
> Same for mlx5 as well. But if the idea is to have a common locking
> across vendor drivers, it is fine.

Yeah, I'm not sure about changing spinlocks to mutex's for no reason..
If we don't sleep and don't hold it for very long then the spinlock is
appropriate

Jason