I have a target set up in vn2vn mode with two iblock target luns.
If I delete either lun 0 or lun 1, a REPORT LUNS command from the client acts
as expected.
It reports either LUN 1 or LUN 0, whichever is remaining.
When I delete both LUNs, so I still have a TPG but no LUNs under it, the target
crashes.
The crash is in target_report_luns. It seems that the data buffer is bad. I'm
always sending
the report luns command to lun 0. What's strange is that tpg_virt_lun0 works
fine with lun1
present but I get the crash when it is not. I have not been able to figure out
what is causing
the crash.
Any ideas? Seems like this should be legal as there is still a session, and the
virtual lun0 should just report no luns.
Bad target setup from targetcli:
o- tcm_fc
.........................................................................................................
[1 Target]
o- 20:00:00:25:90:61:17:02
.......................................................................................
[enabled]
o- acls
..........................................................................................................
[1 ACL]
| o- 20:00:00:25:90:0e:5b:90
..............................................................................
[0 Mapped LUN]
o- luns
..........................................................................................................
[0 LUN]
/>
Crash on the target:
[ 1633.748949] BUG: unable to handle kernel paging request at ffffc900026a1000
[ 1633.755983] IP: [<ffffffffa03bd9e4>] target_report_luns+0x104/0x150
[target_core_mod]
[ 1633.763875] PGD 1a980f067 PUD 32f802067 PMD 324500067 PTE 0
[ 1633.769661] Oops: 0002 [#1] SMP
[ 1633.772971] CPU 2
[ 1633.774800] Modules linked in: target_core_pscsi target_core_file
target_core_iblock fcoe libfcoe netconsole iscsi_target_mod tcm_loop tcm_fc
libfc scsi_transport_fc scsi_tgt ta
[ 1633.979481] Call Trace:
[ 1633.981926] [<ffffffffa03cfde6>] ?
__transport_add_tasks_from_cmd+0xb6/0x190 [target_core_mod]
[ 1633.990615] [<ffffffffa03d4288>] __transport_execute_tasks+0x68/0x180
[target_core_mod]
[ 1633.998701] [<ffffffffa03d43dd>] transport_execute_tasks+0x3d/0x190
[target_core_mod]
[ 1634.006611] [<ffffffffa03d46a6>] transport_generic_new_cmd+0x166/0x500
[target_core_mod]
[ 1634.014782] [<ffffffffa03d4a93>] transport_handle_cdb_direct+0x53/0xc0
[target_core_mod]
[ 1634.022951] [<ffffffffa03d4bd7>] target_submit_cmd+0xd7/0x140
[target_core_mod]
[ 1634.030343] [<ffffffff815f2bb6>] ? _raw_spin_unlock_bh+0x16/0x20
[ 1634.036436] [<ffffffffa041e714>] ft_send_work+0x1f4/0x400 [tcm_fc]
[ 1634.042700] [<ffffffffa041e520>] ? ft_dump_cmd+0x210/0x210 [tcm_fc]
[ 1634.049055] [<ffffffff81074719>] process_one_work+0x129/0x440
[ 1634.054888] [<ffffffff8107578a>] worker_thread+0x16a/0x350
[ 1634.060458] [<ffffffff81075620>] ? manage_workers.clone.20+0x250/0x250
[ 1634.067068] [<ffffffff8107a6ae>] kthread+0x9e/0xb0
[ 1634.071958] [<ffffffff815fc464>] kernel_thread_helper+0x4/0x10
[ 1634.077878] [<ffffffff8107a610>] ? flush_kthread_worker+0xc0/0xc0
[ 1634.084053] [<ffffffff815fc460>] ? gs_change+0x13/0x13
(gdb) l * target_report_luns+0x104
0x69e4 is in target_report_luns (drivers/target/target_core_device.c:700).
695 * See SPC3 r07, page 159.
696 */
697 done:
698 transport_kunmap_data_sg(se_cmd);
699 lun_count *= 8;
700 buf[0] = ((lun_count >> 24) & 0xff);
701 buf[1] = ((lun_count >> 16) & 0xff);
702 buf[2] = ((lun_count >> 8) & 0xff);
_______________________________________________
devel mailing list
[email protected]
https://lists.open-fcoe.org/mailman/listinfo/devel
