scsi: qla2xxx: Fix memcpy() field-spanning write issue

purex_item.iocb is defined as a 64-element u8 array, but 64 is the
minimum size and it can be allocated larger. This makes it a standard
empty flex array.

This was motivated by field-spanning write warnings during FPIN testing:

https://lore.kernel.org/linux-nvme/20250709211919.49100-1-bgurney@redhat.com/



  >  kernel: memcpy: detected field-spanning write (size 60) of single field
  >  "((uint8_t *)fpin_pkt + buffer_copy_offset)"
  >  at drivers/scsi/qla2xxx/qla_isr.c:1221 (size 44)

I removed the outer wrapper from the iocb flex array, so that it can be
linked to 'purex_item.size' with '__counted_by'.

These changes remove the default minimum 64-byte allocation, requiring
further changes.

  In 'struct scsi_qla_host' the embedded 'default_item' is now followed
  by '__default_item_iocb[QLA_DEFAULT_PAYLOAD_SIZE]' to reserve space
  that will be used as 'default_item.iocb'. This is wrapped using the
  'TRAILING_OVERLAP()' macro helper, which effectively creates a union
  between flexible-array member 'default_item.iocb' and
  '__default_item_iocb'.

  Since 'struct pure_item' now contains a flexible-array member, the
  helper must be placed at the end of 'struct scsi_qla_host' to prevent
  a '-Wflex-array-member-not-at-end' warning.

  'qla24xx_alloc_purex_item()' is adjusted to no longer expect the
  default minimum size to be part of 'sizeof(struct purex_item)', the
  entire flexible array size is added to the structure size for
  allocation.

This also slightly changes the layout of the purex_item struct, as
2-bytes of padding are added between 'size' and 'iocb'. The resulting
size is the same, but iocb is shifted 2-bytes (the original 'purex_item'
structure was padded at the end, after the 64-byte defined array size).
I don't think this is a problem.

Tested-by: Bryan Gurney <bgurney@redhat.com>
Co-developed-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20250813200744.17975-10-bgurney@redhat.com


Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>