Bart, On 2019/10/31 17:39, Hannes Reinecke wrote: > On 10/30/19 6:01 PM, Bart Van Assche wrote: >> On 10/30/19 9:21 AM, Damien Le Moal wrote: >>> If you feel strongly about it, I have absolutely no problem with >>> dropping the patch. I just would like that it be dropped for the right >>> reasons... >> >> Hi Damien, >> >> What I'm wondering about is how the SCSI core should support residual >> overflow. Should a new member be introduced in struct scsi_request? >> Should resid_len be changed from unsigned int to int or should we >> perhaps follow yet another approach? >> > Please introduce a new member to hold any overflow value. > And document where it is needed. Yes, I also think this is the best approach. The current resid_len member of struct scsi_request can be kept as is, encoding actual underflow of a command (less bytes transferred than asked for). The new field would only be used in the case of "overflow", which are not actual buffer overflows as Hannes pointed out (otherwise, we would get memory corruptions, iommu screaming etc). The SG driver can make use of this field to keep the io header resid as an int, with negative values indicating overflows and positive values underflows. Best regards. -- Damien Le Moal Western Digital Research
