Hi Andy, Xiubo, On Fri, Mar 03, 2017 at 11:00AM, Andy Grover wrote: > On 02/27/2017 09:47 PM, lixiubo@xxxxxxxxxxxxxxxxxxxx wrote: > > From: Xiubo Li <lixiubo@xxxxxxxxxxxxxxxxxxxx> > > > > If there has BIDI data, its first iov[] will overwrite the last > > iov[] for se_cmd->t_data_sg. > > (+CCing orig BIDI and data block code authors) > > Yeah. It looks like because alloc_and_scatter_data_area() (hereafter > "aasda") is called twice in the BIDI case, and both times iov_cnt is 0, the > new_iov() call doesn't increment the iov ptr and the first bidi iov > overwrites the last data iov. Maybe fix this by exiting aasda() with iov > pointing at the next unused iov in the array? Probably also want to zero the > iov. Yes this is definitely a bug, thanks for catching this. This seems to have been introduced around the time new_iov() was introduced, and hence it has been broken since v4.6. On Mon, Mar 06, 2017 at 10:09AM, Andy Grover wrote: > On 03/05/2017 09:48 PM, Xiubo Li wrote: > > For the BIDI data, still hasn't been used by the tcmu-runner. Is any > > other consumer using this? > > Well with kernel APIs you just never know if somebody's using it but just > not saying anything. But given this bug, how could they? I added support for BIDI commands initially, as I needed to have SCSI OSD working over tcmu and the OSD protocol requires BIDI support and I am definitely using it now. Unfortunately, I haven't been able to closely follow the development of target/user lately, so I failed to notice this breakage in time. Sorry about that. -- Ilias
