On Thu, 22 Jul 2021 11:03:02 +0000, Sergey Samoylenko wrote:

Hi David,

quoted

Hi Sergey,

On Thu, 24 Jun 2021 14:19:25 +0300, Sergey Samoylenko wrote:
 

quoted

EXTENDED COPY tests in libiscsi [1] show that TCM doesn't follow SPC4 
when detects invalid parameters in a XCOPY command or IO errors. The 
replies from TCM contain wrong sense key or ASCQ for incorrect 
request.

The series fixes the following tests from libiscsi:  

We've hit this too. The incorrect sense reporting appears to also affect VMware XCOPY fallback to initiator driven READ/WRITE. I'm pretty sure this is a regression from
d877d7275be34ad70ce92bcbb4bb36cec77ed004, so should probably be marked as such via a Fixes tag.

Cheers, David  

The d877d7275be34ad70ce92bcbb4bb36cec77ed004 was added for v4.10.x kernel and it was necessary
for to avoid LUN removal race conditions. Later you excluded using configfs in the XCOPY workqueue.
It was the 2896c93811e39d63a4d9b63ccf12a8fbc226e5e4.

If we remove the d877d7275be34ad70ce92bcbb4bb36cec77ed004, will it break anything?
We have accumulated many changes between v4.10 and v5.14.

David, maybe can we move the helper 'target_complete_cmd_with_sense' from your path to mainline kernel?
I think it will be useful in the future.

I don't think it makes sense to revert d877d7275be34. I agree that
Mike's target_complete_cmd_with_sense() patch should be helpful for
proper sense propagation here.

Cheers, David