Re: [dm-devel] dm-mq and end_clone_request()
On 08/06/16 07:47, Laurence Oberman wrote: [66813.933246] Workqueue: srp_remove srp_remove_work [ib_srp] [ ... ] [66815.152051] [] scsi_forget_host+0x60/0x70 [66815.183939] [] scsi_remove_host+0x77/0x110 [66815.216152] [] srp_remove_work+0x90/0x200 [ib_srp] [66815.253221] [] process_one_work+0x152/0x400 [66815.286221] [] worker_thread+0x125/0x4b0 [66815.317313] [] ? rescuer_thread+0x380/0x380 [66815.349770] [] kthread+0xd8/0xf0 [66815.376082] [] ret_from_fork+0x1f/0x40 [66815.404767] [] ? kthread_park+0x60/0x60 Hello Laurence, This is a callstack I have not yet encountered myself during any test. Please provide the output of the following commands: $ gdb /lib/modules/$(uname -r)/build/vmlinux (gdb) list *(scsi_forget_host+0x60) Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IB/isert: Return value of iser target transport handlers ignored by iscsi target
Hi, Hi Baharat, In iSER target during iwarp connection tear-down due to ping timeouts, the rdma queues are set to error state and subsequent queued iscsi session commands posted shall fail with corresponding errno returned by ib_post_send/recv. At this stage iser target handlers (Ex: isert_put_datain()) return the error to iscsci target, but these errors are not being handled by the iscsi target handlers(Ex: lio_queue_status()). Indeed looks like lio_queue_data_in() assumes that ->iscsit_queue_data_in() cannot fail. This either mean that isert_put_data_in() should take care of the extra put in this case, or the iscsi should correctly handle a queue_full condition (because we should not be hitting this in the normal IO flow). Does this (untested) patch help? -- diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c index a990c04208c9..ff5dfc0f7c50 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -1810,6 +1810,7 @@ isert_put_response(struct iscsi_conn *conn, struct iscsi_cmd *cmd) struct ib_send_wr *send_wr = &isert_cmd->tx_desc.send_wr; struct iscsi_scsi_rsp *hdr = (struct iscsi_scsi_rsp *) &isert_cmd->tx_desc.iscsi_header; + int ret; isert_create_send_desc(isert_conn, isert_cmd, &isert_cmd->tx_desc); iscsit_build_rsp_pdu(cmd, conn, true, hdr); @@ -1848,7 +1849,10 @@ isert_put_response(struct iscsi_conn *conn, struct iscsi_cmd *cmd) isert_dbg("Posting SCSI Response\n"); - return isert_post_response(isert_conn, isert_cmd); + ret = isert_post_response(isert_conn, isert_cmd); + if (ret) + target_put_sess_cmd(&cmd->se_cmd); + return 0; } static void @@ -2128,7 +2132,7 @@ isert_put_datain(struct iscsi_conn *conn, struct iscsi_cmd *cmd) struct isert_conn *isert_conn = conn->context; struct ib_cqe *cqe = NULL; struct ib_send_wr *chain_wr = NULL; - int rc; + int ret; isert_dbg("Cmd: %p RDMA_WRITE data_length: %u\n", isert_cmd, se_cmd->data_length); @@ -2148,34 +2152,41 @@ isert_put_datain(struct iscsi_conn *conn, struct iscsi_cmd *cmd) isert_init_send_wr(isert_conn, isert_cmd, &isert_cmd->tx_desc.send_wr); - rc = isert_post_recv(isert_conn, isert_cmd->rx_desc); - if (rc) { - isert_err("ib_post_recv failed with %d\n", rc); - return rc; + ret = isert_post_recv(isert_conn, isert_cmd->rx_desc); + if (ret) { + isert_err("ib_post_recv failed with %d\n", ret); + goto out; } chain_wr = &isert_cmd->tx_desc.send_wr; } - isert_rdma_rw_ctx_post(isert_cmd, isert_conn, cqe, chain_wr); + ret = isert_rdma_rw_ctx_post(isert_cmd, isert_conn, cqe, chain_wr); isert_dbg("Cmd: %p posted RDMA_WRITE for iSER Data READ\n", isert_cmd); - return 1; +out: + if (ret) + target_put_sess_cmd(&cmd->se_cmd); + return 0; } static int isert_get_dataout(struct iscsi_conn *conn, struct iscsi_cmd *cmd, bool recovery) { struct isert_cmd *isert_cmd = iscsit_priv_cmd(cmd); + int ret; isert_dbg("Cmd: %p RDMA_READ data_length: %u write_data_done: %u\n", isert_cmd, cmd->se_cmd.data_length, cmd->write_data_done); isert_cmd->tx_desc.tx_cqe.done = isert_rdma_read_done; - isert_rdma_rw_ctx_post(isert_cmd, conn->context, + ret = isert_rdma_rw_ctx_post(isert_cmd, conn->context, &isert_cmd->tx_desc.tx_cqe, NULL); isert_dbg("Cmd: %p posted RDMA_READ memory for ISER Data WRITE\n", isert_cmd);+out: + if (ret) + target_put_sess_cmd(&cmd->se_cmd); return 0; } -- -> While closing the session in case of ping timeouts, isert_close_connection()-> isert_wait_conn()->isert_wait4cmds() checks for the queued session commands and waits infinitely for command completion 'cmd_wait_comp' in target_wait_for_sess_cmds(). 'cmd_wait_comp' will be never complete as the kref on the session command is not derefed, due to which target_release_cmd_kref() is not called by kref_put(). Due to this, the older session is not cleared causing the next login negotiation to fail as the older session is still active(Older SID exists). Makes sense... [Query 1] If the return value of ib_post_send/recv() are handled to deref the corresponding queued session commands, the wait on cmd_wait_comp will be complete and clears off the session successfully. Is this the rightway to do it here? I think that given that ->iscsit_queue_data_in() and ->iscsit_queue_status() are never expected to fail we probably should take care of it in isert... Nic, any input on the iscsit side?
[Bug 151631] "Synchronizing SCSI cache" fails during(and delays) reboot/shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=151631 icanrealizeum changed: What|Removed |Added Kernel Version|<=4.7.0-g0cbbc42|<=4.7.0-g0cbbc42 ||4.7.0-g52ddb7e -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 151631] "Synchronizing SCSI cache" fails during(and delays) reboot/shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=151631 icanrealizeum changed: What|Removed |Added Regression|No |Yes --- Comment #4 from icanrealizeum --- I have worked around this issue(for me) by adding a few lines in debug.sh like: if test "$1" == "poweroff"; then hdparm -Y /dev/sda echo o > /proc/sysrq-trigger ; sleep 5 fi that puts drive to sleep and triggers shutdown via sysrq Seems to have worked just fine: no drive issues on startup anymore, as I've mentioned before with having to ctrl+alt+del once to get BIOS to detect drive; and no extra delays. Also the above require a kernel patch: //sd_start_stop_device(sdkp, 0); commenting out that call in sd_shutdown function in file: drivers/scsi/sd.c or else it will fail like in comment #3 -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)
So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560 (commit d2be537c3ba3) seemed to have caused trouble to some of the ATA devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024. However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not the "real" cause of the trouble, but the fact that AHCI_MAX_SG has been set to a weird value of 168 (with a comment "hardware max is 64K", which neither seem to make any sense). AHCI_MAX_SG is used to set the sg_tablesize (i.e. max_segments, apparently), which is apparently used to derive the actual "request size" (that is, if it is lower than max_sectors(_kb), it will be the limiting factor instead). For example, no matter if the drive has max_sectors set to 2560, or to 65535 (by adding it as the Optimal Transfer Length to libata's SATL, which is also max_hw_sectors that is set from ATA_MAX_SECTORS_LBA48), "avgrq-sz" in `iostat` will be capped at 1344 (168 * 8). However, if I change AHCI_MAX_SG to 128 (which is also the sg_tablesize set in libata.h from LIBATA_MAX_PRD), "avgrq-sz" in `iostat` will be capped at 1024 (128 * 8), which should make ATA_HORKAGE_MAX_SEC_1024 unnecessary. So why has AHCI_MAX_SG been set to 168 anyway? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 4/8] char: rpmb: provide a user space interface
> > On Mon 2016-07-18 23:27:49, Tomas Winkler wrote: > > The user space API is achieved via two synchronous IOCTL. > > IOCTLs? Will fix > > Simplified one, RPMB_IOC_REQ_CMD, were read result cycles is > performed > > by the framework on behalf the user and second, RPMB_IOC_SEQ_CMD > where > > the whole RPMB sequence including RESULT_READ is supplied by the caller. > > The latter is intended for easier adjusting of the applications > > that use MMC_IOC_MULTI_CMD ioctl. > > Why " "? Not sure I there is enough clue in your question. > > > > > Signed-off-by: Tomas Winkler > > > + > > +static long rpmb_ioctl(struct file *fp, unsigned int cmd, unsigned > > +long arg) { > > + return __rpmb_ioctl(fp, cmd, (void __user *)arg); } > > + > > +#ifdef CONFIG_COMPAT > > +static long rpmb_compat_ioctl(struct file *fp, unsigned int cmd, > > + unsigned long arg) > > +{ > > + return __rpmb_ioctl(fp, cmd, compat_ptr(arg)); > > +} > > +#endif /* CONFIG_COMPAT */ > > Description of the ioctl is missing, Will add. and it should certainly be designed in a way > that it does not need compat support. The compat_ioctl handler just casts the compat_ptr, I believe this should be done unless the ioctl is globaly registered in fs/compat_ioctl.c, but I might be wrong. Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html