On 01/07/2011 01:37 AM, Max Matveev wrote:

I'm working with a customer who's getting the famous "scheduling while
atomic" noise in the logs when using his tape library connected via
iSCSI. The task is always an iscsi_q_31 and they're getting a lot of
those BUG messages.

I have the backtrace but it's almost useless - the code path is
unbelievable: the only reliable bit is

Send it. There might be something useful.


  [<f8acca0e>] iscsi_tcp_segment_done+0x1c7/0x2a7 [libiscsi_tcp]
  [<c05b7f45>] kernel_sendmsg+0x27/0x35
  [<f8ad33e8>] iscsi_sw_tcp_pdu_xmit+0x9e/0x1e8 [iscsi_tcp]
  [<f8acc246>] iscsi_tcp_task_xmit+0x25/0x204 [libiscsi_tcp]
  [<f8d9b622>] iscsi_xmit_task+0x24/0x4b [libiscsi2]
  [<f8d9c190>] iscsi_xmitworker+0x122/0x202 [libiscsi2]

Upstream, it should be ok to sleep in the *xmit code path when using iscsi_tcp. We send from a thread and are not holding a lock when actually sending.

We cannot sleep on the completion path though (*_segment_done path) because that is run in softirq context.


He's running RHEL 5.5 i686 kernel - sorry, I cannot tell the version
of open-iscsi bits in this kernel.

Just uname -a the kernel. I can map it to the version. I think it should be close to upstream though.


After some digging into the code I'm starting to wonder if kmap_atomic
is the right thing to do when dealing with tcp: tcp_sendmsg() can
legitemately sleep on full socket buffer or when trying to allocate an

Ack on the sleeping waiting for write space. But, for skb allocation isn't the sock->sk_allocation used always or what paths is it not used?

skb which sort of violates the assumption that kmap_atomic is uses for
"tight code paths".


The recv path calls iscsi_tcp_segment_done->iscsi_tcp_segment_map->kmap so we cannot use kmap, because it is run from the net softirw. We must use the atomic version. In the xmit path we could change it to use the kmap call instead though.



max

PS. Should www.open-iscsi.org display Apache test page?


No. I do not see that. Maybe the problem is now fixed.

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

Reply via email to