Re: [PATCHv5 00/36] asynchronous ALUA device handler

[Hannes Reinecke <hare@suse.de>]

On 09/30/2015 11:32 PM, Bart Van Assche wrote:
> On 09/30/2015 06:21 AM, Hannes Reinecke wrote:
>> On 09/29/2015 08:29 PM, Bart Van Assche wrote:
>>> On 09/29/2015 03:47 AM, Hannes Reinecke wrote:
>>>> here the next round of my update to the ALUA device handler.
>>>
>>> Sorry but this with this version I see an initiator kernel lockup
>>> shortly after the initiator system had been booted. I have attached
>>> the output of echo t > /proc/sysrq-trigger to this e-mail.
>>>
>> Hmm. Weird.
>> Everything seems to wait for alua_rtpg() to complete: [ ... ]
> 
> Hello Hannes,
> 
> Would it be possible to add the patch to your tree that causes
> scsi_dh_alua to be loaded automatically again
> (http://thread.gmane.org/gmane.linux.scsi/105276) ? I might have
> forgotten to load the scsi_dh_alua driver manually before I ran
> my test ...
> 
> However, even with the scsi_dh_alua driver loaded a kernel lockup is
> reported. Please note that I do not know whether or not that lockup is
> related to this patch series or to the changes in v4.3-rc1:
> 
> INFO: task srp_daemon:600 blocked for more than 120 seconds.
>       Not tainted 4.3.0-rc1-debug+ #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> srp_daemon      D ffff88045c6a2d00     0   600    593 0x00000000
>  ffff88043060b960 0000000000000092 ffffffff810ba0bd ffff88047fc95ad8
>  ffff88045c6a2d00 ffff880430559680 ffff88043060c000 ffff8804181061c8
>  ffff88041dbd3cf8 ffff8804181055e8 ffff880418104ad0 ffff88043060b978
> Call Trace:
>  [<ffffffff810ba0bd>] ? trace_hardirqs_on+0xd/0x10
>  [<ffffffff814efcda>] schedule+0x3a/0x90
>  [<ffffffff81271a46>] blk_mq_freeze_queue_wait+0x56/0xb0
>  [<ffffffff810b45c0>] ? prepare_to_wait_event+0xf0/0xf0
>  [<ffffffff81273a61>] blk_mq_update_tag_set_depth+0x41/0xb0
>  [<ffffffff81274294>] blk_mq_init_allocated_queue+0x7c4/0x860
>  [<ffffffff8127436a>] blk_mq_init_queue+0x3a/0x60
>  [<ffffffffa0016a6c>] scsi_mq_alloc_queue+0x1c/0x50 [scsi_mod]
>  [<ffffffffa0017c51>] scsi_alloc_sdev+0x331/0x3b0 [scsi_mod]
>  [<ffffffffa0018554>] scsi_probe_and_add_lun+0x884/0xd20 [scsi_mod]
>  [<ffffffffa00191cb>] __scsi_scan_target+0x52b/0x5f0 [scsi_mod]
>  [<ffffffff8139198c>] ? __pm_runtime_resume+0x5c/0x80
>  [<ffffffffa001936c>] scsi_scan_target+0xdc/0x100 [scsi_mod]
>  [<ffffffffa04374ae>] srp_create_target+0xfde/0x1410 [ib_srp]
>  [<ffffffff810b8201>] ? match_held_lock+0x1c1/0x200
>  [<ffffffff81381b68>] dev_attr_store+0x18/0x30
>  [<ffffffff812300f4>] sysfs_kf_write+0x44/0x60
>  [<ffffffff8122f724>] kernfs_fop_write+0x144/0x190
>  [<ffffffff811b8788>] __vfs_write+0x28/0xe0
>  [<ffffffff810b6a4a>] ? percpu_down_read+0x5a/0x90
>  [<ffffffff811bba70>] ? __sb_start_write+0xe0/0x100
>  [<ffffffff811bba70>] ? __sb_start_write+0xe0/0x100
>  [<ffffffff811d7455>] ? __fget+0x5/0x210
>  [<ffffffff811b8e19>] vfs_write+0xa9/0x190
>  [<ffffffff811b9b19>] SyS_write+0x49/0xa0
>  [<ffffffff814f57b6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> 7 locks held by srp_daemon/600:
>  #0:  (&f->f_pos_lock){+.+.+.}, at: [<ffffffff811d84b3>] __fdget_pos+0x43/0x50
>  #1:  (sb_writers#3){.+.+.+}, at: [<ffffffff811bba70>] __sb_start_write+0xe0/0x100
>  #2:  (&of->mutex){+.+.+.}, at: [<ffffffff8122f646>] kernfs_fop_write+0x66/0x190
>  #3:  (s_active#142){.+.+.+}, at: [<ffffffff8122f64e>] kernfs_fop_write+0x6e/0x190
>  #4:  (&host->add_target_mutex){+.+.+.}, at: [<ffffffffa043660b>] srp_create_target+0x13b/0x1410 [ib_srp]
>  #5:  (&shost->scan_mutex){+.+.+.}, at: [<ffffffffa0019317>] scsi_scan_target+0x87/0x100 [scsi_mod]
>  #6:  (&set->tag_list_lock){+.+...}, at: [<ffffffff81274272>] blk_mq_init_allocated_queue+0x7a2/0x860
> 
I have rebased my patches to 4.3.0-rc5 and didn't see any lockups;
tested with hpsa and lpfc, both mq enabled and disabled.

Can you check if it's specific to ib_srp? Is there a way to simulate
an ib_srp setup?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html