There are two cases:

1. If you bounce, then the sync is not guaranteed to see a consistent snapshot of data (though in practice, due to the alignment of the data, an optimised memcpy will do word-by-word copies and thus you'll at least get cid+status consistent on 32-bit architectures, and sqhd+sqid+cid+status consistent on 64-bit architectures, as they for naturally aligned machine words). This is not the normal case (and there are other issues currently with bouncing, ignoring speed).

2. If you don't bounce, which is what happens in practice everywhere for NVMe (going fast is kinda the point), the sync is just a fence, but that does nothing to enforce the order in which you read the fields of the entry itself. A sync before the first read, which we do way above the loop, ensures you see the entries in the queue that triggered this interrupt, but because we loop (or, given the nature of interrupts, this could be spurious, or delayed and we already processed the entries that caused it, so it'd still be possible without the loop, just rarer) we could see new entries in the completion queue that were written after that sync.

Pictorially (ignoring fields other than CID+STATUS):

Host                  Drive

                   Write A.CID
                        |
                        V
                  Write A.STATUS
                        |
                        V
               +--- Send IRQ
               |        |
Receive IRQ <--+        |
     |                  |
     V                  |
   Sync                 |
     |                  |
     V                  |
 Read A.CID             |
     |                  |
     V                  |
Read A.STATUS           |
     |                  |
     V                  |
  Process               |
     |                  |
     V                  |
Read B.CID              |
     |                  V
     |             Write B.CID
     |                  |
     |                  V
     |            Write B.STATUS
     V
Read B.STATUS

is currently possible due to the lack of ordering between status and cid reads.

On x86/arm/arm64 both GCC and Clang are happy using unaligned loads to copy packed structs (which all the nvme ones are), but on riscv it will use byte loads as unaligned loads, whilst supported, may be emulated by firmware, causing performance to tank.

Since cid and status are in the same 32-bit word, and in reality the struct _is_ aligned, this means it happens to always be atomic on x86/arm/arm64 so you never see cid and status be inconsistent (e.g. disassembling a 12.2-RELEASE-p1 amd64 kernel I can see it just doing to movq loads and two movq stores).

You'd be able to get away with it on 64-bit architectures, but it's not just cid we need, we also need sqhd, which is in a different 32-bit word, though the same 64-bit word. Marking it as aligned is a good idea anyway to avoid the horrendous codegen currently seen on riscv, but it's not a complete fix.

If this weren't using busdma I'd just use an atomic_load_acq_16 on status and that'd be that...