From: Ming Lei <ming.lei@redhat.com> To: Stephen Rust <srust@blockbridge.com> Cc: Rob Townley <rob.townley@gmail.com>, Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, linux-scsi@vger.kernel.org, martin.petersen@oracle.com, target-devel@vger.kernel.org, Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@ziepe.ca> Subject: Re: Data corruption in kernel 5.1+ with iSER attached ramdisk Date: Wed, 4 Dec 2019 10:39:39 +0800 Message-ID: <20191204023939.GD3910@ming.t460p> (raw) In-Reply-To: <CAAFE1bfB2Km+e=T0ahwq0r9BQrBMnSguQQ+y=yzYi3tursS+TQ@mail.gmail.com> On Tue, Dec 03, 2019 at 02:56:08PM -0500, Stephen Rust wrote: > Hi Ming, > > Thanks very much for the patch. > > > BTW, you may try the attached test patch. If the issue can be fixed by > > this patch, that means it is really caused by un-aligned buffer, and > > the iser driver needs to be fixed. > > I have tried the patch, and re-run the test. Results are mixed. > > To recap, our test writes the last bytes of an iser attached iscsi > device. The target device is a LIO iblock, backed by a brd ramdisk. > The client does a simple `dd`, doing a seek to "size - offset" of the > device, and writing a buffer of "length" which is equivalent to the > offset. > > For example, to test a write at a 512 offset, seek to device "size - > 512", and write a length of data 512 bytes. > > WITHOUT the patch, writing data at the following offsets from the end > of the device failed to write all the correct data (rather, the write > succeeded, but reading the data back it was invalid): > > - failed: 512,1024, 2048, 4096, 8192 > > Anything larger worked fine. > > WITH the patch applied, writing data up to an offset of 4096 all now > worked and verified correctly. However, offsets between 4096 and 8192 > all still failed. I started at 512, and incremented by 512 all the way > up to 16384. The following offsets all failed to verify the write: > > - failed: 4608, 5120, 5632, 6144, 6656, 7168, 7680, 8192 > > Anything larger continues to work fine with the patch. > > As an example, for the failed 8192 case, the `bpftrace lio.bt` trace shows: > > 8192 76 > 4096 0 > 4096 0 > 8192 76 > 4096 0 > 4096 0 The following delta change against last patch should fix the issue with >4096 bvec length: diff --git a/drivers/block/brd.c b/drivers/block/brd.c index 9ea1894c820d..49e37a7dda63 100644 --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -308,7 +308,7 @@ static blk_qc_t brd_make_request(struct request_queue *q, struct bio *bio) if (err) goto io_error; sector += secs; - offset_in_sec = len - (secs << SECTOR_SHIFT); + offset_in_sec += len - (secs << SECTOR_SHIFT); } bio_endio(bio); However, the change on brd is a workaround just for confirming the issue. Thanks, Ming
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CAAFE1bd9wuuobpe4VK7Ty175j7mWT+kRmHCNhVD+6R8MWEAqmw@mail.gmail.com> 2019-11-28 1:57 ` Ming Lei [not found] ` <CA+VdTb_-CGaPjKUQteKVFSGqDz-5o-tuRRkJYqt8B9iOQypiwQ@mail.gmail.com> 2019-11-28 2:58 ` Ming Lei [not found] ` <CAAFE1bfsXsKGyw7SU_z4NanT+wmtuJT=XejBYbHHMCDQwm73sw@mail.gmail.com> 2019-11-28 4:25 ` Stephen Rust 2019-11-28 5:51 ` Rob Townley 2019-11-28 9:12 ` Ming Lei 2019-12-02 18:42 ` Stephen Rust 2019-12-03 0:58 ` Ming Lei 2019-12-03 3:04 ` Stephen Rust 2019-12-03 3:14 ` Ming Lei 2019-12-03 3:26 ` Stephen Rust 2019-12-03 3:50 ` Stephen Rust 2019-12-03 12:45 ` Ming Lei 2019-12-03 19:56 ` Stephen Rust 2019-12-04 1:05 ` Ming Lei 2019-12-04 17:23 ` Stephen Rust 2019-12-04 23:02 ` Ming Lei 2019-12-05 0:16 ` Bart Van Assche 2019-12-05 14:44 ` Stephen Rust 2019-12-05 2:28 ` Stephen Rust 2019-12-05 3:05 ` Ming Lei 2019-12-05 9:17 ` Sagi Grimberg 2019-12-05 14:36 ` Stephen Rust 2019-12-04 2:39 ` Ming Lei [this message] 2019-12-03 4:15 ` Ming Lei
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191204023939.GD3910@ming.t460p \ --to=ming.lei@redhat.com \ --cc=axboe@kernel.dk \ --cc=dledford@redhat.com \ --cc=hch@lst.de \ --cc=jgg@ziepe.ca \ --cc=linux-block@vger.kernel.org \ --cc=linux-rdma@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=rob.townley@gmail.com \ --cc=srust@blockbridge.com \ --cc=target-devel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Block Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-block/0 linux-block/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-block linux-block/ https://lore.kernel.org/linux-block \ linux-block@vger.kernel.org public-inbox-index linux-block Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-block AGPL code for this site: git clone https://public-inbox.org/public-inbox.git