> > On 10/6/26 3:21 AM, Jia Jia wrote: > > vhost_scsi_handle_vq() moves pi_bytesout and pi_bytesin into the > > protection sgl and subtracts them from exp_data_len. The length passed > > to TCM is still exp_data_len + prot_bytes. > > > > That sum matched an older target path which subtracted prot_length > > again. sbc_check_prot() now replaces data_length from the CDB only > > What patch changed this? Did all the drivers except vhost-scsi get fixed? >
I had that wrong. 9f977ef7b671 says target would subtract prot_length and points at 14ef9200. That commit is not in the tree, and the target code never subtracts prot_length. The in-tree behavior is e2a4f55c6498: if protect is non-zero, sbc_check_prot() sets data_length from the CDB. The vhost add has been there since 9f977ef7b671, in the same pull. Nothing later changed it. > > when the protect field is non-zero, and only for READ and WRITE. > > target_cmd_size_check() leaves a write's data_length unchanged when the > > CDB size is smaller. > > > > MODE SELECT, SET TARGET PORT GROUPS and UNMAP then use data_length as > > the size of t_data_sg. The PI bytes are not in that sgl. A parameter > > Can you have prot_bytes > 0 with those commands? I did not describe this clearly. MODE SELECT is not where prot_bytes comes from. With VIRTIO_SCSI_F_T10_PI negotiated, pi_bytesout can be set in virtio_scsi_cmd_req_pi, and vhost does not check that the CDB is a READ or WRITE. . A MODE SELECT sent with that field set hits this. That is what I ran.
