On Wed, Feb 17, 2021 at 08:26:30AM +0100, Heiner Kallweit wrote:

On 17.02.2021 00:59, Chaitanya Kulkarni wrote:

quoted

On 2/14/21 08:30, Heiner Kallweit wrote:

quoted

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@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.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme