Re: [PATCH v7 6/7] scsi: mvumi: validate the response frame tag before using it

[Yehyeong Lee]

Thanks for the review. None of these are regressions introduced by this
series; I verified each against the base tree.

Endianness (this patch and 5/7): the driver does no device-to-host endian
conversion anywhere -- these fields are plain u16 and are used natively
throughout (e.g. host->max_id = mhba->max_target_id, tag_pool.size =
mhba->max_io). The new checks read the same values the driver already
consumes, so they follow the existing convention rather than change it.
Making the driver big-endian-correct would be a driver-wide __le
conversion, which is a separate change. I'll note that on a big-endian
build the base driver silently accepts a byte-swapped count and scans
phantom targets; patch 5 turns that into an explicit probe failure.

MV9580 / per-completion udelay: the unconditional request_id comparison in
mvumi_receive_ob_list_entry() is pre-existing. This patch only wraps the
reads in READ_ONCE(), fixes the > to >= off-by-one, and localizes the tag;
the comparison itself is unchanged. The new re-check I add in the
completion handler is gated by request_id_enabled, matching the existing
gate in mvumi_check_ob_frame(), so a controller that leaves the flag clear
is unaffected.

dma_rmb(): the validate-then-memcpy ordering is unchanged from the base.
The ownership handshake here is the MMIO copy pointer read with ioread32()
in mvumi_check_ob_list_9143()/_9580(), which already carries the
architecture's read barrier, not the tag. The driver's own comment notes an
entry "may point to [an] entry in [the] outbound list before [the] entry
has valid data", so the tag can itself be stale; ordering the tag read
ahead of the payload read would not help, and a CPU barrier cannot make a
not-yet-DMAed payload arrive. I don't think a dma_rmb() here is correct
without a firmware write-ordering guarantee I can't establish from the
tree.

tombstone tag 0xff vs max_io > 255: correct, and pre-existing --
max_io_support is not bounded and the 0xff sentinel can alias a valid tag.
This series does not introduce it (the re-check reads the dequeued copy
before the sentinel is written), but the defect is real; I'll send a
follow-up that stamps the consumed entry with 0xffff, which is always
outside the u16 tag range, once this series lands.