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.

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.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Reply via email to