On Thu, 2014-06-12 at 09:18 +0200, Thomas Glanzmann wrote:
> Hello Nab,
>
> > Please test!
>
> I tested the same: 2 LUNs, 2 ESX Servers, LUNs presented in Demo Mode,
> created one VMFS on each LUN, depoyed a thin provisioned VM and cloned
> it using XCOPY to the other LUN. Target PANICS:
<SNIP>
> [ 252.978868] BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
> [ 252.986913] IP: [<ffffffff8139b6e9>] _raw_spin_lock_irqsave+0x8/0x23
> [ 252.993425] PGD 0
> [ 252.995569] Oops: 0002 [#1] SMP
> [ 252.999009] Modules linked in: target_core_pscsi target_core_file target_core_iblock tcm_loop iscsi_target_mod tcm_fc libfc scsi_transport_fc scsi_tgt target_core_mod bridge configfs 8021q garp stp llc bonding joydev hid_generic usbhid hid loop x86_pkg_temp_thermal coretemp kvm_intel kvm ghash_clmulni_intel aesni_intel iTCO_wdt ehci_pci aes_x86_64 ablk_helper snd_pcm iTCO_vendor_support ehci_hcd cryptd lpc_ich sb_edac usbcore psmouse snd_timer lrw i2c_i801 serio_raw snd edac_core soundcore evdev gf128mul pcspkr acpi_cpufreq glue_helper mfd_core ipmi_si ioatdma usb_common ipmi_msghandler tpm_tis tpm processor wmi thermal_sys button ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif crct10dif_common crc32c_intel igb ahci i2c_algo_bit libahci i2c_core libata dca microcode ptp scsi_mod pps_core [last unloaded: target_core_mod]
> [ 253.077963] CPU: 2 PID: 80 Comm: kworker/2:1 Not tainted 3.15.0+ #4
> [ 253.084298] Hardware name: Supermicro X9SRD-F/X9SRD-F, BIOS 1.0a 10/15/2012
> [ 253.091359] Workqueue: xcopy_wq target_xcopy_do_work [target_core_mod]
> [ 253.098025] task: ffff88103f2fe910 ti: ffff8810247f4000 task.ti: ffff8810247f4000
> [ 253.105610] RIP: 0010:[<ffffffff8139b6e9>] [<ffffffff8139b6e9>] _raw_spin_lock_irqsave+0x8/0x23
> [ 253.120216] RSP: 0018:ffff8810247f7d20 EFLAGS: 00010046
> [ 253.125601] RAX: 0000000000000246 RBX: ffff8800789aa008 RCX: ffff8800789aa0c8
> [ 253.132809] RDX: 0000000000010000 RSI: ffff8800789aa008 RDI: 0000000000000070
> [ 253.140007] RBP: ffff881022e7dc00 R08: ffff8810247f4000 R09: 0000000000000000
> [ 253.147220] R10: 0000000000005add R11: 0000000000005add R12: 0000000000000070
> [ 253.154422] R13: ffff881022d0b550 R14: ffff881022e7dc08 R15: 0000000000000000
> [ 253.161624] FS: 0000000000000000(0000) GS:ffff88107fc40000(0000) knlGS:0000000000000000
> [ 253.169794] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 253.175617] CR2: 0000000000000070 CR3: 0000000001610000 CR4: 00000000000407e0
> [ 253.182820] Stack:
> [ 253.184915] ffffffffa0492b06 ffff881022d0b4c0 ffff881022e7dc00 0000000000000000
> [ 253.192670] ffffffffa049b1b8 ffff881022e7de40 ffff88107fc52d40 ffff881000000001
> [ 253.200420] ffff8810247f7dc8 000000000018b400 000000000018b400 040004003f2fe910
> [ 253.208175] Call Trace:
> [ 253.210721] [<ffffffffa0492b06>] ? target_put_sess_cmd+0x5e/0x71 [target_core_mod]
> [ 253.218465] [<ffffffffa049b1b8>] ? target_xcopy_do_work+0x5a8/0x700 [target_core_mod]
> [ 253.226470] [<ffffffff81001656>] ? __switch_to+0x230/0x468
> [ 253.232132] [<ffffffff8104cd10>] ? process_one_work+0x191/0x293
> [ 253.238209] [<ffffffff8104d09a>] ? worker_thread+0x262/0x337
> [ 253.244024] [<ffffffff8104ce38>] ? process_scheduled_works+0x26/0x26
> [ 253.250534] [<ffffffff8104ce38>] ? process_scheduled_works+0x26/0x26
> [ 253.257059] [<ffffffff81051a76>] ? kthread+0x99/0xa1
> [ 253.262182] [<ffffffff810519dd>] ? __kthread_parkme+0x59/0x59
> [ 253.268090] [<ffffffff813a087c>] ? ret_from_fork+0x7c/0xb0
> [ 253.273734] [<ffffffff810519dd>] ? __kthread_parkme+0x59/0x59
> [ 253.279634] Code: 07 01 56 9d c3 53 9c 5b fa e8 70 e2 cc ff 48 89 d8 5b c3 f0 ff 07 56 9d c3 f0 81 07 00 00 10 00 56 9d c3 9c 58 fa ba 00 00 01 00 <f0> 0f c1 17 89 d1 c1 e9 10 66 39 d1 74 0c 66 8b 17 66 39 ca 74
> [ 253.303077] RIP [<ffffffff8139b6e9>] _raw_spin_lock_irqsave+0x8/0x23
> [ 253.309661] RSP <ffff8810247f7d20>
> [ 253.313214] CR2: 0000000000000070
> [ 253.316595] ---[ end trace ca88a23d16825853 ]---
Ugh. Mikulas' (Cc'ed) patch to fix the XCOPY memory leak is triggering
this, because the XCOPY passthrough commands aren't associated with a
se_session. :-(
I'm applying the following now + adding CC' to >= v3.12.y.
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index c9e8b35..f072f25 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2424,6 +2424,10 @@ static void target_release_cmd_kref(struct kref *kref)
*/
int target_put_sess_cmd(struct se_session *se_sess, struct se_cmd *se_cmd)
{
+ if (!se_sess) {
+ se_cmd->se_tfo->release_cmd(se_cmd);
+ return 0;
+ }
return kref_put_spinlock_irqsave(&se_cmd->cmd_kref, target_release_cmd_kref,
&se_sess->sess_cmd_lock);
}
> I used Linus TIP + the three patches. One thing, that I do not
> understand happened: When it crashed the first time 'targetcli' did not
> startup after a reboot at all. I also had forgot to save to /etc/target
> was empty with one exception: The backup folder. So I pulled the lasted
> tip from Torvalds and recompiled, rebooted and afterwards I could start
> targetcli. I can reproduce this. The reason targetcli did not start was
> because /sys/kernel/config/target did not exist. Ideas? The kernel
> modules was loaded. I'm using the userland from Debian wheezy should I
> update 'targetcli' userland with the most current version. In the past
> it did not give me any trouble whatsoever.
>
There haven't been any user-facing changes that would effect rtslib +
targetcli. I'm assuming it had something to do with the OOPs, but can
you please verify again with the above..?
Thanks for reporting Thomas.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
