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 [thread overview]
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
WARNING: multiple messages have this Message-ID (diff)
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, 04 Dec 2019 02:39:39 +0000 [thread overview]
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 other threads:[~2019-12-04 2:40 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAAFE1bd9wuuobpe4VK7Ty175j7mWT+kRmHCNhVD+6R8MWEAqmw@mail.gmail.com>
2019-11-28 1:57 ` Data corruption in kernel 5.1+ with iSER attached ramdisk Ming Lei
2019-11-28 1:57 ` Ming Lei
[not found] ` <CA+VdTb_-CGaPjKUQteKVFSGqDz-5o-tuRRkJYqt8B9iOQypiwQ@mail.gmail.com>
2019-11-28 2:58 ` Ming Lei
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 4:25 ` Stephen Rust
2019-11-28 5:51 ` Rob Townley
2019-11-28 5:51 ` Rob Townley
2019-11-28 9:12 ` Ming Lei
2019-11-28 9:12 ` Ming Lei
2019-12-02 18:42 ` Stephen Rust
2019-12-02 18:42 ` Stephen Rust
2019-12-03 0:58 ` Ming Lei
2019-12-03 0:58 ` Ming Lei
2019-12-03 3:04 ` Stephen Rust
2019-12-03 3:04 ` Stephen Rust
2019-12-03 3:14 ` Ming Lei
2019-12-03 3:14 ` Ming Lei
2019-12-03 3:26 ` Stephen Rust
2019-12-03 3:26 ` Stephen Rust
2019-12-03 3:50 ` Stephen Rust
2019-12-03 3:50 ` Stephen Rust
2019-12-03 12:45 ` Ming Lei
2019-12-03 12:45 ` Ming Lei
2019-12-03 19:56 ` Stephen Rust
2019-12-03 19:56 ` Stephen Rust
2019-12-04 1:05 ` Ming Lei
2019-12-04 1:05 ` Ming Lei
2019-12-04 17:23 ` Stephen Rust
2019-12-04 17:23 ` Stephen Rust
2019-12-04 23:02 ` Ming Lei
2019-12-04 23:02 ` Ming Lei
2019-12-05 0:16 ` Bart Van Assche
2019-12-05 0:16 ` Bart Van Assche
2019-12-05 14:44 ` Stephen Rust
2019-12-05 14:44 ` Stephen Rust
2019-12-05 2:28 ` Stephen Rust
2019-12-05 2:28 ` Stephen Rust
2019-12-05 3:05 ` Ming Lei
2019-12-05 3:05 ` Ming Lei
2019-12-05 9:17 ` Sagi Grimberg
2019-12-05 9:17 ` Sagi Grimberg
2019-12-05 14:36 ` Stephen Rust
2019-12-05 14:36 ` Stephen Rust
[not found] ` <CAAFE1beqFBQS_zVYEXFTD2qu8PAF9hBSW4j1k9ZD6MhU_gWg5Q@mail.gmail.com>
2020-03-25 0:15 ` Sagi Grimberg
2020-03-25 0:15 ` Sagi Grimberg
2020-03-30 17:08 ` Stephen Rust
2020-03-30 17:08 ` Stephen Rust
2020-03-31 1:07 ` Sagi Grimberg
2020-03-31 1:07 ` Sagi Grimberg
2020-04-01 0:38 ` Sagi Grimberg
2020-04-01 0:38 ` Sagi Grimberg
2020-04-02 20:03 ` Stephen Rust
2020-04-02 20:03 ` Stephen Rust
2020-04-02 22:16 ` Sagi Grimberg
2020-04-02 22:16 ` Sagi Grimberg
2019-12-04 2:39 ` Ming Lei [this message]
2019-12-04 2:39 ` Ming Lei
2019-12-03 4:15 ` Ming Lei
2019-12-03 4:15 ` Ming Lei
Reply instructions:
You may reply publicly 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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.