On Thu, 22 Jul 2021 11:03:02 +0000, Sergey Samoylenko wrote: > Hi David, > > > Hi Sergey, > > > > On Thu, 24 Jun 2021 14:19:25 +0300, Sergey Samoylenko wrote: > > > >> 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
