netdev - Re: [PATCH V4 mlx5-next 13/13] vfio/mlx5: Use its own PCI reset

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] [day] [month] [year] [list]

Message-ID: <20211027165335.GF2744544@nvidia.com>
Date:   Wed, 27 Oct 2021 13:53:35 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Yishai Hadas <yishaih@...dia.com>, bhelgaas@...gle.com,
        saeedm@...dia.com, linux-pci@...r.kernel.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org, kuba@...nel.org, leonro@...dia.com,
        kwankhede@...dia.com, mgurtovoy@...dia.com, maorg@...dia.com
Subject: Re: [PATCH V4 mlx5-next 13/13] vfio/mlx5: Use its own PCI reset_done
 error handler

On Wed, Oct 27, 2021 at 10:48:55AM -0600, Alex Williamson wrote:

> Ok, I see.  I didn't digest that contention on state_mutex can only
> occur from a concurrent migration region access and the stale state is
> resolved at the end of that concurrent access, not some subsequent
> access.

Ah, I see, yes, that is tricky - the spinlock around the mutex
provides the guarentee: deferral cannot be set at mutex_lock() time.

Jason