2017-07-28 13:13:30

by Javier González

[permalink] [raw]
Subject: [PATCH V2] lightnvm: pblk fix for 4.13

Hi Jens,

Can you pick up this fix for 4.13? It is a fix to a read corruption in
pblk that has been there form the beginning. It is due to a bad bio
manipulation in the case that an I/O containing lbas that are invalid,
point to data in the host cache and point to data on the device, all
three in a single bio.

The patch applies on top of you for-4.13/block and is available too at:
- https://github.com/OpenChannelSSD/linux/tree/pblk.for-4.13

I marked the patch to fix the original pblk commit, but it does not
apply anymore on the original 4.12 code. How do we handle these
situations? We make a backport when Greg makes 4.12 stable?

Changes since V1:
- Make advanced_bio a bool to improve readability, as suggested by Jens

Thanks,
Javier


Javier González (1):
lightnvm: pblk: advance bio according to lba index

drivers/lightnvm/pblk-rb.c | 4 ++--
rivers/lightnvm/pblk-read.c | 23 ++++++++++++++++-------
drivers/lightnvm/pblk.h | 2 +-
3 files changed, 19 insertions(+), 10 deletions(-)

--
2.7.4


2017-07-28 13:13:31

by Javier González

[permalink] [raw]
Subject: [PATCH] lightnvm: pblk: advance bio according to lba index

When a lba either hits the cache or corresponds to an empty entry in the
L2P table, we need to advance the bio according to the position in which
the lba is located. Otherwise, we will copy data in the wrong page, thus
causing data corruption for the application.

In case of a cache hit, we assumed that bio->bi_iter.bi_idx would
contain the correct index, but this is no necessarily true. Instead, use
the local bio advance counter and iterator. This guarantees that lbas
hitting the cache are copied into the right bv_page.

In case of an empty L2P entry, we omitted to advance the bio. In the
cases when the same I/O also contains a cache hit, data corresponding
to this lba will be copied to the wrong bv_page. Fix this by advancing
the bio as we do in the case of a cache hit.

Fixes: a4bd217b4326 lightnvm: physical block device (pblk) target

