On Tue, May 19, 2015 at 08:22:31AM +0200, Christoph Hellwig wrote:
> On Mon, May 18, 2015 at 11:05:47PM -0700, Nicholas A. Bellinger wrote:
> > > [ 12.830576] kernel BUG at ../drivers/target/target_core_device.c:337!
> > >
> >
> > How did you hit this..?
>
> tcm_node --block iblock_0/array /dev/sda
>
> line=$(tcm_loop --createnexus=0)
> wwn=$(echo $line | awk '{print $15}')
> tcm_loop --addlun=$wwn 0 0 iblock_0/array
And here is the fix. Seems like anything using dynamic node ACLs was
broken the same way (I could reproduce it with vhost as well).
I don't really like how HBA_FLAGS_INTERNAL_USE means this is a virtual
lun0, so I'll send another patch to replace it with a per-device flag
eventually.
---
>From 9fd0e75cffde876b84b08952cc7f026d4e08d77a Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@xxxxxx>
Date: Thu, 21 May 2015 18:58:21 +0200
Subject: target: don't add lun0 to tpg_lun_hlist
We never want to find the virtual lun0 when looking up a lun on the TPG,
otherwise the core code gets really confused.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
---
drivers/target/target_core_tpg.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c
index b8c2a32..ced1dd6 100644
--- a/drivers/target/target_core_tpg.c
+++ b/drivers/target/target_core_tpg.c
@@ -647,7 +647,8 @@ int core_tpg_add_lun(
lun->lun_access = lun_access;
lun->lun_status = TRANSPORT_LUN_STATUS_ACTIVE;
- hlist_add_head_rcu(&lun->link, &tpg->tpg_lun_hlist);
+ if (!(dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE))
+ hlist_add_head_rcu(&lun->link, &tpg->tpg_lun_hlist);
mutex_unlock(&tpg->tpg_lun_mutex);
@@ -687,7 +688,8 @@ void core_tpg_remove_lun(
}
lun->lun_status = TRANSPORT_LUN_STATUS_FREE;
- hlist_del_rcu(&lun->link);
+ if (!(dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE))
+ hlist_del_rcu(&lun->link);
mutex_unlock(&tpg->tpg_lun_mutex);
percpu_ref_exit(&lun->lun_ref);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
