@@ -64,19 +64,23 @@ static void pblk_put_line_back(struct pblk *pblk, struct pblk_line *line)
struct pblk_line_mgmt *l_mg = &pblk->l_mg;
struct list_head *move_list;
+ spin_lock(&l_mg->gc_lock);
spin_lock(&line->lock);
WARN_ON(line->state != PBLK_LINESTATE_GC);
line->state = PBLK_LINESTATE_CLOSED;
trace_pblk_line_state(pblk_disk_name(pblk), line->id,
line->state);
+
+ /* We need to reset gc_group in order to ensure that
+ * pblk_line_gc_list will return proper move_list
+ * since right now current line is not on any of the
+ * gc lists.
+ */
+ line->gc_group = PBLK_LINEGC_NONE;
move_list = pblk_line_gc_list(pblk, line);
spin_unlock(&line->lock);
-
- if (move_list) {
- spin_lock(&l_mg->gc_lock);
- list_add_tail(&line->list, move_list);
- spin_unlock(&l_mg->gc_lock);
- }
+ list_add_tail(&line->list, move_list);
+ spin_unlock(&l_mg->gc_lock);
}
static void pblk_gc_line_ws(struct work_struct *work)
In current implementation of pblk_put_line_back behaviour there are two cases which are not handled. First one is the race condition with __pblk_map_invalidate in which function we check for line state, which might be closed, but still not added to any list and thus explode in list_move_tail. This is due to lack of locking both gc_lock and line lock in pblk_put_line_back current implementation. The second issue is that when we are in that function, line is not on any list and pblk_line_gc_list might hit the same gc group and thus not return any move_list. Then our line will stuck forever unassigned to any list. Simply resetting gc_list to none will fix that. Fixes: a4bd217 ("lightnvm: physical block device (pblk) target") Signed-off-by: Igor Konopko <igor.j.konopko@intel.com> Reviewed-by: Javier González <javier@javigon.com> Reviewed-by: Hans Holmberg <hans.holmberg@cnexlabs.com> --- drivers/lightnvm/pblk-gc.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)