Signed-off-by: Javier González <[email protected]>
---
drivers/lightnvm/pblk-rb.c | 4 ++--
drivers/lightnvm/pblk-read.c | 23 ++++++++++++++++-------
drivers/lightnvm/pblk.h | 2 +-
3 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/lightnvm/pblk-rb.c b/drivers/lightnvm/pblk-rb.c
index 5ecc154f6831..9bc32578a766 100644
--- a/drivers/lightnvm/pblk-rb.c
+++ b/drivers/lightnvm/pblk-rb.c
@@ -657,7 +657,7 @@ unsigned int pblk_rb_read_to_bio(struct pblk_rb *rb, struct nvm_rq *rqd,
* be directed to disk.
*/
int pblk_rb_copy_to_bio(struct pblk_rb *rb, struct bio *bio, sector_t lba,
- struct ppa_addr ppa, int bio_iter)
+ struct ppa_addr ppa, int bio_iter, bool advanced_bio)
{
struct pblk *pblk = container_of(rb, struct pblk, rwb);
struct pblk_rb_entry *entry;
@@ -694,7 +694,7 @@ int pblk_rb_copy_to_bio(struct pblk_rb *rb, struct bio *bio, sector_t lba,
* filled with data from the cache). If part of the data resides on the
* media, we will read later on
*/
- if (unlikely(!bio->bi_iter.bi_idx))
+ if (unlikely(!advanced_bio))
bio_advance(bio, bio_iter * PBLK_EXPOSED_PAGE_SIZE);

data = bio_data(bio);
diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
index 4e5c48f3de62..d682e89e6493 100644
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -26,7 +26,7 @@
*/
static int pblk_read_from_cache(struct pblk *pblk, struct bio *bio,
sector_t lba, struct ppa_addr ppa,
- int bio_iter)
+ int bio_iter, bool advanced_bio)
{
#ifdef CONFIG_NVM_DEBUG
/* Callers must ensure that the ppa points to a cache address */
@@ -34,7 +34,8 @@ static int pblk_read_from_cache(struct pblk *pblk, struct bio *bio,
BUG_ON(!pblk_addr_in_cache(ppa));
#endif

- return pblk_rb_copy_to_bio(&pblk->rwb, bio, lba, ppa, bio_iter);
+ return pblk_rb_copy_to_bio(&pblk->rwb, bio, lba, ppa,
+ bio_iter, advanced_bio);
}

static void pblk_read_ppalist_rq(struct pblk *pblk, struct nvm_rq *rqd,
@@ -44,7 +45,7 @@ static void pblk_read_ppalist_rq(struct pblk *pblk, struct nvm_rq *rqd,
struct ppa_addr ppas[PBLK_MAX_REQ_ADDRS];
sector_t blba = pblk_get_lba(bio);
int nr_secs = rqd->nr_ppas;
- int advanced_bio = 0;
+ bool advanced_bio = false;
int i, j = 0;

/* logic error: lba out-of-bounds. Ignore read request */
@@ -62,19 +63,26 @@ static void pblk_read_ppalist_rq(struct pblk *pblk, struct nvm_rq *rqd,
retry:
if (pblk_ppa_empty(p)) {
WARN_ON(test_and_set_bit(i, read_bitmap));
- continue;
+
+ if (unlikely(!advanced_bio)) {
+ bio_advance(bio, (i) * PBLK_EXPOSED_PAGE_SIZE);
+ advanced_bio = true;
+ }
+
+ goto next;
}

/* Try to read from write buffer. The address is later checked
* on the write buffer to prevent retrieving overwritten data.
*/
if (pblk_addr_in_cache(p)) {
- if (!pblk_read_from_cache(pblk, bio, lba, p, i)) {
+ if (!pblk_read_from_cache(pblk, bio, lba, p, i,
+ advanced_bio)) {
pblk_lookup_l2p_seq(pblk, &p, lba, 1);
goto retry;
}
WARN_ON(test_and_set_bit(i, read_bitmap));
- advanced_bio = 1;
+ advanced_bio = true;
#ifdef CONFIG_NVM_DEBUG
atomic_long_inc(&pblk->cache_reads);
#endif
@@ -83,6 +91,7 @@ static void pblk_read_ppalist_rq(struct pblk *pblk, struct nvm_rq *rqd,
rqd->ppa_list[j++] = p;
}

+next:
if (advanced_bio)
bio_advance(bio, PBLK_EXPOSED_PAGE_SIZE);
}
@@ -282,7 +291,7 @@ static void pblk_read_rq(struct pblk *pblk, struct nvm_rq *rqd,
* write buffer to prevent retrieving overwritten data.
*/
if (pblk_addr_in_cache(ppa)) {
- if (!pblk_read_from_cache(pblk, bio, lba, ppa, 0)) {
+ if (!pblk_read_from_cache(pblk, bio, lba, ppa, 0, 1)) {
pblk_lookup_l2p_seq(pblk, &ppa, lba, 1);
goto retry;
}
diff --git a/drivers/lightnvm/pblk.h b/drivers/lightnvm/pblk.h
index 0c5692cc2f60..67e623bd5c2d 100644
--- a/drivers/lightnvm/pblk.h
+++ b/drivers/lightnvm/pblk.h
@@ -670,7 +670,7 @@ unsigned int pblk_rb_read_to_bio_list(struct pblk_rb *rb, struct bio *bio,
struct list_head *list,
unsigned int max);
int pblk_rb_copy_to_bio(struct pblk_rb *rb, struct bio *bio, sector_t lba,
- struct ppa_addr ppa, int bio_iter);
+ struct ppa_addr ppa, int bio_iter, bool advanced_bio);
unsigned int pblk_rb_read_commit(struct pblk_rb *rb, unsigned int entries);

unsigned int pblk_rb_sync_init(struct pblk_rb *rb, unsigned long *flags);
--
2.7.4

2017-07-28 14:06:57

by Jens Axboe

[permalink] [raw]
Subject: Re: [PATCH V2] lightnvm: pblk fix for 4.13

On 07/28/2017 07:13 AM, Javier González wrote:
> Hi Jens,
>
> Can you pick up this fix for 4.13? It is a fix to a read corruption in
> pblk that has been there form the beginning. It is due to a bad bio
> manipulation in the case that an I/O containing lbas that are invalid,
> point to data in the host cache and point to data on the device, all
> three in a single bio.
>
> The patch applies on top of you for-4.13/block and is available too at:
> - https://github.com/OpenChannelSSD/linux/tree/pblk.for-4.13
>
> I marked the patch to fix the original pblk commit, but it does not
> apply anymore on the original 4.12 code. How do we handle these
> situations? We make a backport when Greg makes 4.12 stable?

Greg will email you if it doesn't apply, then you can reply back
with a version that does apply against 4.12.

Applied for 4.13.

--
Jens Axboe

2017-07-28 14:09:42

by Javier González

[permalink] [raw]
Subject: Re: [PATCH V2] lightnvm: pblk fix for 4.13

> On 28 Jul 2017, at 16.06, Jens Axboe <[email protected]> wrote:
>
> On 07/28/2017 07:13 AM, Javier González wrote:
>> Hi Jens,
>>
>> Can you pick up this fix for 4.13? It is a fix to a read corruption in
>> pblk that has been there form the beginning. It is due to a bad bio
>> manipulation in the case that an I/O containing lbas that are invalid,
>> point to data in the host cache and point to data on the device, all
>> three in a single bio.
>>
>> The patch applies on top of you for-4.13/block and is available too at:
>> - https://github.com/OpenChannelSSD/linux/tree/pblk.for-4.13
>>
>> I marked the patch to fix the original pblk commit, but it does not
>> apply anymore on the original 4.12 code. How do we handle these
>> situations? We make a backport when Greg makes 4.12 stable?
>
> Greg will email you if it doesn't apply, then you can reply back
> with a version that does apply against 4.12.

Makes sense. Thanks for explaining :)

Javier


Attachments:
signature.asc (801.00 B)
Message signed with OpenPGP