Re: [dm-devel] dm-mq and end_clone_request()

[Bart Van Assche]

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

[Sagi Grimberg]

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 = _cmd->tx_desc.send_wr;
struct iscsi_scsi_rsp *hdr = (struct iscsi_scsi_rsp *)
_cmd->tx_desc.iscsi_header;
+   int ret;

isert_create_send_desc(isert_conn, isert_cmd, _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(>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,
   _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 = _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(>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,
_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(>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?



[Query 2] An extra deref is done in case of 

[Bug 151631] "Synchronizing SCSI cache" fails during(and delays) reboot/shutdown

[bugzilla-daemon]

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

[bugzilla-daemon]

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)

[Tom Yan]

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

[Winkler, Tomas]

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