Re: LIO and the libiscsi regression tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2015-02-13 at 11:58 +0100, Bart Van Assche wrote:
> Hello Nic,
> 
> As you know I'm working on a prototype of a unified SRP target
> driver. Since that work involves some small target core changes
> I started to look for a good regression test for the LIO core.
> That is why I ran the libiscsi test suite against LIO. The test
> I ran was as follows:
> * Installed kernel v3.18.6 inside a virtual machine.
> * Installed the libcunit1-dev package.
> * Cloned libiscsi from https://github.com/sahlberg/libiscsi.git.
> * Built libiscsi.
> * Ran the attached script to start LIO.
> * Started the libiscsi regression tests as follows:
>   test-tool/iscsi-test-cu --dataloss --allow-sanitize iscsi://127.0.0.1/tgt1/0
> 
> The result can be found below. This is 100% reproducible. Can you have a look at this ?
> 
> Thanks,
> 
> Bart.
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000014
> IP: [<ffffffffa038522e>] fd_execute_write_same+0x6e/0x310 [target_core_file]
> PGD 58fe7067 PUD 54bca067 PMD 0 
> Oops: 0000 [#1] SMP 
> Modules linked in: target_core_pscsi target_core_iblock target_core_file iscsi_target_mod target_core_mod crc32c_generic iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi netconsole configfs af_packet hid_generic qxl drm_kms_helper usbhid processor ttm microcode thermal_sys hid drm virtio_balloon hwmon intel_agp button i2c_piix4 intel_gtt agpgart i2c_core fuse sg sr_mod cdrom ata_generic ext4 pata_acpi crc16 jbd2 mbcache virtio_blk virtio_net virtio_pci virtio_ring ata_piix virtio uhci_hcd libata usbcore usb_common scsi_mod [last unloaded: target_core_mod]
> CPU: 3 PID: 2431 Comm: iscsi_trx Not tainted 3.18.6+ #1
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> task: ffff88005d21b630 ti: ffff880058700000 task.ti: ffff880058700000
> RIP: 0010:[<ffffffffa038522e>]  [<ffffffffa038522e>] fd_execute_write_same+0x6e/0x310 [target_core_file]
> RSP: 0018:ffff880058703b68  EFLAGS: 00010297
> RAX: 0000000000000001 RBX: ffff880058f5c290 RCX: 0000000000000200
> RDX: ffff880058f5c290 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffff880058703bd8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880056ef8ce8
> R13: ffff880058f5c290 R14: 0000000000000286 R15: ffff880056ef8b98
> FS:  0000000000000000(0000) GS:ffff88005fd80000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000014 CR3: 0000000054b8c000 CR4: 00000000000006e0
> Stack:
>  ffff88005d21b630 ffff880033dbc300 0000000000000006 ffff880056ef8b98
>  0000000000000000 ffffffff8109c195 ffffffff814ce380 0000000040000200
>  ffff880058f5c290 ffff880056ef8b98 ffff880056ef8ce8 ffff880058f5c290
> Call Trace:
>  [<ffffffff8109c195>] ? mark_held_locks+0x75/0xa0
>  [<ffffffff814ce380>] ? _raw_spin_unlock_irq+0x30/0x40
>  [<ffffffffa03af513>] __target_execute_cmd+0x23/0x70 [target_core_mod]
>  [<ffffffffa03b0888>] target_execute_cmd+0x168/0x240 [target_core_mod]
>  [<ffffffffa03b0bff>] transport_generic_new_cmd+0x10f/0x1e0 [target_core_mod]
>  [<ffffffffa03b0d0b>] transport_handle_cdb_direct+0x3b/0x90 [target_core_mod]
>  [<ffffffffa03427f4>] iscsit_execute_cmd+0x254/0x2a0 [iscsi_target_mod]
>  [<ffffffffa034bc90>] iscsit_sequence_cmd+0xc0/0x1b0 [iscsi_target_mod]
>  [<ffffffffa034e438>] iscsit_process_scsi_cmd+0x88/0x110 [iscsi_target_mod]
>  [<ffffffffa0352447>] iscsi_target_rx_thread+0x337/0xf30 [iscsi_target_mod]
>  [<ffffffff810f4da8>] ? kprobe_flush_task+0x88/0x110
>  [<ffffffffa0352110>] ? iscsi_target_tx_thread+0x210/0x210 [iscsi_target_mod]
>  [<ffffffff81076f86>] kthread+0xf6/0x110
>  [<ffffffff814ce380>] ? _raw_spin_unlock_irq+0x30/0x40
>  [<ffffffff81076e90>] ? kthread_create_on_node+0x220/0x220
>  [<ffffffff814ced6c>] ret_from_fork+0x7c/0xb0
>  [<ffffffff81076e90>] ? kthread_create_on_node+0x220/0x220
> Code: 55 c8 0f 84 05 02 00 00 49 8b b7 18 02 00 00 48 89 75 b0 41 8b b7 28 02 00 00 83 fe 01 0f 87 14 02 00 00 48 8b 7d b0 49 8b 57 68 <44> 8b 6f 14 44 3b aa cc 06 00 00 0f 85 07 02 00 00 0f af c8 41 
> RIP  [<ffffffffa038522e>] fd_execute_write_same+0x6e/0x310 [target_core_file]
>  RSP <ffff880058703b68>
> CR2: 0000000000000014
> ---[ end trace ab3633b8c3273797 ]---

So after running against what's in target-pending/for-next (v3.19-rc1+)
using your script for initial setup, I'm currently not able to trigger
this bug with iscsi-test-cu.

AFAICT there haven't been any changes in fd_execute_write_same() between
v3.18 up until now.

Which specific WRITE_SAME test is triggering it on your side..?

Also, I assume you've tried using stock v3.18.6 without your
modifications, right..?

--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




[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux