On 02/13/15 23:07, Nicholas A. Bellinger wrote: > On Fri, 2015-02-13 at 12:07 -0800, Nicholas A. Bellinger wrote: >> 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..? >> > > Still not able to reproduce this particular OOPsen, but did notice that > WRITE_SAME emulation is not checking for LBAs past the end of the > device. Could be related to what your seeing above.. > > Sending out a patch to address this shortly. Hello Nic, This happened with an unmodified 3.18.6 kernel. The "+" sign behind the kernel version was there because I had added the kernel .config file to the git tree. If I interpret the disassembler output correctly the above crash report means that fd_execute_write_same() was called for a command for which t_data_sg was NULL. Bart. -- 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
