* [PATCH v1 14/14] md: raid10: avoid direct access to bvec table in handle_reshape_read_error
From: Ming Lei @ 2017-02-24 15:42 UTC (permalink / raw)
To: Shaohua Li, Jens Axboe, linux-kernel, linux-raid, linux-block,
Christoph Hellwig
Cc: Ming Lei
In-Reply-To: <1487950971-1131-1-git-send-email-tom.leiming@gmail.com>
The cost is 128bytes(8*16) stack space in kernel thread context, and
just use the bio helper to retrieve pages from bio.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
drivers/md/raid10.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index ae162d542bf4..705cb9af03ef 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -4689,7 +4689,15 @@ static int handle_reshape_read_error(struct mddev *mddev,
struct r10bio *r10b = &on_stack.r10_bio;
int slot = 0;
int idx = 0;
- struct bio_vec *bvec = r10_bio->master_bio->bi_io_vec;
+ struct bio_vec *bvl;
+ struct page *pages[RESYNC_PAGES];
+
+ /*
+ * This bio is allocated in reshape_request(), and size
+ * is still RESYNC_PAGES
+ */
+ bio_for_each_segment_all(bvl, r10_bio->master_bio, idx)
+ pages[idx] = bvl->bv_page;
r10b->sector = r10_bio->sector;
__raid10_find_phys(&conf->prev, r10b);
@@ -4718,7 +4726,7 @@ static int handle_reshape_read_error(struct mddev *mddev,
success = sync_page_io(rdev,
addr,
s << 9,
- bvec[idx].bv_page,
+ pages[idx],
REQ_OP_READ, 0, false);
rdev_dec_pending(rdev, mddev);
rcu_read_lock();
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] lightnvm: rename scrambler controller hint
From: Javier González @ 2017-02-24 16:14 UTC (permalink / raw)
To: mb; +Cc: linux-block, linux-kernel, Javier González,
Matias Bjørling
In-Reply-To: <1487952846-29476-1-git-send-email-javier@cnexlabs.com>
According to the OCSSD 1.2 specification, the 0x200 hint enables the
media scrambler for the read/write opcode, providing that the controller
has been correctly configured by the firmware. Rename the macro to
represent this meaning.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
---
include/linux/lightnvm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
index 6a3534b..bebea80 100644
--- a/include/linux/lightnvm.h
+++ b/include/linux/lightnvm.h
@@ -123,7 +123,7 @@ enum {
/* NAND Access Modes */
NVM_IO_SUSPEND = 0x80,
NVM_IO_SLC_MODE = 0x100,
- NVM_IO_SCRAMBLE_DISABLE = 0x200,
+ NVM_IO_SCRAMBLE_ENABLE = 0x200,
/* Block Types */
NVM_BLK_T_FREE = 0x0,
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] lightnvm: submit erases using the I/O path
From: Javier González @ 2017-02-24 16:14 UTC (permalink / raw)
To: mb; +Cc: linux-block, linux-kernel, Javier González,
Matias Bjørling
Until now erases have been submitted as synchronous commands through a
dedicated erase function. In order to enable targets implementing
asynchronous erases, refactor the erase path so that it uses the normal
async I/O submission functions. If a target requires sync I/O, it can
implement it internally. Also, adapt rrpc to use the new erase path.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
---
drivers/lightnvm/core.c | 54 +++++++++++++++++++++++++++-----------------
drivers/lightnvm/rrpc.c | 3 +--
drivers/nvme/host/lightnvm.c | 32 ++++++++------------------
include/linux/lightnvm.h | 8 +++----
4 files changed, 47 insertions(+), 50 deletions(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index fcbd82f..ca48792 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -592,11 +592,11 @@ int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
memset(&rqd, 0, sizeof(struct nvm_rq));
- nvm_set_rqd_ppalist(dev, &rqd, ppas, nr_ppas, 1);
+ nvm_set_rqd_ppalist(tgt_dev, &rqd, ppas, nr_ppas, 1);
nvm_rq_tgt_to_dev(tgt_dev, &rqd);
ret = dev->ops->set_bb_tbl(dev, &rqd.ppa_addr, rqd.nr_ppas, type);
- nvm_free_rqd_ppalist(dev, &rqd);
+ nvm_free_rqd_ppalist(tgt_dev, &rqd);
if (ret) {
pr_err("nvm: failed bb mark\n");
return -EINVAL;
@@ -628,34 +628,45 @@ int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
}
EXPORT_SYMBOL(nvm_submit_io);
-int nvm_erase_blk(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas, int flags)
+static void nvm_end_io_sync(struct nvm_rq *rqd)
{
- struct nvm_dev *dev = tgt_dev->parent;
+ struct completion *waiting = rqd->private;
+
+ complete(waiting);
+}
+
+int nvm_erase_sync(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
+ int nr_ppas)
+{
+ struct nvm_geo *geo = &tgt_dev->geo;
struct nvm_rq rqd;
int ret;
-
- if (!dev->ops->erase_block)
- return 0;
-
- nvm_map_to_dev(tgt_dev, ppas);
+ DECLARE_COMPLETION_ONSTACK(wait);
memset(&rqd, 0, sizeof(struct nvm_rq));
- ret = nvm_set_rqd_ppalist(dev, &rqd, ppas, 1, 1);
+ rqd.opcode = NVM_OP_ERASE;
+ rqd.end_io = nvm_end_io_sync;
+ rqd.private = &wait;
+ rqd.flags = geo->plane_mode >> 1;
+
+ ret = nvm_set_rqd_ppalist(tgt_dev, &rqd, ppas, nr_ppas, 1);
if (ret)
return ret;
- nvm_rq_tgt_to_dev(tgt_dev, &rqd);
+ ret = nvm_submit_io(tgt_dev, &rqd);
+ if (ret) {
+ pr_err("rrpr: erase I/O submission falied: %d\n", ret);
+ goto free_ppa_list;
+ }
+ wait_for_completion_io(&wait);
- rqd.flags = flags;
-
- ret = dev->ops->erase_block(dev, &rqd);
-
- nvm_free_rqd_ppalist(dev, &rqd);
+free_ppa_list:
+ nvm_free_rqd_ppalist(tgt_dev, &rqd);
return ret;
}
-EXPORT_SYMBOL(nvm_erase_blk);
+EXPORT_SYMBOL(nvm_erase_sync);
int nvm_get_l2p_tbl(struct nvm_tgt_dev *tgt_dev, u64 slba, u32 nlb,
nvm_l2p_update_fn *update_l2p, void *priv)
@@ -734,10 +745,11 @@ void nvm_put_area(struct nvm_tgt_dev *tgt_dev, sector_t begin)
}
EXPORT_SYMBOL(nvm_put_area);
-int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
+int nvm_set_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd,
const struct ppa_addr *ppas, int nr_ppas, int vblk)
{
- struct nvm_geo *geo = &dev->geo;
+ struct nvm_dev *dev = tgt_dev->parent;
+ struct nvm_geo *geo = &tgt_dev->geo;
int i, plane_cnt, pl_idx;
struct ppa_addr ppa;
@@ -775,12 +787,12 @@ int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
}
EXPORT_SYMBOL(nvm_set_rqd_ppalist);
-void nvm_free_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd)
+void nvm_free_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
{
if (!rqd->ppa_list)
return;
- nvm_dev_dma_free(dev, rqd->ppa_list, rqd->dma_ppa_list);
+ nvm_dev_dma_free(tgt_dev->parent, rqd->ppa_list, rqd->dma_ppa_list);
}
EXPORT_SYMBOL(nvm_free_rqd_ppalist);
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index e68efbc..4e4c299 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -414,7 +414,6 @@ static void rrpc_block_gc(struct work_struct *work)
struct rrpc *rrpc = gcb->rrpc;
struct rrpc_block *rblk = gcb->rblk;
struct rrpc_lun *rlun = rblk->rlun;
- struct nvm_tgt_dev *dev = rrpc->dev;
struct ppa_addr ppa;
mempool_free(gcb, rrpc->gcb_pool);
@@ -430,7 +429,7 @@ static void rrpc_block_gc(struct work_struct *work)
ppa.g.lun = rlun->bppa.g.lun;
ppa.g.blk = rblk->id;
- if (nvm_erase_blk(dev, &ppa, 0))
+ if (nvm_erase_sync(rrpc->dev, &ppa, 1))
goto put_back;
rrpc_put_blk(rrpc, rblk);
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index a057a36..faf8419 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -606,12 +606,16 @@ static int nvme_nvm_submit_io(struct nvm_dev *dev, struct nvm_rq *rqd)
}
rq->cmd_flags &= ~REQ_FAILFAST_DRIVER;
- rq->ioprio = bio_prio(bio);
- if (bio_has_data(bio))
- rq->nr_phys_segments = bio_phys_segments(q, bio);
-
- rq->__data_len = bio->bi_iter.bi_size;
- rq->bio = rq->biotail = bio;
+ if (bio) {
+ rq->ioprio = bio_prio(bio);
+ rq->__data_len = bio->bi_iter.bi_size;
+ rq->bio = rq->biotail = bio;
+ if (bio_has_data(bio))
+ rq->nr_phys_segments = bio_phys_segments(q, bio);
+ } else {
+ rq->ioprio = IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_NORM);
+ rq->__data_len = 0;
+ }
nvme_nvm_rqtocmd(rq, rqd, ns, cmd);
@@ -622,21 +626,6 @@ static int nvme_nvm_submit_io(struct nvm_dev *dev, struct nvm_rq *rqd)
return 0;
}
-static int nvme_nvm_erase_block(struct nvm_dev *dev, struct nvm_rq *rqd)
-{
- struct request_queue *q = dev->q;
- struct nvme_ns *ns = q->queuedata;
- struct nvme_nvm_command c = {};
-
- c.erase.opcode = NVM_OP_ERASE;
- c.erase.nsid = cpu_to_le32(ns->ns_id);
- c.erase.spba = cpu_to_le64(rqd->ppa_addr.ppa);
- c.erase.length = cpu_to_le16(rqd->nr_ppas - 1);
- c.erase.control = cpu_to_le16(rqd->flags);
-
- return nvme_submit_sync_cmd(q, (struct nvme_command *)&c, NULL, 0);
-}
-
static void *nvme_nvm_create_dma_pool(struct nvm_dev *nvmdev, char *name)
{
struct nvme_ns *ns = nvmdev->q->queuedata;
@@ -672,7 +661,6 @@ static struct nvm_dev_ops nvme_nvm_dev_ops = {
.set_bb_tbl = nvme_nvm_set_bb_tbl,
.submit_io = nvme_nvm_submit_io,
- .erase_block = nvme_nvm_erase_block,
.create_dma_pool = nvme_nvm_create_dma_pool,
.destroy_dma_pool = nvme_nvm_destroy_dma_pool,
diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
index 33c29cc..6a3534b 100644
--- a/include/linux/lightnvm.h
+++ b/include/linux/lightnvm.h
@@ -56,7 +56,6 @@ typedef int (nvm_get_l2p_tbl_fn)(struct nvm_dev *, u64, u32,
typedef int (nvm_op_bb_tbl_fn)(struct nvm_dev *, struct ppa_addr, u8 *);
typedef int (nvm_op_set_bb_fn)(struct nvm_dev *, struct ppa_addr *, int, int);
typedef int (nvm_submit_io_fn)(struct nvm_dev *, struct nvm_rq *);
-typedef int (nvm_erase_blk_fn)(struct nvm_dev *, struct nvm_rq *);
typedef void *(nvm_create_dma_pool_fn)(struct nvm_dev *, char *);
typedef void (nvm_destroy_dma_pool_fn)(void *);
typedef void *(nvm_dev_dma_alloc_fn)(struct nvm_dev *, void *, gfp_t,
@@ -70,7 +69,6 @@ struct nvm_dev_ops {
nvm_op_set_bb_fn *set_bb_tbl;
nvm_submit_io_fn *submit_io;
- nvm_erase_blk_fn *erase_block;
nvm_create_dma_pool_fn *create_dma_pool;
nvm_destroy_dma_pool_fn *destroy_dma_pool;
@@ -479,10 +477,10 @@ extern int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *, struct ppa_addr *,
int, int);
extern int nvm_max_phys_sects(struct nvm_tgt_dev *);
extern int nvm_submit_io(struct nvm_tgt_dev *, struct nvm_rq *);
-extern int nvm_set_rqd_ppalist(struct nvm_dev *, struct nvm_rq *,
+extern int nvm_erase_sync(struct nvm_tgt_dev *, struct ppa_addr *, int);
+extern int nvm_set_rqd_ppalist(struct nvm_tgt_dev *, struct nvm_rq *,
const struct ppa_addr *, int, int);
-extern void nvm_free_rqd_ppalist(struct nvm_dev *, struct nvm_rq *);
-extern int nvm_erase_blk(struct nvm_tgt_dev *, struct ppa_addr *, int);
+extern void nvm_free_rqd_ppalist(struct nvm_tgt_dev *, struct nvm_rq *);
extern int nvm_get_l2p_tbl(struct nvm_tgt_dev *, u64, u32, nvm_l2p_update_fn *,
void *);
extern int nvm_get_area(struct nvm_tgt_dev *, sector_t *, sector_t);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] lightnvm: free reverse device map
From: Javier González @ 2017-02-24 16:14 UTC (permalink / raw)
To: mb; +Cc: linux-block, linux-kernel, Javier González
In-Reply-To: <1487952846-29476-1-git-send-email-javier@cnexlabs.com>
Free the reverse mapping table correctly on target tear down
Signed-off-by: Javier González <javier@cnexlabs.com>
---
drivers/lightnvm/core.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index ca48792..f1cb485 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -413,6 +413,18 @@ static int nvm_register_map(struct nvm_dev *dev)
return -ENOMEM;
}
+static void nvm_unregister_map(struct nvm_dev *dev)
+{
+ struct nvm_dev_map *rmap = dev->rmap;
+ int i;
+
+ for (i = 0; i < dev->geo.nr_chnls; i++)
+ kfree(rmap->chnls[i].lun_offs);
+
+ kfree(rmap->chnls);
+ kfree(rmap);
+}
+
static void nvm_map_to_dev(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *p)
{
struct nvm_dev_map *dev_map = tgt_dev->map;
@@ -994,7 +1006,7 @@ void nvm_free(struct nvm_dev *dev)
if (dev->dma_pool)
dev->ops->destroy_dma_pool(dev->dma_pool);
- kfree(dev->rmap);
+ nvm_unregister_map(dev);
kfree(dev->lptbl);
kfree(dev->lun_map);
kfree(dev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3] lightnvm: rename scrambler controller hint
From: Matias Bjørling @ 2017-02-24 17:08 UTC (permalink / raw)
To: Javier González
Cc: linux-block, linux-kernel, Javier González,
Matias Bjørling
In-Reply-To: <1487952846-29476-2-git-send-email-javier@cnexlabs.com>
On 02/24/2017 05:14 PM, Javier González wrote:
> According to the OCSSD 1.2 specification, the 0x200 hint enables the
> media scrambler for the read/write opcode, providing that the controller
> has been correctly configured by the firmware. Rename the macro to
> represent this meaning.
>
> Signed-off-by: Javier González <javier@cnexlabs.com>
> Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
> ---
> include/linux/lightnvm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
> index 6a3534b..bebea80 100644
> --- a/include/linux/lightnvm.h
> +++ b/include/linux/lightnvm.h
> @@ -123,7 +123,7 @@ enum {
> /* NAND Access Modes */
> NVM_IO_SUSPEND = 0x80,
> NVM_IO_SLC_MODE = 0x100,
> - NVM_IO_SCRAMBLE_DISABLE = 0x200,
> + NVM_IO_SCRAMBLE_ENABLE = 0x200,
>
> /* Block Types */
> NVM_BLK_T_FREE = 0x0,
>
Thanks, applied for 4.12.
^ permalink raw reply
* Re: [PATCH 1/3] lightnvm: submit erases using the I/O path
From: Matias Bjørling @ 2017-02-24 17:08 UTC (permalink / raw)
To: Javier González
Cc: linux-block, linux-kernel, Javier González,
Matias Bjørling
In-Reply-To: <1487952846-29476-1-git-send-email-javier@cnexlabs.com>
On 02/24/2017 05:14 PM, Javier González wrote:
> Until now erases have been submitted as synchronous commands through a
> dedicated erase function. In order to enable targets implementing
> asynchronous erases, refactor the erase path so that it uses the normal
> async I/O submission functions. If a target requires sync I/O, it can
> implement it internally. Also, adapt rrpc to use the new erase path.
>
> Signed-off-by: Javier González <javier@cnexlabs.com>
> Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
> ---
> drivers/lightnvm/core.c | 54 +++++++++++++++++++++++++++-----------------
> drivers/lightnvm/rrpc.c | 3 +--
> drivers/nvme/host/lightnvm.c | 32 ++++++++------------------
> include/linux/lightnvm.h | 8 +++----
> 4 files changed, 47 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
> index fcbd82f..ca48792 100644
> --- a/drivers/lightnvm/core.c
> +++ b/drivers/lightnvm/core.c
> @@ -592,11 +592,11 @@ int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
>
> memset(&rqd, 0, sizeof(struct nvm_rq));
>
> - nvm_set_rqd_ppalist(dev, &rqd, ppas, nr_ppas, 1);
> + nvm_set_rqd_ppalist(tgt_dev, &rqd, ppas, nr_ppas, 1);
> nvm_rq_tgt_to_dev(tgt_dev, &rqd);
>
> ret = dev->ops->set_bb_tbl(dev, &rqd.ppa_addr, rqd.nr_ppas, type);
> - nvm_free_rqd_ppalist(dev, &rqd);
> + nvm_free_rqd_ppalist(tgt_dev, &rqd);
> if (ret) {
> pr_err("nvm: failed bb mark\n");
> return -EINVAL;
> @@ -628,34 +628,45 @@ int nvm_submit_io(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
> }
> EXPORT_SYMBOL(nvm_submit_io);
>
> -int nvm_erase_blk(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas, int flags)
> +static void nvm_end_io_sync(struct nvm_rq *rqd)
> {
> - struct nvm_dev *dev = tgt_dev->parent;
> + struct completion *waiting = rqd->private;
> +
> + complete(waiting);
> +}
> +
> +int nvm_erase_sync(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *ppas,
> + int nr_ppas)
> +{
> + struct nvm_geo *geo = &tgt_dev->geo;
> struct nvm_rq rqd;
> int ret;
> -
> - if (!dev->ops->erase_block)
> - return 0;
> -
> - nvm_map_to_dev(tgt_dev, ppas);
> + DECLARE_COMPLETION_ONSTACK(wait);
>
> memset(&rqd, 0, sizeof(struct nvm_rq));
>
> - ret = nvm_set_rqd_ppalist(dev, &rqd, ppas, 1, 1);
> + rqd.opcode = NVM_OP_ERASE;
> + rqd.end_io = nvm_end_io_sync;
> + rqd.private = &wait;
> + rqd.flags = geo->plane_mode >> 1;
> +
> + ret = nvm_set_rqd_ppalist(tgt_dev, &rqd, ppas, nr_ppas, 1);
> if (ret)
> return ret;
>
> - nvm_rq_tgt_to_dev(tgt_dev, &rqd);
> + ret = nvm_submit_io(tgt_dev, &rqd);
> + if (ret) {
> + pr_err("rrpr: erase I/O submission falied: %d\n", ret);
> + goto free_ppa_list;
> + }
> + wait_for_completion_io(&wait);
>
> - rqd.flags = flags;
> -
> - ret = dev->ops->erase_block(dev, &rqd);
> -
> - nvm_free_rqd_ppalist(dev, &rqd);
> +free_ppa_list:
> + nvm_free_rqd_ppalist(tgt_dev, &rqd);
>
> return ret;
> }
> -EXPORT_SYMBOL(nvm_erase_blk);
> +EXPORT_SYMBOL(nvm_erase_sync);
>
> int nvm_get_l2p_tbl(struct nvm_tgt_dev *tgt_dev, u64 slba, u32 nlb,
> nvm_l2p_update_fn *update_l2p, void *priv)
> @@ -734,10 +745,11 @@ void nvm_put_area(struct nvm_tgt_dev *tgt_dev, sector_t begin)
> }
> EXPORT_SYMBOL(nvm_put_area);
>
> -int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
> +int nvm_set_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd,
> const struct ppa_addr *ppas, int nr_ppas, int vblk)
> {
> - struct nvm_geo *geo = &dev->geo;
> + struct nvm_dev *dev = tgt_dev->parent;
> + struct nvm_geo *geo = &tgt_dev->geo;
> int i, plane_cnt, pl_idx;
> struct ppa_addr ppa;
>
> @@ -775,12 +787,12 @@ int nvm_set_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd,
> }
> EXPORT_SYMBOL(nvm_set_rqd_ppalist);
>
> -void nvm_free_rqd_ppalist(struct nvm_dev *dev, struct nvm_rq *rqd)
> +void nvm_free_rqd_ppalist(struct nvm_tgt_dev *tgt_dev, struct nvm_rq *rqd)
> {
> if (!rqd->ppa_list)
> return;
>
> - nvm_dev_dma_free(dev, rqd->ppa_list, rqd->dma_ppa_list);
> + nvm_dev_dma_free(tgt_dev->parent, rqd->ppa_list, rqd->dma_ppa_list);
> }
> EXPORT_SYMBOL(nvm_free_rqd_ppalist);
>
> diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
> index e68efbc..4e4c299 100644
> --- a/drivers/lightnvm/rrpc.c
> +++ b/drivers/lightnvm/rrpc.c
> @@ -414,7 +414,6 @@ static void rrpc_block_gc(struct work_struct *work)
> struct rrpc *rrpc = gcb->rrpc;
> struct rrpc_block *rblk = gcb->rblk;
> struct rrpc_lun *rlun = rblk->rlun;
> - struct nvm_tgt_dev *dev = rrpc->dev;
> struct ppa_addr ppa;
>
> mempool_free(gcb, rrpc->gcb_pool);
> @@ -430,7 +429,7 @@ static void rrpc_block_gc(struct work_struct *work)
> ppa.g.lun = rlun->bppa.g.lun;
> ppa.g.blk = rblk->id;
>
> - if (nvm_erase_blk(dev, &ppa, 0))
> + if (nvm_erase_sync(rrpc->dev, &ppa, 1))
> goto put_back;
>
> rrpc_put_blk(rrpc, rblk);
> diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
> index a057a36..faf8419 100644
> --- a/drivers/nvme/host/lightnvm.c
> +++ b/drivers/nvme/host/lightnvm.c
> @@ -606,12 +606,16 @@ static int nvme_nvm_submit_io(struct nvm_dev *dev, struct nvm_rq *rqd)
> }
> rq->cmd_flags &= ~REQ_FAILFAST_DRIVER;
>
> - rq->ioprio = bio_prio(bio);
> - if (bio_has_data(bio))
> - rq->nr_phys_segments = bio_phys_segments(q, bio);
> -
> - rq->__data_len = bio->bi_iter.bi_size;
> - rq->bio = rq->biotail = bio;
> + if (bio) {
> + rq->ioprio = bio_prio(bio);
> + rq->__data_len = bio->bi_iter.bi_size;
> + rq->bio = rq->biotail = bio;
> + if (bio_has_data(bio))
> + rq->nr_phys_segments = bio_phys_segments(q, bio);
> + } else {
> + rq->ioprio = IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, IOPRIO_NORM);
> + rq->__data_len = 0;
> + }
>
> nvme_nvm_rqtocmd(rq, rqd, ns, cmd);
>
> @@ -622,21 +626,6 @@ static int nvme_nvm_submit_io(struct nvm_dev *dev, struct nvm_rq *rqd)
> return 0;
> }
>
> -static int nvme_nvm_erase_block(struct nvm_dev *dev, struct nvm_rq *rqd)
> -{
> - struct request_queue *q = dev->q;
> - struct nvme_ns *ns = q->queuedata;
> - struct nvme_nvm_command c = {};
> -
> - c.erase.opcode = NVM_OP_ERASE;
> - c.erase.nsid = cpu_to_le32(ns->ns_id);
> - c.erase.spba = cpu_to_le64(rqd->ppa_addr.ppa);
> - c.erase.length = cpu_to_le16(rqd->nr_ppas - 1);
> - c.erase.control = cpu_to_le16(rqd->flags);
> -
> - return nvme_submit_sync_cmd(q, (struct nvme_command *)&c, NULL, 0);
> -}
> -
> static void *nvme_nvm_create_dma_pool(struct nvm_dev *nvmdev, char *name)
> {
> struct nvme_ns *ns = nvmdev->q->queuedata;
> @@ -672,7 +661,6 @@ static struct nvm_dev_ops nvme_nvm_dev_ops = {
> .set_bb_tbl = nvme_nvm_set_bb_tbl,
>
> .submit_io = nvme_nvm_submit_io,
> - .erase_block = nvme_nvm_erase_block,
>
> .create_dma_pool = nvme_nvm_create_dma_pool,
> .destroy_dma_pool = nvme_nvm_destroy_dma_pool,
> diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
> index 33c29cc..6a3534b 100644
> --- a/include/linux/lightnvm.h
> +++ b/include/linux/lightnvm.h
> @@ -56,7 +56,6 @@ typedef int (nvm_get_l2p_tbl_fn)(struct nvm_dev *, u64, u32,
> typedef int (nvm_op_bb_tbl_fn)(struct nvm_dev *, struct ppa_addr, u8 *);
> typedef int (nvm_op_set_bb_fn)(struct nvm_dev *, struct ppa_addr *, int, int);
> typedef int (nvm_submit_io_fn)(struct nvm_dev *, struct nvm_rq *);
> -typedef int (nvm_erase_blk_fn)(struct nvm_dev *, struct nvm_rq *);
> typedef void *(nvm_create_dma_pool_fn)(struct nvm_dev *, char *);
> typedef void (nvm_destroy_dma_pool_fn)(void *);
> typedef void *(nvm_dev_dma_alloc_fn)(struct nvm_dev *, void *, gfp_t,
> @@ -70,7 +69,6 @@ struct nvm_dev_ops {
> nvm_op_set_bb_fn *set_bb_tbl;
>
> nvm_submit_io_fn *submit_io;
> - nvm_erase_blk_fn *erase_block;
>
> nvm_create_dma_pool_fn *create_dma_pool;
> nvm_destroy_dma_pool_fn *destroy_dma_pool;
> @@ -479,10 +477,10 @@ extern int nvm_set_tgt_bb_tbl(struct nvm_tgt_dev *, struct ppa_addr *,
> int, int);
> extern int nvm_max_phys_sects(struct nvm_tgt_dev *);
> extern int nvm_submit_io(struct nvm_tgt_dev *, struct nvm_rq *);
> -extern int nvm_set_rqd_ppalist(struct nvm_dev *, struct nvm_rq *,
> +extern int nvm_erase_sync(struct nvm_tgt_dev *, struct ppa_addr *, int);
> +extern int nvm_set_rqd_ppalist(struct nvm_tgt_dev *, struct nvm_rq *,
> const struct ppa_addr *, int, int);
> -extern void nvm_free_rqd_ppalist(struct nvm_dev *, struct nvm_rq *);
> -extern int nvm_erase_blk(struct nvm_tgt_dev *, struct ppa_addr *, int);
> +extern void nvm_free_rqd_ppalist(struct nvm_tgt_dev *, struct nvm_rq *);
> extern int nvm_get_l2p_tbl(struct nvm_tgt_dev *, u64, u32, nvm_l2p_update_fn *,
> void *);
> extern int nvm_get_area(struct nvm_tgt_dev *, sector_t *, sector_t);
>
Thanks, applied for 4.12.
^ permalink raw reply
* Re: [PATCH 3/3] lightnvm: free reverse device map
From: Matias Bjørling @ 2017-02-24 17:08 UTC (permalink / raw)
To: Javier González; +Cc: linux-block, linux-kernel, Javier González
In-Reply-To: <1487952846-29476-3-git-send-email-javier@cnexlabs.com>
On 02/24/2017 05:14 PM, Javier González wrote:
> Free the reverse mapping table correctly on target tear down
>
> Signed-off-by: Javier González <javier@cnexlabs.com>
> ---
> drivers/lightnvm/core.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
> index ca48792..f1cb485 100644
> --- a/drivers/lightnvm/core.c
> +++ b/drivers/lightnvm/core.c
> @@ -413,6 +413,18 @@ static int nvm_register_map(struct nvm_dev *dev)
> return -ENOMEM;
> }
>
> +static void nvm_unregister_map(struct nvm_dev *dev)
> +{
> + struct nvm_dev_map *rmap = dev->rmap;
> + int i;
> +
> + for (i = 0; i < dev->geo.nr_chnls; i++)
> + kfree(rmap->chnls[i].lun_offs);
> +
> + kfree(rmap->chnls);
> + kfree(rmap);
> +}
> +
> static void nvm_map_to_dev(struct nvm_tgt_dev *tgt_dev, struct ppa_addr *p)
> {
> struct nvm_dev_map *dev_map = tgt_dev->map;
> @@ -994,7 +1006,7 @@ void nvm_free(struct nvm_dev *dev)
> if (dev->dma_pool)
> dev->ops->destroy_dma_pool(dev->dma_pool);
>
> - kfree(dev->rmap);
> + nvm_unregister_map(dev);
> kfree(dev->lptbl);
> kfree(dev->lun_map);
> kfree(dev);
>
Thanks, applied for 4.12.
^ permalink raw reply
* [PATCH 2/2] lightnvm: fix assert fixes and enable checks
From: Matias Bjørling @ 2017-02-24 17:16 UTC (permalink / raw)
To: linux-block, linux-kernel; +Cc: Matias Bjørling
In-Reply-To: <20170224171649.27409-1-matias@cnexlabs.com>
The asserts in _nvme_nvm_check_size are not compiled due to the function
not begin called. Make sure that it is called, and also fix the wrong
sizes of asserts for nvme_nvm_addr_format, and nvme_nvm_bb_tbl, which
checked for number of bits instead of bytes.
Reported-by: Scott Bauer <scott.bauer@intel.com>
Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
---
drivers/nvme/host/lightnvm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index e37b432..b6a67ad 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -241,9 +241,9 @@ static inline void _nvme_nvm_check_size(void)
BUILD_BUG_ON(sizeof(struct nvme_nvm_l2ptbl) != 64);
BUILD_BUG_ON(sizeof(struct nvme_nvm_erase_blk) != 64);
BUILD_BUG_ON(sizeof(struct nvme_nvm_id_group) != 960);
- BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 128);
+ BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 16);
BUILD_BUG_ON(sizeof(struct nvme_nvm_id) != 4096);
- BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 512);
+ BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 64);
}
static int init_grps(struct nvm_id *nvm_id, struct nvme_nvm_id *nvme_nvm_id)
@@ -797,6 +797,8 @@ int nvme_nvm_register(struct nvme_ns *ns, char *disk_name, int node)
struct request_queue *q = ns->queue;
struct nvm_dev *dev;
+ _nvme_nvm_check_size();
+
dev = nvm_alloc_dev(node);
if (!dev)
return -ENOMEM;
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] lightnvm: add generic ocssd detection
From: Matias Bjørling @ 2017-02-24 17:16 UTC (permalink / raw)
To: linux-block, linux-kernel; +Cc: Matias Bjørling
More implementations of OCSSDs are becoming available. Adding each using
pci ids are becoming a hassle. Instead, use a 16 byte string in the
vendor-specific area of the identification command to identify an
Open-Channel SSD.
The large string should make the collision probability with other
vendor-specific strings to be near nil.
Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
---
drivers/nvme/host/lightnvm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 4ea9c93..e37b432 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -986,6 +986,9 @@ int nvme_nvm_ns_supported(struct nvme_ns *ns, struct nvme_id_ns *id)
/* XXX: this is poking into PCI structures from generic code! */
struct pci_dev *pdev = to_pci_dev(ctrl->dev);
+ if (!strncmp((char *)id->vs, "open-channel ssd", 16))
+ return 1;
+
/* QEMU NVMe simulator - PCI ID + Vendor specific bit */
if (pdev->vendor == PCI_VENDOR_ID_CNEX &&
pdev->device == PCI_DEVICE_ID_CNEX_QEMU &&
--
2.9.3
^ permalink raw reply related
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: Bart Van Assche @ 2017-02-24 17:39 UTC (permalink / raw)
To: hch@lst.de, axboe@kernel.dk
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, snitzer@redhat.com
In-Reply-To: <f9b3b2ca-b19b-7c4a-52bb-789c3e2b39e5@kernel.dk>
On Mon, 2017-02-20 at 09:32 -0700, Jens Axboe wrote:
> On 02/20/2017 09:16 AM, Bart Van Assche wrote:
> > On 02/19/2017 11:35 PM, Christoph Hellwig wrote:
> > > On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
> > > > That said, we will look into this again, of course. Christoph, any =
idea?
> > >=20
> > > No idea really - this seems so far away from the code touched, and th=
ere
> > > are no obvious signs for a memory scamble from another object touched
> > > that I think if it really bisects down to that issue it must be a tim=
ing
> > > issue.
> > >=20
> > > But reading Bart's message again: Did you actually bisect it down
> > > to the is commit? Or just test the whole tree? Between the 4.10-rc5
> > > merge and all the block tree there might a few more likely suspects
> > > like the scsi bdi lifetime fixes that James mentioned.
> >=20
> > Hello Christoph,
> >=20
> > As far as I know Jens does not rebase his trees so we can use the commi=
t
> > date to check which patch went in when. From the first of Jan's bdi pat=
ches:
> >=20
> > CommitDate: Thu Feb 2 08:18:41 2017 -0700
> >=20
> > So the bdi patches went in several days after I reported the general pr=
otection
> > fault issue.
> >=20
> > In an e-mail of January 30th I wrote the following: "Running the srp-te=
st
> > software against kernel 4.9.6 and kernel 4.10-rc5 went fine. With your
> > for-4.11/block branch (commit 400f73b23f457a) however I just ran into
> > the following warning: [ ... ]" That means that I did not hit the crash=
with
> > Jens' for-4.11/block branch but only with the for-next branch. The patc=
hes
> > on Jens' for-next branch after that commit that were applied before I r=
an
> > my test are:
> >=20
> > $ PAGER=3D git log --format=3Doneline 400f73b23f457a..fb045ca25cc7 bloc=
k drivers/md/dm{,-mpath,-table}.[ch]
> > fb045ca25cc7b6d46368ab8221774489c2a81648 block: don't assign cmd_flags =
in __blk_rq_prep_clone
> > 82ed4db499b8598f16f8871261bff088d6b0597f block: split scsi_request out =
of struct request
> > 8ae94eb65be9425af4d57a4f4cfebfdf03081e93 block/bsg: move queue creation=
into bsg_setup_queue
> > eb8db831be80692bf4bda3dfc55001daf64ec299 dm: always defer request alloc=
ation to the owner of the request_queue
> > 6d247d7f71d1fa4b66a5f4da7b1daa21510d529b block: allow specifying size f=
or extra command data
> > 5ea708d15a928f7a479987704203616d3274c03b block: simplify blk_init_alloc=
ated_queue
> > e6f7f93d58de74700f83dd0547dd4306248a093d block: fix elevator init check
> > f924ba70c1b12706c6679d793202e8f4c125f7ae Merge branch 'for-4.11/block' =
into for-4.11/rq-refactor
> > 88a7503376f4f3bf303c809d1a389739e1205614 blk-mq: Remove unused variable
> > bef13315e990fd3d3fb4c39013aefd53f06c3657 block: don't try to discard fr=
om __blkdev_issue_zeroout
> > f99e86485cc32cd16e5cc97f9bb0474f28608d84 block: Rename blk_queue_zone_s=
ize and bdev_zone_size
> >=20
> > Do you see any patch in the above list that does not belong to the "spl=
it
> > scsi passthrough fields out of struct request" series and that could ha=
ve
> > caused the reported behavior change?
>=20
> Bart, since you are the only one that can reproduce this, can you just bi=
sect
> your way through that series?
Hello Jens,
Since Christoph also has access to IB hardware I will leave it to Christoph
to do the bisect. Anyway, I just reproduced this crash with Linus' current
tree (commit f1ef09fde17f) by running=A0srp-test/run_tests -r 10 -t 02-sq-o=
n-mq
(see also=A0https://github.com/bvanassche/srp-test):
[ 1629.920553] general protection fault: 0000 [#1] SMP
[ 1629.921193] CPU: 6 PID: 46 Comm: ksoftirqd/6 Tainted: G I 4=
.10.0-dbg+ #1
[ 1629.921289] RIP: 0010:rq_completed+0x12/0x90 [dm_mod]
[ 1629.921316] RSP: 0018:ffffc90001bdbda8 EFLAGS: 00010246
[ 1629.921344] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6b RCX: 00000000000=
00000
[ 1629.921372] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6=
b6b6b
[ 1629.921401] RBP: ffffc90001bdbdc0 R08: ffff8803a3858d48 R09: 00000000000=
00000
[ 1629.921429] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000=
00000
[ 1629.921458] R13: 0000000000000000 R14: ffffffff81c05120 R15: 00000000000=
00004
[ 1629.921489] FS: 0000000000000000(0000) GS:ffff88046ef80000(0000) knlGS:=
0000000000000000
[ 1629.921520] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1629.921547] CR2: 00007fb6324486b8 CR3: 0000000001c0f000 CR4: 00000000001=
406e0
[ 1629.921576] Call Trace:
[ 1629.921605] dm_softirq_done+0xe6/0x1e0 [dm_mod]
[ 1629.921637] blk_done_softirq+0x88/0xa0
[ 1629.921663] __do_softirq+0xba/0x4c0
[ 1629.921744] run_ksoftirqd+0x1a/0x50
[ 1629.921769] smpboot_thread_fn+0x123/0x1e0
[ 1629.921797] kthread+0x107/0x140
[ 1629.921944] ret_from_fork+0x2e/0x40
[ 1629.921972] Code: ff ff 31 f6 48 89 c7 e8 ed 96 2f e1 5d c3 90 66 2e 0f =
1f 84 00 00 00 00 00 55 48 63 f6 48 89 e5 41 55 41 89 d5 41 54 53 48 89 fb =
<4c> 8b a7 70 02 00 00 f0 ff 8c b7 38 03 00 00 e8 3a 43 ff ff 85=20
[ 1629.922093] RIP: rq_completed+0x12/0x90 [dm_mod] RSP: ffffc90001bdbda8
$ gdb drivers/md/dm-mod.ko
(gdb) list *(rq_completed+0x12) =A0=A0=A0
0xdf62 is in rq_completed (drivers/md/dm-rq.c:187).
182 =A0=A0=A0=A0=A0* the md may be freed in dm_put() at the end of this fun=
ction.
183 =A0=A0=A0=A0=A0* Or do dm_get() before calling this function and dm_put=
() later.
184 =A0=A0=A0=A0=A0*/
185 =A0=A0=A0=A0static void rq_completed(struct mapped_device *md, int rw, =
bool run_queue)
186 =A0=A0=A0=A0{
187 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0struct request_queue *q =3D md->que=
ue;
188 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0unsigned long flags;
189
190 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0atomic_dec(&md->pending[rw]);
191
(gdb) disas rq_completed =A0
Dump of assembler code for function rq_completed:
=A0=A00x000000000000df50 <+0>: =A0=A0=A0=A0push =A0=A0%rbp
=A0=A00x000000000000df51 <+1>: =A0=A0=A0=A0movslq %esi,%rsi
=A0=A00x000000000000df54 <+4>: =A0=A0=A0=A0mov =A0=A0=A0%rsp,%rbp
=A0=A00x000000000000df57 <+7>: =A0=A0=A0=A0push =A0=A0%r13
=A0=A00x000000000000df59 <+9>: =A0=A0=A0=A0mov =A0=A0=A0%edx,%r13d
=A0=A00x000000000000df5c <+12>: =A0=A0=A0push =A0=A0%r12
=A0=A00x000000000000df5e <+14>: =A0=A0=A0push =A0=A0%rbx
=A0=A00x000000000000df5f <+15>: =A0=A0=A0mov =A0=A0=A0%rdi,%rbx
=A0=A00x000000000000df62 <+18>: =A0=A0=A0mov =A0=A0=A00x270(%rdi),%r12
[ ... ]
So the crash is caused by an attempt to dereference address 0x6b6b6b6b6b6b6=
b6b
at offset 0x270. I think this means the crash is caused by a use-after-free=
.
Bart.=
^ permalink raw reply
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: Jens Axboe @ 2017-02-24 17:51 UTC (permalink / raw)
To: Bart Van Assche, hch@lst.de
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, snitzer@redhat.com
In-Reply-To: <1487957968.2575.6.camel@sandisk.com>
On 02/24/2017 10:39 AM, Bart Van Assche wrote:
> On Mon, 2017-02-20 at 09:32 -0700, Jens Axboe wrote:
>> On 02/20/2017 09:16 AM, Bart Van Assche wrote:
>>> On 02/19/2017 11:35 PM, Christoph Hellwig wrote:
>>>> On Sun, Feb 19, 2017 at 06:15:41PM -0700, Jens Axboe wrote:
>>>>> That said, we will look into this again, of course. Christoph, any idea?
>>>>
>>>> No idea really - this seems so far away from the code touched, and there
>>>> are no obvious signs for a memory scamble from another object touched
>>>> that I think if it really bisects down to that issue it must be a timing
>>>> issue.
>>>>
>>>> But reading Bart's message again: Did you actually bisect it down
>>>> to the is commit? Or just test the whole tree? Between the 4.10-rc5
>>>> merge and all the block tree there might a few more likely suspects
>>>> like the scsi bdi lifetime fixes that James mentioned.
>>>
>>> Hello Christoph,
>>>
>>> As far as I know Jens does not rebase his trees so we can use the commit
>>> date to check which patch went in when. From the first of Jan's bdi patches:
>>>
>>> CommitDate: Thu Feb 2 08:18:41 2017 -0700
>>>
>>> So the bdi patches went in several days after I reported the general protection
>>> fault issue.
>>>
>>> In an e-mail of January 30th I wrote the following: "Running the srp-test
>>> software against kernel 4.9.6 and kernel 4.10-rc5 went fine. With your
>>> for-4.11/block branch (commit 400f73b23f457a) however I just ran into
>>> the following warning: [ ... ]" That means that I did not hit the crash with
>>> Jens' for-4.11/block branch but only with the for-next branch. The patches
>>> on Jens' for-next branch after that commit that were applied before I ran
>>> my test are:
>>>
>>> $ PAGER= git log --format=oneline 400f73b23f457a..fb045ca25cc7 block drivers/md/dm{,-mpath,-table}.[ch]
>>> fb045ca25cc7b6d46368ab8221774489c2a81648 block: don't assign cmd_flags in __blk_rq_prep_clone
>>> 82ed4db499b8598f16f8871261bff088d6b0597f block: split scsi_request out of struct request
>>> 8ae94eb65be9425af4d57a4f4cfebfdf03081e93 block/bsg: move queue creation into bsg_setup_queue
>>> eb8db831be80692bf4bda3dfc55001daf64ec299 dm: always defer request allocation to the owner of the request_queue
>>> 6d247d7f71d1fa4b66a5f4da7b1daa21510d529b block: allow specifying size for extra command data
>>> 5ea708d15a928f7a479987704203616d3274c03b block: simplify blk_init_allocated_queue
>>> e6f7f93d58de74700f83dd0547dd4306248a093d block: fix elevator init check
>>> f924ba70c1b12706c6679d793202e8f4c125f7ae Merge branch 'for-4.11/block' into for-4.11/rq-refactor
>>> 88a7503376f4f3bf303c809d1a389739e1205614 blk-mq: Remove unused variable
>>> bef13315e990fd3d3fb4c39013aefd53f06c3657 block: don't try to discard from __blkdev_issue_zeroout
>>> f99e86485cc32cd16e5cc97f9bb0474f28608d84 block: Rename blk_queue_zone_size and bdev_zone_size
>>>
>>> Do you see any patch in the above list that does not belong to the "split
>>> scsi passthrough fields out of struct request" series and that could have
>>> caused the reported behavior change?
>>
>> Bart, since you are the only one that can reproduce this, can you just bisect
>> your way through that series?
>
> Hello Jens,
>
> Since Christoph also has access to IB hardware I will leave it to Christoph
> to do the bisect. Anyway, I just reproduced this crash with Linus' current
> tree (commit f1ef09fde17f) by running srp-test/run_tests -r 10 -t 02-sq-on-mq
> (see also https://github.com/bvanassche/srp-test):
>
> [ 1629.920553] general protection fault: 0000 [#1] SMP
> [ 1629.921193] CPU: 6 PID: 46 Comm: ksoftirqd/6 Tainted: G I 4.10.0-dbg+ #1
> [ 1629.921289] RIP: 0010:rq_completed+0x12/0x90 [dm_mod]
> [ 1629.921316] RSP: 0018:ffffc90001bdbda8 EFLAGS: 00010246
> [ 1629.921344] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000
> [ 1629.921372] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6b6b
> [ 1629.921401] RBP: ffffc90001bdbdc0 R08: ffff8803a3858d48 R09: 0000000000000000
> [ 1629.921429] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> [ 1629.921458] R13: 0000000000000000 R14: ffffffff81c05120 R15: 0000000000000004
> [ 1629.921489] FS: 0000000000000000(0000) GS:ffff88046ef80000(0000) knlGS:0000000000000000
> [ 1629.921520] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1629.921547] CR2: 00007fb6324486b8 CR3: 0000000001c0f000 CR4: 00000000001406e0
> [ 1629.921576] Call Trace:
> [ 1629.921605] dm_softirq_done+0xe6/0x1e0 [dm_mod]
> [ 1629.921637] blk_done_softirq+0x88/0xa0
> [ 1629.921663] __do_softirq+0xba/0x4c0
> [ 1629.921744] run_ksoftirqd+0x1a/0x50
> [ 1629.921769] smpboot_thread_fn+0x123/0x1e0
> [ 1629.921797] kthread+0x107/0x140
> [ 1629.921944] ret_from_fork+0x2e/0x40
> [ 1629.921972] Code: ff ff 31 f6 48 89 c7 e8 ed 96 2f e1 5d c3 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 63 f6 48 89 e5 41 55 41 89 d5 41 54 53 48 89 fb <4c> 8b a7 70 02 00 00 f0 ff 8c b7 38 03 00 00 e8 3a 43 ff ff 85
> [ 1629.922093] RIP: rq_completed+0x12/0x90 [dm_mod] RSP: ffffc90001bdbda8
>
> $ gdb drivers/md/dm-mod.ko
> (gdb) list *(rq_completed+0x12)
> 0xdf62 is in rq_completed (drivers/md/dm-rq.c:187).
> 182 * the md may be freed in dm_put() at the end of this function.
> 183 * Or do dm_get() before calling this function and dm_put() later.
> 184 */
> 185 static void rq_completed(struct mapped_device *md, int rw, bool run_queue)
> 186 {
> 187 struct request_queue *q = md->queue;
> 188 unsigned long flags;
> 189
> 190 atomic_dec(&md->pending[rw]);
> 191
> (gdb) disas rq_completed
> Dump of assembler code for function rq_completed:
> 0x000000000000df50 <+0>: push %rbp
> 0x000000000000df51 <+1>: movslq %esi,%rsi
> 0x000000000000df54 <+4>: mov %rsp,%rbp
> 0x000000000000df57 <+7>: push %r13
> 0x000000000000df59 <+9>: mov %edx,%r13d
> 0x000000000000df5c <+12>: push %r12
> 0x000000000000df5e <+14>: push %rbx
> 0x000000000000df5f <+15>: mov %rdi,%rbx
> 0x000000000000df62 <+18>: mov 0x270(%rdi),%r12
> [ ... ]
>
> So the crash is caused by an attempt to dereference address 0x6b6b6b6b6b6b6b6b
> at offset 0x270. I think this means the crash is caused by a use-after-free.
Christoph, if you have the setup to reproduce this now, can you bisect and
see wtf is going on here?
--
Jens Axboe
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Bart Van Assche @ 2017-02-24 18:44 UTC (permalink / raw)
To: paolo.valente@linaro.org
Cc: ulf.hansson@linaro.org, tj@kernel.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org, axboe@kernel.dk
In-Reply-To: <62F8F65E-A376-44EB-B53C-C2CFB8F8693F@linaro.org>
On Wed, 2017-02-22 at 22:29 +0100, Paolo Valente wrote:
> thanks for this second attempt of yours. Although, unfortunately, not
> providing some clear indication of the exact cause of your hang (apart
> from a possible deadlock), your log helped me notice another bug.
>=20
> At any rate, as I have just written to Jens, I have pushed a new
> version of the branch [1] (not just added new commits, but also
> integrated some old commit with new changes, to make it more quickly).
> The branch now contains both a fix for the above bug, and, more
> importantly, a fix for the circular dependencies that were still
> lurking around. Could you please test it?
Hello Paolo,
I have good news: the same test system boots normally with the same
kernel config I used during my previous tests and with the latest
bfq-mq code (commit a965d19585c0) merged with kernel v4.10.
Thanks,
Bart.=
^ permalink raw reply
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: Linus Torvalds @ 2017-02-24 19:43 UTC (permalink / raw)
To: Bart Van Assche
Cc: hch@lst.de, axboe@kernel.dk, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, snitzer@redhat.com
In-Reply-To: <1487957968.2575.6.camel@sandisk.com>
On Fri, Feb 24, 2017 at 9:39 AM, Bart Van Assche
<Bart.VanAssche@sandisk.com> wrote:
>
> So the crash is caused by an attempt to dereference address 0x6b6b6b6b6b6b6b6b
> at offset 0x270. I think this means the crash is caused by a use-after-free.
Yeah, that's POISON_FREE, and that might explain why you see crashes
that others don't - you obviously have SLAB poisoning enabled. Jens
may not have.
%rdi is "struct mapped_device *md", which came from dm_softirq_done() doing
struct dm_rq_target_io *tio = tio_from_request(rq);
struct request *clone = tio->clone;
int rw;
if (!clone) {
rq_end_stats(tio->md, rq);
rw = rq_data_dir(rq);
if (!rq->q->mq_ops)
blk_end_request_all(rq, tio->error);
else
blk_mq_end_request(rq, tio->error);
rq_completed(tio->md, rw, false);
return;
}
so it's the 'tio' pointer that has been free'd. But it's worth noting
that we did apparently successfully dereference "tio" earlier in that
dm_softirq_done() *without* getting the poison value, so what I think
might be going on is that the 'tio' thing gets free'd when the code
does the blk_end_request_all()/blk_mq_end_request() call.
Which makes sense - that ends the lifetime of the request, which in
turn also ends the lifetime of the "tio_from_request()", no?
So the fix may be as simple as just doing
if (!clone) {
struct mapped_device *md = tio->md;
rq_end_stats(md, rq);
...
rq_completed(md, rw, false);
return;
}
because the 'mapped_device' pointer hopefully is still valid, it's
just 'tio' that has been freed.
Jens? Bart? Christoph? Somebody who knows this code should
double-check my thinking above. I don't actually know the tio
lifetimes, I'm just going by looking at how earlier accesses seemed to
be fine (eg that "tio->clone" got us NULL, not a POISON_FREE pointer,
for example).
Linus
^ permalink raw reply
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: Jens Axboe @ 2017-02-24 20:00 UTC (permalink / raw)
To: Linus Torvalds, Bart Van Assche
Cc: hch@lst.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, snitzer@redhat.com
In-Reply-To: <CA+55aFw7T8hsZpMfWuo5e=DnsuRjp8cfQzGb8Qeng=RRR61fYA@mail.gmail.com>
On 02/24/2017 12:43 PM, Linus Torvalds wrote:
> On Fri, Feb 24, 2017 at 9:39 AM, Bart Van Assche
> <Bart.VanAssche@sandisk.com> wrote:
>>
>> So the crash is caused by an attempt to dereference address 0x6b6b6b6b6b6b6b6b
>> at offset 0x270. I think this means the crash is caused by a use-after-free.
>
> Yeah, that's POISON_FREE, and that might explain why you see crashes
> that others don't - you obviously have SLAB poisoning enabled. Jens
> may not have.
>
> %rdi is "struct mapped_device *md", which came from dm_softirq_done() doing
>
> struct dm_rq_target_io *tio = tio_from_request(rq);
> struct request *clone = tio->clone;
> int rw;
>
> if (!clone) {
> rq_end_stats(tio->md, rq);
> rw = rq_data_dir(rq);
> if (!rq->q->mq_ops)
> blk_end_request_all(rq, tio->error);
> else
> blk_mq_end_request(rq, tio->error);
> rq_completed(tio->md, rw, false);
> return;
> }
>
> so it's the 'tio' pointer that has been free'd. But it's worth noting
> that we did apparently successfully dereference "tio" earlier in that
> dm_softirq_done() *without* getting the poison value, so what I think
> might be going on is that the 'tio' thing gets free'd when the code
> does the blk_end_request_all()/blk_mq_end_request() call.
>
> Which makes sense - that ends the lifetime of the request, which in
> turn also ends the lifetime of the "tio_from_request()", no?
>
> So the fix may be as simple as just doing
>
> if (!clone) {
> struct mapped_device *md = tio->md;
>
> rq_end_stats(md, rq);
> ...
> rq_completed(md, rw, false);
> return;
> }
>
> because the 'mapped_device' pointer hopefully is still valid, it's
> just 'tio' that has been freed.
>
> Jens? Bart? Christoph? Somebody who knows this code should
> double-check my thinking above. I don't actually know the tio
> lifetimes, I'm just going by looking at how earlier accesses seemed to
> be fine (eg that "tio->clone" got us NULL, not a POISON_FREE pointer,
> for example).
I think that is spot on. With the request changes for CDBs, for non
blk-mq, we know also carry the payload after the request. But since
blk-mq never frees the request, the above use-after-free with poison
will only happen for !mq. Caching 'md' and avoiding a dereference of
'tio' after calling blk_end_request_all() will likely fix it.
Bart, can you test that?
--
Jens Axboe
^ permalink raw reply
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: Jens Axboe @ 2017-02-24 20:22 UTC (permalink / raw)
To: Linus Torvalds, Bart Van Assche
Cc: hch@lst.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, snitzer@redhat.com
In-Reply-To: <0af4ed69-a9d0-44be-701c-ced76b84bfef@kernel.dk>
On 02/24/2017 01:00 PM, Jens Axboe wrote:
> On 02/24/2017 12:43 PM, Linus Torvalds wrote:
>> On Fri, Feb 24, 2017 at 9:39 AM, Bart Van Assche
>> <Bart.VanAssche@sandisk.com> wrote:
>>>
>>> So the crash is caused by an attempt to dereference address 0x6b6b6b6b6b6b6b6b
>>> at offset 0x270. I think this means the crash is caused by a use-after-free.
>>
>> Yeah, that's POISON_FREE, and that might explain why you see crashes
>> that others don't - you obviously have SLAB poisoning enabled. Jens
>> may not have.
>>
>> %rdi is "struct mapped_device *md", which came from dm_softirq_done() doing
>>
>> struct dm_rq_target_io *tio = tio_from_request(rq);
>> struct request *clone = tio->clone;
>> int rw;
>>
>> if (!clone) {
>> rq_end_stats(tio->md, rq);
>> rw = rq_data_dir(rq);
>> if (!rq->q->mq_ops)
>> blk_end_request_all(rq, tio->error);
>> else
>> blk_mq_end_request(rq, tio->error);
>> rq_completed(tio->md, rw, false);
>> return;
>> }
>>
>> so it's the 'tio' pointer that has been free'd. But it's worth noting
>> that we did apparently successfully dereference "tio" earlier in that
>> dm_softirq_done() *without* getting the poison value, so what I think
>> might be going on is that the 'tio' thing gets free'd when the code
>> does the blk_end_request_all()/blk_mq_end_request() call.
>>
>> Which makes sense - that ends the lifetime of the request, which in
>> turn also ends the lifetime of the "tio_from_request()", no?
>>
>> So the fix may be as simple as just doing
>>
>> if (!clone) {
>> struct mapped_device *md = tio->md;
>>
>> rq_end_stats(md, rq);
>> ...
>> rq_completed(md, rw, false);
>> return;
>> }
>>
>> because the 'mapped_device' pointer hopefully is still valid, it's
>> just 'tio' that has been freed.
>>
>> Jens? Bart? Christoph? Somebody who knows this code should
>> double-check my thinking above. I don't actually know the tio
>> lifetimes, I'm just going by looking at how earlier accesses seemed to
>> be fine (eg that "tio->clone" got us NULL, not a POISON_FREE pointer,
>> for example).
>
> I think that is spot on. With the request changes for CDBs, for non
> blk-mq, we know also carry the payload after the request. But since
> blk-mq never frees the request, the above use-after-free with poison
> will only happen for !mq. Caching 'md' and avoiding a dereference of
> 'tio' after calling blk_end_request_all() will likely fix it.
>
> Bart, can you test that?
Bart, I pushed a fix here:
http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=61febef40bfe8ab68259d8545257686e8a0d91d1
--
Jens Axboe
^ permalink raw reply
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: Bart Van Assche @ 2017-02-24 21:15 UTC (permalink / raw)
To: torvalds@linux-foundation.org, axboe@kernel.dk
Cc: hch@lst.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, snitzer@redhat.com
In-Reply-To: <0dc039e5-58c5-d328-0b81-bf9e7d782675@kernel.dk>
On Fri, 2017-02-24 at 13:22 -0700, Jens Axboe wrote:
> Bart, I pushed a fix here:
>=20
> http://git.kernel.dk/cgit/linux-block/commit/?h=3Dfor-linus&id=3D61febef4=
0bfe8ab68259d8545257686e8a0d91d1
Hello Jens,
The same test passes against the kernel I obtained by merging your for-linu=
s
branch with the same version of Linus' master branch I mentioned in a previ=
ous
e-mail. Feel free to add my Tested-by to the patch "dm-rq: don't dereferenc=
e
request payload after ending request".
Thanks,
Bart.=
^ permalink raw reply
* Re: [PATCH V2 1/3] blk-mq: allocate blk_mq_tags and requests in correct node
From: Jens Axboe @ 2017-02-24 22:23 UTC (permalink / raw)
To: Shaohua Li, linux-kernel, linux-block; +Cc: bhelgaas, hch
In-Reply-To: <b41e8f74-007d-c818-4915-3ea3b7c229b5@fb.com>
On 02/01/2017 12:09 PM, Jens Axboe wrote:
> On 02/01/2017 09:53 AM, Shaohua Li wrote:
>> blk_mq_tags/requests of specific hardware queue are mostly used in
>> specific cpus, which might not be in the same numa node as disk. For
>> example, a nvme card is in node 0. half hardware queue will be used by
>> node 0, the other node 1.
>
> All three patches look good to me. Bjorn, to avoid complications, if
> you can review/ack patch #2, then I will queue it up through the block
> tree for 4.11.
Bjorn, ping. You were CC'ed on the original patch three weeks ago.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH V2 1/3] blk-mq: allocate blk_mq_tags and requests in correct node
From: Bjorn Helgaas @ 2017-02-24 22:30 UTC (permalink / raw)
To: Jens Axboe
Cc: Shaohua Li, linux-kernel@vger.kernel.org, linux-block,
Christoph Hellwig
In-Reply-To: <fa1eaadf-db72-a642-a917-3f633af2ca55@kernel.dk>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Fri, Feb 24, 2017 at 4:23 PM, Jens Axboe <axboe@kernel.dk> wrote:
> On 02/01/2017 12:09 PM, Jens Axboe wrote:
>> On 02/01/2017 09:53 AM, Shaohua Li wrote:
>>> blk_mq_tags/requests of specific hardware queue are mostly used in
>>> specific cpus, which might not be in the same numa node as disk. For
>>> example, a nvme card is in node 0. half hardware queue will be used by
>>> node 0, the other node 1.
>>
>> All three patches look good to me. Bjorn, to avoid complications, if
>> you can review/ack patch #2, then I will queue it up through the block
>> tree for 4.11.
>
> Bjorn, ping. You were CC'ed on the original patch three weeks ago.
Acked, sorry I missed it.
[-- Attachment #2: Type: text/html, Size: 877 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/3] PCI: add an API to get node from vector
From: Bjorn Helgaas @ 2017-02-24 22:29 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-kernel, linux-block, bhelgaas, hch, axboe
In-Reply-To: <d0f9b1bda8c27f058c95f88015e013b9d8131dc0.1485971427.git.shli@fb.com>
On Wed, Feb 01, 2017 at 09:53:15AM -0800, Shaohua Li wrote:
> Next patch will use the API to get the node from vector for nvme device
>
> Signed-off-by: Shaohua Li <shli@fb.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Sorry I missed this; I normally work from the linux-pci patchwork, and
this didn't show up there because it wasn't cc'd to linux-pci. But I
should have noticed anyway.
> ---
> drivers/pci/msi.c | 16 ++++++++++++++++
> include/linux/pci.h | 6 ++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 50c5003..ab7aee7 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -1313,6 +1313,22 @@ const struct cpumask *pci_irq_get_affinity(struct pci_dev *dev, int nr)
> }
> EXPORT_SYMBOL(pci_irq_get_affinity);
>
> +/**
> + * pci_irq_get_node - return the numa node of a particular msi vector
> + * @pdev: PCI device to operate on
> + * @vec: device-relative interrupt vector index (0-based).
> + */
> +int pci_irq_get_node(struct pci_dev *pdev, int vec)
> +{
> + const struct cpumask *mask;
> +
> + mask = pci_irq_get_affinity(pdev, vec);
> + if (mask)
> + return local_memory_node(cpu_to_node(cpumask_first(mask)));
> + return dev_to_node(&pdev->dev);
> +}
> +EXPORT_SYMBOL(pci_irq_get_node);
> +
> struct pci_dev *msi_desc_to_pci_dev(struct msi_desc *desc)
> {
> return to_pci_dev(desc->dev);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e2d1a12..df2c649 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1334,6 +1334,7 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,
> void pci_free_irq_vectors(struct pci_dev *dev);
> int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
> const struct cpumask *pci_irq_get_affinity(struct pci_dev *pdev, int vec);
> +int pci_irq_get_node(struct pci_dev *pdev, int vec);
>
> #else
> static inline int pci_msi_vec_count(struct pci_dev *dev) { return -ENOSYS; }
> @@ -1384,6 +1385,11 @@ static inline const struct cpumask *pci_irq_get_affinity(struct pci_dev *pdev,
> {
> return cpu_possible_mask;
> }
> +
> +static inline int pci_irq_get_node(struct pci_dev *pdev, int vec)
> +{
> + return first_online_node;
> +}
> #endif
>
> static inline int
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH V2 2/3] PCI: add an API to get node from vector
From: Jens Axboe @ 2017-02-24 22:34 UTC (permalink / raw)
To: Bjorn Helgaas, Shaohua Li; +Cc: linux-kernel, linux-block, bhelgaas, hch
In-Reply-To: <20170224222943.GB26430@bhelgaas-glaptop.roam.corp.google.com>
On 02/24/2017 03:29 PM, Bjorn Helgaas wrote:
> On Wed, Feb 01, 2017 at 09:53:15AM -0800, Shaohua Li wrote:
>> Next patch will use the API to get the node from vector for nvme device
>>
>> Signed-off-by: Shaohua Li <shli@fb.com>
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> Sorry I missed this; I normally work from the linux-pci patchwork, and
> this didn't show up there because it wasn't cc'd to linux-pci. But I
> should have noticed anyway.
Thanks Bjorn!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH V2 1/3] blk-mq: allocate blk_mq_tags and requests in correct node
From: Jens Axboe @ 2017-02-25 2:54 UTC (permalink / raw)
To: Shaohua Li, linux-kernel, linux-block; +Cc: bhelgaas, hch
In-Reply-To: <a52afb3e09691267f2240331ef0b9962f793703d.1485971427.git.shli@fb.com>
On 02/01/2017 10:53 AM, Shaohua Li wrote:
> blk_mq_tags/requests of specific hardware queue are mostly used in
> specific cpus, which might not be in the same numa node as disk. For
> example, a nvme card is in node 0. half hardware queue will be used by
> node 0, the other node 1.
Applied 1-3 for this series, thanks Shaohua!
--
Jens Axboe
^ permalink raw reply
* [RFC PATCH v2] lightnvm: pblk
From: Javier González @ 2017-02-25 16:53 UTC (permalink / raw)
To: mb; +Cc: linux-block, linux-kernel, Javier González
This patch introduces pblk, a new target for LightNVM implementing a
full host-based FTL. Details on the commit message.
Changes since v1:
* Rebase on top of Matias' for-4.12/core
* Move from per-LUN block allocation to a line model. This means that a
whole lines across all LUNs is allocated at a time. Data is still
stripped in a round-robin fashion at a page granurality.
* Implement new disk format scheme, where metadata is stored per line
instead of per LUN. This allows for space optimizations.
* Improvements on GC workqueue management and victim selection.
* Implement sysfs interface to query pblk's operation and statistics.
* Implement a user - GC I/O rate-limiter
* Various bug fixes
Javier González (1):
lightnvm: physical block device (pblk) target
Documentation/lightnvm/pblk.txt | 21 +
drivers/lightnvm/Kconfig | 18 +
drivers/lightnvm/Makefile | 5 +
drivers/lightnvm/pblk-cache.c | 119 +++
drivers/lightnvm/pblk-core.c | 1539 ++++++++++++++++++++++++++++++++++++++
drivers/lightnvm/pblk-gc.c | 401 ++++++++++
drivers/lightnvm/pblk-init.c | 937 +++++++++++++++++++++++
drivers/lightnvm/pblk-map.c | 146 ++++
drivers/lightnvm/pblk-rb.c | 857 +++++++++++++++++++++
drivers/lightnvm/pblk-read.c | 512 +++++++++++++
drivers/lightnvm/pblk-recovery.c | 142 ++++
drivers/lightnvm/pblk-rl.c | 219 ++++++
drivers/lightnvm/pblk-sysfs.c | 947 +++++++++++++++++++++++
drivers/lightnvm/pblk-write.c | 407 ++++++++++
drivers/lightnvm/pblk.h | 958 ++++++++++++++++++++++++
15 files changed, 7228 insertions(+)
create mode 100644 Documentation/lightnvm/pblk.txt
create mode 100644 drivers/lightnvm/pblk-cache.c
create mode 100644 drivers/lightnvm/pblk-core.c
create mode 100644 drivers/lightnvm/pblk-gc.c
create mode 100644 drivers/lightnvm/pblk-init.c
create mode 100644 drivers/lightnvm/pblk-map.c
create mode 100644 drivers/lightnvm/pblk-rb.c
create mode 100644 drivers/lightnvm/pblk-read.c
create mode 100644 drivers/lightnvm/pblk-recovery.c
create mode 100644 drivers/lightnvm/pblk-rl.c
create mode 100644 drivers/lightnvm/pblk-sysfs.c
create mode 100644 drivers/lightnvm/pblk-write.c
create mode 100644 drivers/lightnvm/pblk.h
--
2.7.4
^ permalink raw reply
* [WIP BRANCH] cgroups support in bfq-mq WIP branch
From: Paolo Valente @ 2017-02-25 17:44 UTC (permalink / raw)
To: ulf.hansson@linaro.org, tj@kernel.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org, axboe@kernel.dk,
Bart Van Assche
Hi,
I've just completed cgroups support, and I'd like to highlight the
main blk-mq issue that I have found along the way. I have pushed the
commit that completes the support for cgroups to the usual WIP branch
[1]. Before moving to this issue, I have preliminary question about
the scheduler name, since I'm about to start preparing the patch
series for submission. So far, I have used bfq-mq as a temporary
name. Are we fine with it, or should I change it, for example, to
just bfq? Jens?
I've found a sort of circular dependency in blk-mq, related to
scheduler initialization. To describe both the issue and how I've
addressed it, I'm pasting the message of the new commit.
This commit completes cgroups support for bfq-mq. In particular, it =
deals with
a sort of circular dependency introduced in blk-mq: the function
blkcg_activate_policy, invoked during scheduler initialization, =
triggers the
invocation of the has_work scheduler hook (before the init function =
is
finished). To adress this issue, this commit moves the invocation of
blkcg_activate_policy after the initialization of all the fields =
that could be
initialized before invoking blkcg_activate_policy itself. This =
enables has_work
to correctly return false, and thus to prevent the blk-mq stack from =
invoking
further scheduler hooks before the init function is finished.
Thanks,
Paolo
[1] https://github.com/Algodev-github/bfq-mq=
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Paolo Valente @ 2017-02-25 17:45 UTC (permalink / raw)
To: Bart Van Assche
Cc: ulf.hansson@linaro.org, tj@kernel.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org, axboe@kernel.dk
In-Reply-To: <1487961857.2575.8.camel@sandisk.com>
> Il giorno 24 feb 2017, alle ore 19:44, Bart Van Assche =
<bart.vanassche@sandisk.com> ha scritto:
>=20
> On Wed, 2017-02-22 at 22:29 +0100, Paolo Valente wrote:
>> thanks for this second attempt of yours. Although, unfortunately, =
not
>> providing some clear indication of the exact cause of your hang =
(apart
>> from a possible deadlock), your log helped me notice another bug.
>>=20
>> At any rate, as I have just written to Jens, I have pushed a new
>> version of the branch [1] (not just added new commits, but also
>> integrated some old commit with new changes, to make it more =
quickly).
>> The branch now contains both a fix for the above bug, and, more
>> importantly, a fix for the circular dependencies that were still
>> lurking around. Could you please test it?
>=20
> Hello Paolo,
>=20
Hi
> I have good news: the same test system boots normally with the same
> kernel config I used during my previous tests and with the latest
> bfq-mq code (commit a965d19585c0) merged with kernel v4.10.
>=20
Whew, I was longing for you reply, thanks :)
Should you want to have a look at it, I have just finished completing
cgroups support too, as you have probably already read from my
previous email.
Thanks,
Paolo
> Thanks,
>=20
> Bart.
^ permalink raw reply
* Re: [GIT PULL] Block pull request for- 4.11-rc1
From: hch @ 2017-02-25 18:17 UTC (permalink / raw)
To: Jens Axboe
Cc: Linus Torvalds, Bart Van Assche, hch@lst.de,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
snitzer@redhat.com
In-Reply-To: <0dc039e5-58c5-d328-0b81-bf9e7d782675@kernel.dk>
On Fri, Feb 24, 2017 at 01:22:42PM -0700, Jens Axboe wrote:
> Bart, I pushed a fix here:
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=61febef40bfe8ab68259d8545257686e8a0d91d1
Yeah, this looks fine to me. It was broken on blk-mq before, but
basically impossible to hit. I wonder if we should have a debug mode
where we set requests to a known pattern after they are freed to catch
these sort of bugs.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox