iscsi session recovery work

[Vivek S]

Hi,

iscsi session recovery work is queued by function __iscsi_block_session which is in turn called by iscsi_block_session.

This is the function call sequence i figured out (using sw iscsi over tcp/ip)

iscsi_if_recv_msg (ISCSI_UEVENT_STOP_CONN) -> iscsi_sw_tcp_conn_stop -> iscsi_conn_stop -> iscsi_start_session_recovery -> iscsi_block_session

This means that the session recovery work is initiated by the user space. What events propageted to user space causes it to initiate this recovery ? A function call sequence would greatly help.

Thank you

[Mike Christie]

I think it was just userspace controlled recovery, so if we ended doing
other ERLs then iscsid might decided to do something else and that
smarts was going to be all in userspace.

Also, we have to sleep in that iscsi_start_session_recovery path so we
cannot always call it directly from the code path that we discovery the
problem from. A lot of times we could be in soft irq context (timer,
network soft irq, bottom half for other drivers).

iscsi_block_session is actually called directly from the kernel for
qla4xxx in some cases. It is called from isr context in some places.
This is why it is queued to a thread.

[Vivek S]

On Sat, Sep 24, 2011 at 3:18 AM, Mike Christie <mich...@cs.wisc.edu> wrote:

On 09/23/2011 02:43 AM, Vivek S wrote:
> Hi,
>
> iscsi session recovery work is queued by function __iscsi_block_session
> which is in turn called by iscsi_block_session.
>
> This is the function call sequence i figured out (using sw iscsi over
> tcp/ip)
>
> iscsi_if_recv_msg (ISCSI_UEVENT_STOP_CONN) -> iscsi_sw_tcp_conn_stop ->
> iscsi_conn_stop -> iscsi_start_session_recovery -> iscsi_block_session
>
> This means that the session recovery work is initiated by the user space.
> What events propageted to user space causes it to initiate this recovery ? A
> function call sequence would greatly help.
>

I think it was just userspace controlled recovery, so if we ended doing
other ERLs then iscsid might decided to do something else and that
smarts was going to be all in userspace.

What is ERL ?
 

Also, we have to sleep in that iscsi_start_session_recovery path so we
cannot always call it directly from the code path that we discovery the
problem from. A lot of times we could be in soft irq context (timer,
network soft irq, bottom half for other drivers).

Why do we have sleep in iscsi_start_session_recovery ?
 

iscsi_block_session is actually called directly from the kernel for
qla4xxx in some cases. It is called from isr context in some places.
This is why it is queued to a thread.

Its (recovery work) queued to a thread because the kernel or the isr cannot wait till the recovery work is completed. Is this correct ?