[PATCH] nvme: use lighter smp barriers in nvme_irq

[Keith Busch]

On Wed, Feb 17, 2021 at 08:26:30AM +0100, Heiner Kallweit wrote:
> On 17.02.2021 00:59, Chaitanya Kulkarni wrote:
> > On 2/14/21 08:30, Heiner Kallweit wrote:
> >> Based on the description we should be fine using the less heavy-weight
> >> smp barriers here. On x86 this would be compiler barriers only.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1 at gmail.com>
> > Can you share performance numbers ?
> > 
> 
> I stumbled across this code piece by chance and don't have hw to test it.
> Having said that the change is based on code inspection only.
> Unfortunately the barrier comment is very generic and doesn't mention
> a problematic scenario. Also the commit message of 3a7afd8ee42a doesn't
> mention a potential race. Most likely the barrier can be removed
> completely. Helpful would be if someone could explain the potential race
> in detail, means which reordering / variable accesses could be racy.
> Then we would have a basis to talk about READ_ONCE/WRITE_ONCE vs.
> smp barrier vs. dma barrier vs. full barrier.

The variables the driver was protecting no longer exist, so I also agree
the barriers should not be necessary.