<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/target, branch v3.2.36</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>target/tcm_fc: fix the lockdep warning due to inconsistent lock state</title>
<updated>2013-01-03T03:33:38+00:00</updated>
<author>
<name>Yi Zou</name>
<email>yi.zou@intel.com</email>
</author>
<published>2012-12-11T01:04:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=14f1aeda0684a4c0286065bd1a3a05906825ed32'/>
<id>14f1aeda0684a4c0286065bd1a3a05906825ed32</id>
<content type='text'>
commit 9f4ad44b264f8bb61ffdd607148215566568430d upstream.

The lockdep warning below is in theory correct but it will be in really weird
rare situation that ends up that deadlock since the tcm fc session is hashed
based the rport id. Nonetheless, the complaining below is about rcu callback
that does the transport_deregister_session() is happening in softirq, where
transport_register_session() that happens earlier is not. This triggers the
lockdep warning below. So, just fix this to make lockdep happy by disabling
the soft irq before calling transport_register_session() in ft_prli.

BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy
would get this triggered.

v1: was enforcing register to be in softirq context which was not righ. See,
http://www.spinics.net/lists/target-devel/msg03614.html

v2: following comments from Roland&amp;Nick (thanks), it seems we don't have to
do transport_deregister_session() in rcu callback, so move it into ft_sess_free()
but still do kfree() of the corresponding ft_sess struct in rcu callback to
make sure the ft_sess is not freed till the rcu callback.

...
[ 1328.370592] scsi2 : FCoE Driver
[ 1328.383429] fcoe: No FDMI support.
[ 1328.384509] host2: libfc: Link up on port (000000)
[ 1328.934229] host2: Assigned Port ID 00a292
[ 1357.232132] host2: rport 00a393: Remove port
[ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state
[ 1357.233692] host2: rport 00a393: Delete port
[ 1357.234472] host2: rport 00a393: work event 3
[ 1357.234969] host2: rport 00a393: callback ev 3
[ 1357.235979] host2: rport 00a393: Received a LOGO response closed
[ 1357.236706] host2: rport 00a393: work delete
[ 1357.237481]
[ 1357.237631] =================================
[ 1357.238064] [ INFO: inconsistent lock state ]
[ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G           O
[ 1357.238450] ---------------------------------
[ 1357.238450] inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.
[ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 1357.238450]  (&amp;(&amp;se_tpg-&gt;session_lock)-&gt;rlock){+.?...}, at: [&lt;ffffffffa01eacd4&gt;] transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] {SOFTIRQ-ON-W} state was registered at:
[ 1357.238450]   [&lt;ffffffff810834f5&gt;] mark_held_locks+0x6d/0x95
[ 1357.238450]   [&lt;ffffffff8108364a&gt;] trace_hardirqs_on_caller+0x12d/0x197
[ 1357.238450]   [&lt;ffffffff810836c1&gt;] trace_hardirqs_on+0xd/0xf
[ 1357.238450]   [&lt;ffffffff8149caba&gt;] _raw_spin_unlock_irq+0x2d/0x45
[ 1357.238450]   [&lt;ffffffffa01e8d10&gt;] __transport_register_session+0xb8/0x122 [target_core_mod]
[ 1357.238450]   [&lt;ffffffffa01e8dbe&gt;] transport_register_session+0x44/0x5a [target_core_mod]
[ 1357.238450]   [&lt;ffffffffa018e32c&gt;] ft_prli+0x1e3/0x275 [tcm_fc]
[ 1357.238450]   [&lt;ffffffffa0160e8d&gt;] fc_rport_recv_req+0x95e/0xdc5 [libfc]
[ 1357.238450]   [&lt;ffffffffa015be88&gt;] fc_lport_recv_els_req+0xc4/0xd5 [libfc]
[ 1357.238450]   [&lt;ffffffffa015c778&gt;] fc_lport_recv_req+0x12f/0x18f [libfc]
[ 1357.238450]   [&lt;ffffffffa015a6d7&gt;] fc_exch_recv+0x8ba/0x981 [libfc]
[ 1357.238450]   [&lt;ffffffffa0176d7a&gt;] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe]
[ 1357.238450]   [&lt;ffffffff810549f1&gt;] kthread+0xb1/0xb9
[ 1357.238450]   [&lt;ffffffff814a40ec&gt;] ret_from_fork+0x7c/0xb0
[ 1357.238450] irq event stamp: 275411
[ 1357.238450] hardirqs last  enabled at (275410): [&lt;ffffffff810bb6a0&gt;] rcu_process_callbacks+0x229/0x42a
[ 1357.238450] hardirqs last disabled at (275411): [&lt;ffffffff8149c2f7&gt;] _raw_spin_lock_irqsave+0x22/0x8e
[ 1357.238450] softirqs last  enabled at (275394): [&lt;ffffffff8103d669&gt;] __do_softirq+0x246/0x26f
[ 1357.238450] softirqs last disabled at (275399): [&lt;ffffffff8103d6bb&gt;] run_ksoftirqd+0x29/0x62
[ 1357.238450]
[ 1357.238450] other info that might help us debug this:
[ 1357.238450]  Possible unsafe locking scenario:
[ 1357.238450]
[ 1357.238450]        CPU0
[ 1357.238450]        ----
[ 1357.238450]   lock(&amp;(&amp;se_tpg-&gt;session_lock)-&gt;rlock);
[ 1357.238450]   &lt;Interrupt&gt;
[ 1357.238450]     lock(&amp;(&amp;se_tpg-&gt;session_lock)-&gt;rlock);
[ 1357.238450]
[ 1357.238450]  *** DEADLOCK ***
[ 1357.238450]
[ 1357.238450] no locks held by ksoftirqd/0/3.
[ 1357.238450]
[ 1357.238450] stack backtrace:
[ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G           O 3.7.0-rc7-yikvm+ #3
[ 1357.238450] Call Trace:
[ 1357.238450]  [&lt;ffffffff8149399a&gt;] print_usage_bug+0x1f5/0x206
[ 1357.238450]  [&lt;ffffffff8100da59&gt;] ? save_stack_trace+0x2c/0x49
[ 1357.238450]  [&lt;ffffffff81082aae&gt;] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae
[ 1357.238450]  [&lt;ffffffff81083336&gt;] mark_lock+0x106/0x258
[ 1357.238450]  [&lt;ffffffff81084e34&gt;] __lock_acquire+0x2e7/0xe53
[ 1357.238450]  [&lt;ffffffff8102903d&gt;] ? pvclock_clocksource_read+0x48/0xb4
[ 1357.238450]  [&lt;ffffffff810ba6a3&gt;] ? rcu_process_gp_end+0xc0/0xc9
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffff81085ef1&gt;] lock_acquire+0x119/0x143
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffff8149c329&gt;] _raw_spin_lock_irqsave+0x54/0x8e
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffff810bb6a0&gt;] ? rcu_process_callbacks+0x229/0x42a
[ 1357.238450]  [&lt;ffffffffa018ddc5&gt;] ft_sess_rcu_free+0x17/0x24 [tcm_fc]
[ 1357.238450]  [&lt;ffffffffa018ddae&gt;] ? ft_sess_free+0x1b/0x1b [tcm_fc]
[ 1357.238450]  [&lt;ffffffff810bb6d7&gt;] rcu_process_callbacks+0x260/0x42a
[ 1357.238450]  [&lt;ffffffff8103d55d&gt;] __do_softirq+0x13a/0x26f
[ 1357.238450]  [&lt;ffffffff8149b34e&gt;] ? __schedule+0x65f/0x68e
[ 1357.238450]  [&lt;ffffffff8103d6bb&gt;] run_ksoftirqd+0x29/0x62
[ 1357.238450]  [&lt;ffffffff8105c83c&gt;] smpboot_thread_fn+0x1a5/0x1aa
[ 1357.238450]  [&lt;ffffffff8105c697&gt;] ? smpboot_unregister_percpu_thread+0x47/0x47
[ 1357.238450]  [&lt;ffffffff810549f1&gt;] kthread+0xb1/0xb9
[ 1357.238450]  [&lt;ffffffff8149b49d&gt;] ? wait_for_common+0xbb/0x10a
[ 1357.238450]  [&lt;ffffffff81054940&gt;] ? __init_kthread_worker+0x59/0x59
[ 1357.238450]  [&lt;ffffffff814a40ec&gt;] ret_from_fork+0x7c/0xb0
[ 1357.238450]  [&lt;ffffffff81054940&gt;] ? __init_kthread_worker+0x59/0x59
[ 1417.440099]  rport-2:0-0: blocked FC remote port time out: removing rport

Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Cc: Open-FCoE &lt;devel@open-fcoe.org&gt;
Cc: Nicholas A. Bellinger &lt;nab@risingtidesystems.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9f4ad44b264f8bb61ffdd607148215566568430d upstream.

The lockdep warning below is in theory correct but it will be in really weird
rare situation that ends up that deadlock since the tcm fc session is hashed
based the rport id. Nonetheless, the complaining below is about rcu callback
that does the transport_deregister_session() is happening in softirq, where
transport_register_session() that happens earlier is not. This triggers the
lockdep warning below. So, just fix this to make lockdep happy by disabling
the soft irq before calling transport_register_session() in ft_prli.

BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy
would get this triggered.

v1: was enforcing register to be in softirq context which was not righ. See,
http://www.spinics.net/lists/target-devel/msg03614.html

v2: following comments from Roland&amp;Nick (thanks), it seems we don't have to
do transport_deregister_session() in rcu callback, so move it into ft_sess_free()
but still do kfree() of the corresponding ft_sess struct in rcu callback to
make sure the ft_sess is not freed till the rcu callback.

...
[ 1328.370592] scsi2 : FCoE Driver
[ 1328.383429] fcoe: No FDMI support.
[ 1328.384509] host2: libfc: Link up on port (000000)
[ 1328.934229] host2: Assigned Port ID 00a292
[ 1357.232132] host2: rport 00a393: Remove port
[ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state
[ 1357.233692] host2: rport 00a393: Delete port
[ 1357.234472] host2: rport 00a393: work event 3
[ 1357.234969] host2: rport 00a393: callback ev 3
[ 1357.235979] host2: rport 00a393: Received a LOGO response closed
[ 1357.236706] host2: rport 00a393: work delete
[ 1357.237481]
[ 1357.237631] =================================
[ 1357.238064] [ INFO: inconsistent lock state ]
[ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G           O
[ 1357.238450] ---------------------------------
[ 1357.238450] inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.
[ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 1357.238450]  (&amp;(&amp;se_tpg-&gt;session_lock)-&gt;rlock){+.?...}, at: [&lt;ffffffffa01eacd4&gt;] transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] {SOFTIRQ-ON-W} state was registered at:
[ 1357.238450]   [&lt;ffffffff810834f5&gt;] mark_held_locks+0x6d/0x95
[ 1357.238450]   [&lt;ffffffff8108364a&gt;] trace_hardirqs_on_caller+0x12d/0x197
[ 1357.238450]   [&lt;ffffffff810836c1&gt;] trace_hardirqs_on+0xd/0xf
[ 1357.238450]   [&lt;ffffffff8149caba&gt;] _raw_spin_unlock_irq+0x2d/0x45
[ 1357.238450]   [&lt;ffffffffa01e8d10&gt;] __transport_register_session+0xb8/0x122 [target_core_mod]
[ 1357.238450]   [&lt;ffffffffa01e8dbe&gt;] transport_register_session+0x44/0x5a [target_core_mod]
[ 1357.238450]   [&lt;ffffffffa018e32c&gt;] ft_prli+0x1e3/0x275 [tcm_fc]
[ 1357.238450]   [&lt;ffffffffa0160e8d&gt;] fc_rport_recv_req+0x95e/0xdc5 [libfc]
[ 1357.238450]   [&lt;ffffffffa015be88&gt;] fc_lport_recv_els_req+0xc4/0xd5 [libfc]
[ 1357.238450]   [&lt;ffffffffa015c778&gt;] fc_lport_recv_req+0x12f/0x18f [libfc]
[ 1357.238450]   [&lt;ffffffffa015a6d7&gt;] fc_exch_recv+0x8ba/0x981 [libfc]
[ 1357.238450]   [&lt;ffffffffa0176d7a&gt;] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe]
[ 1357.238450]   [&lt;ffffffff810549f1&gt;] kthread+0xb1/0xb9
[ 1357.238450]   [&lt;ffffffff814a40ec&gt;] ret_from_fork+0x7c/0xb0
[ 1357.238450] irq event stamp: 275411
[ 1357.238450] hardirqs last  enabled at (275410): [&lt;ffffffff810bb6a0&gt;] rcu_process_callbacks+0x229/0x42a
[ 1357.238450] hardirqs last disabled at (275411): [&lt;ffffffff8149c2f7&gt;] _raw_spin_lock_irqsave+0x22/0x8e
[ 1357.238450] softirqs last  enabled at (275394): [&lt;ffffffff8103d669&gt;] __do_softirq+0x246/0x26f
[ 1357.238450] softirqs last disabled at (275399): [&lt;ffffffff8103d6bb&gt;] run_ksoftirqd+0x29/0x62
[ 1357.238450]
[ 1357.238450] other info that might help us debug this:
[ 1357.238450]  Possible unsafe locking scenario:
[ 1357.238450]
[ 1357.238450]        CPU0
[ 1357.238450]        ----
[ 1357.238450]   lock(&amp;(&amp;se_tpg-&gt;session_lock)-&gt;rlock);
[ 1357.238450]   &lt;Interrupt&gt;
[ 1357.238450]     lock(&amp;(&amp;se_tpg-&gt;session_lock)-&gt;rlock);
[ 1357.238450]
[ 1357.238450]  *** DEADLOCK ***
[ 1357.238450]
[ 1357.238450] no locks held by ksoftirqd/0/3.
[ 1357.238450]
[ 1357.238450] stack backtrace:
[ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G           O 3.7.0-rc7-yikvm+ #3
[ 1357.238450] Call Trace:
[ 1357.238450]  [&lt;ffffffff8149399a&gt;] print_usage_bug+0x1f5/0x206
[ 1357.238450]  [&lt;ffffffff8100da59&gt;] ? save_stack_trace+0x2c/0x49
[ 1357.238450]  [&lt;ffffffff81082aae&gt;] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae
[ 1357.238450]  [&lt;ffffffff81083336&gt;] mark_lock+0x106/0x258
[ 1357.238450]  [&lt;ffffffff81084e34&gt;] __lock_acquire+0x2e7/0xe53
[ 1357.238450]  [&lt;ffffffff8102903d&gt;] ? pvclock_clocksource_read+0x48/0xb4
[ 1357.238450]  [&lt;ffffffff810ba6a3&gt;] ? rcu_process_gp_end+0xc0/0xc9
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffff81085ef1&gt;] lock_acquire+0x119/0x143
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffff8149c329&gt;] _raw_spin_lock_irqsave+0x54/0x8e
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffffa01eacd4&gt;] transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450]  [&lt;ffffffff810bb6a0&gt;] ? rcu_process_callbacks+0x229/0x42a
[ 1357.238450]  [&lt;ffffffffa018ddc5&gt;] ft_sess_rcu_free+0x17/0x24 [tcm_fc]
[ 1357.238450]  [&lt;ffffffffa018ddae&gt;] ? ft_sess_free+0x1b/0x1b [tcm_fc]
[ 1357.238450]  [&lt;ffffffff810bb6d7&gt;] rcu_process_callbacks+0x260/0x42a
[ 1357.238450]  [&lt;ffffffff8103d55d&gt;] __do_softirq+0x13a/0x26f
[ 1357.238450]  [&lt;ffffffff8149b34e&gt;] ? __schedule+0x65f/0x68e
[ 1357.238450]  [&lt;ffffffff8103d6bb&gt;] run_ksoftirqd+0x29/0x62
[ 1357.238450]  [&lt;ffffffff8105c83c&gt;] smpboot_thread_fn+0x1a5/0x1aa
[ 1357.238450]  [&lt;ffffffff8105c697&gt;] ? smpboot_unregister_percpu_thread+0x47/0x47
[ 1357.238450]  [&lt;ffffffff810549f1&gt;] kthread+0xb1/0xb9
[ 1357.238450]  [&lt;ffffffff8149b49d&gt;] ? wait_for_common+0xbb/0x10a
[ 1357.238450]  [&lt;ffffffff81054940&gt;] ? __init_kthread_worker+0x59/0x59
[ 1357.238450]  [&lt;ffffffff814a40ec&gt;] ret_from_fork+0x7c/0xb0
[ 1357.238450]  [&lt;ffffffff81054940&gt;] ? __init_kthread_worker+0x59/0x59
[ 1417.440099]  rport-2:0-0: blocked FC remote port time out: removing rport

Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Cc: Open-FCoE &lt;devel@open-fcoe.org&gt;
Cc: Nicholas A. Bellinger &lt;nab@risingtidesystems.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target/file: Fix 32-bit highmem breakage for SGL -&gt; iovec mapping</title>
<updated>2013-01-03T03:33:29+00:00</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2012-12-05T11:08:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1506cb20191c0b33ae0c6cedac7a0ebf4fee3cf7'/>
<id>1506cb20191c0b33ae0c6cedac7a0ebf4fee3cf7</id>
<content type='text'>
commit 40ff2c3b3da35dd3a00ac6722056a59b4b3f2caf upstream.

This patch changes vectored file I/O to use kmap + kunmap when mapping
incoming SGL memory -&gt; struct iovec in order to properly support 32-bit
highmem configurations.  This is because an extra bounce buffer may be
required when processing scatterlist pages allocated with GFP_KERNEL.

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[bwh: Backported to 3.2: use task-&gt;task_sg{,_nents} for iteration]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 40ff2c3b3da35dd3a00ac6722056a59b4b3f2caf upstream.

This patch changes vectored file I/O to use kmap + kunmap when mapping
incoming SGL memory -&gt; struct iovec in order to properly support 32-bit
highmem configurations.  This is because an extra bounce buffer may be
required when processing scatterlist pages allocated with GFP_KERNEL.

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[bwh: Backported to 3.2: use task-&gt;task_sg{,_nents} for iteration]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsit: use GFP_ATOMIC under spin lock</title>
<updated>2013-01-03T03:33:18+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>yongjun_wei@trendmicro.com.cn</email>
</author>
<published>2012-11-23T04:07:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=173dedb8464984b58d2fdec39c09486a1b6b036e'/>
<id>173dedb8464984b58d2fdec39c09486a1b6b036e</id>
<content type='text'>
commit 3c989d7603872bf878840f7ce3ea49b73bea4c6c upstream.

The function iscsit_build_conn_drop_async_message() is called
from iscsit_close_connection() with spin lock 'sess-&gt;conn_lock'
held, so we should use GFP_ATOMIC instead of GFP_KERNEL.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3c989d7603872bf878840f7ce3ea49b73bea4c6c upstream.

The function iscsit_build_conn_drop_async_message() is called
from iscsit_close_connection() with spin lock 'sess-&gt;conn_lock'
held, so we should use GFP_ATOMIC instead of GFP_KERNEL.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Always send a response before terminating iSCSI connection</title>
<updated>2013-01-03T03:33:03+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-11-06T02:02:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9ef928b0104af7c05b03f6a40bffe225b4f4c9e4'/>
<id>9ef928b0104af7c05b03f6a40bffe225b4f4c9e4</id>
<content type='text'>
commit 1c5c12c666fda27c7c494b34934a0a0631a48130 upstream.

There are some cases, for example when the initiator sends an
out-of-bounds ErrorRecoveryLevel value, where the iSCSI target
terminates the connection without sending back any error.  Audit the
login path and add appropriate iscsit_tx_login_rsp() calls to make
sure this doesn't happen.

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1c5c12c666fda27c7c494b34934a0a0631a48130 upstream.

There are some cases, for example when the initiator sends an
out-of-bounds ErrorRecoveryLevel value, where the iSCSI target
terminates the connection without sending back any error.  Audit the
login path and add appropriate iscsit_tx_login_rsp() calls to make
sure this doesn't happen.

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Fix missed wakeup race in TX thread</title>
<updated>2012-11-16T16:47:07+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-31T16:16:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=620cc1df7f260855bfa05f56483ced4be702d57b'/>
<id>620cc1df7f260855bfa05f56483ced4be702d57b</id>
<content type='text'>
commit d5627acba9ae584cf4928af19f7ddf5f6837de32 upstream.

The sleeping code in iscsi_target_tx_thread() is susceptible to the classic
missed wakeup race:

 - TX thread finishes handle_immediate_queue() and handle_response_queue(),
   thinks both queues are empty.
 - Another thread adds a queue entry and does wake_up_process(), which does
   nothing because the TX thread is still awake.
 - TX thread does schedule_timeout() and sleeps forever.

In practice this can kill an iSCSI connection if for example an initiator
does single-threaded writes and the target misses the wakeup window when
queueing an R2T; in this case the connection will be stuck until the
initiator loses patience and does some task management operation (or kills
the connection entirely).

Fix this by converting to wait_event_interruptible(), which does not
suffer from this sort of race.

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d5627acba9ae584cf4928af19f7ddf5f6837de32 upstream.

The sleeping code in iscsi_target_tx_thread() is susceptible to the classic
missed wakeup race:

 - TX thread finishes handle_immediate_queue() and handle_response_queue(),
   thinks both queues are empty.
 - Another thread adds a queue entry and does wake_up_process(), which does
   nothing because the TX thread is still awake.
 - TX thread does schedule_timeout() and sleeps forever.

In practice this can kill an iSCSI connection if for example an initiator
does single-threaded writes and the target misses the wakeup window when
queueing an R2T; in this case the connection will be stuck until the
initiator loses patience and does some task management operation (or kills
the connection entirely).

Fix this by converting to wait_event_interruptible(), which does not
suffer from this sort of race.

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Avoid integer overflow in se_dev_align_max_sectors()</title>
<updated>2012-11-16T16:47:06+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-31T16:16:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ca8b38a5d0489f39245404acea9a1524b29d1cbb'/>
<id>ca8b38a5d0489f39245404acea9a1524b29d1cbb</id>
<content type='text'>
commit 3e03989b5868acf69a391a424dc71fcd6cc48167 upstream.

The expression (max_sectors * block_size) might overflow a u32
(indeed, since iblock sets max_hw_sectors to UINT_MAX, it is
guaranteed to overflow and end up with a much-too-small result in many
common cases).  Fix this by doing an equivalent calculation that
doesn't require multiplication.

While we're touching this code, avoid splitting a printk format across
two lines and use pr_info(...) instead of printk(KERN_INFO ...).

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3e03989b5868acf69a391a424dc71fcd6cc48167 upstream.

The expression (max_sectors * block_size) might overflow a u32
(indeed, since iblock sets max_hw_sectors to UINT_MAX, it is
guaranteed to overflow and end up with a much-too-small result in many
common cases).  Fix this by doing an equivalent calculation that
doesn't require multiplication.

While we're touching this code, avoid splitting a printk format across
two lines and use pr_info(...) instead of printk(KERN_INFO ...).

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>target: Don't return success from module_init() if setup fails</title>
<updated>2012-11-16T16:47:06+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-31T16:16:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c7685e47cf98dbaeaf523b7c235bf251bba1354f'/>
<id>c7685e47cf98dbaeaf523b7c235bf251bba1354f</id>
<content type='text'>
commit 0d0f9dfb31e0a6c92063e235417b42df185b3275 upstream.

If the call to core_dev_release_virtual_lun0() fails, then nothing
sets ret to anything other than 0, so even though everything is
torn down and freed, target_core_init_configfs() will seem to succeed
and the module will be loaded.  Fix this by passing the return value
on up the chain.

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0d0f9dfb31e0a6c92063e235417b42df185b3275 upstream.

If the call to core_dev_release_virtual_lun0() fails, then nothing
sets ret to anything other than 0, so even though everything is
torn down and freed, target_core_init_configfs() will seem to succeed
and the module will be loaded.  Fix this by passing the return value
on up the chain.

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Bump defaults for nopin_timeout + nopin_response_timeout values</title>
<updated>2012-10-17T02:49:29+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2012-10-03T22:42:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=601e4d671ac72bbb37b6d3c5981bd3792ffd07bb'/>
<id>601e4d671ac72bbb37b6d3c5981bd3792ffd07bb</id>
<content type='text'>
commit cf0eb28d3ba60098865bf7dbcbfdd6b1cc483e3b upstream.

This patch increases the default for nopin_timeout to 15 seconds (wait
between sending a new NopIN ping) and nopin_response_timeout to 30 seconds
(wait for NopOUT response before failing the connection) in order to avoid
false positives by iSCSI Initiators who are not always able (under load) to
respond to NopIN echo PING requests within the current 5 second window.

False positives have been observed recently using Open-iSCSI code on v3.3.x
with heavy large-block READ workloads over small MTU 1 Gb/sec ports, and
increasing these values to more reasonable defaults significantly reduces
the possibility of false positive NopIN response timeout events under
this specific workload.

Historically these have been set low to initiate connection recovery as
soon as possible if we don't hear a ping back, but for modern v3.x code
on 1 -&gt; 10 Gb/sec ports these new defaults make alot more sense.

Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Cc: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cf0eb28d3ba60098865bf7dbcbfdd6b1cc483e3b upstream.

This patch increases the default for nopin_timeout to 15 seconds (wait
between sending a new NopIN ping) and nopin_response_timeout to 30 seconds
(wait for NopOUT response before failing the connection) in order to avoid
false positives by iSCSI Initiators who are not always able (under load) to
respond to NopIN echo PING requests within the current 5 second window.

False positives have been observed recently using Open-iSCSI code on v3.3.x
with heavy large-block READ workloads over small MTU 1 Gb/sec ports, and
increasing these values to more reasonable defaults significantly reduces
the possibility of false positive NopIN response timeout events under
this specific workload.

Historically these have been set low to initiate connection recovery as
soon as possible if we don't hear a ping back, but for modern v3.x code
on 1 -&gt; 10 Gb/sec ports these new defaults make alot more sense.

Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Cc: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsit: remove incorrect unlock in iscsit_build_sendtargets_resp</title>
<updated>2012-10-17T02:49:25+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@infradead.org</email>
</author>
<published>2012-09-26T12:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5b84d8279eb9fa68c1e8eb3e79cf1e42607dfd1e'/>
<id>5b84d8279eb9fa68c1e8eb3e79cf1e42607dfd1e</id>
<content type='text'>
commit 904753da183566c71211d23c169a80184648c121 upstream.

Fix a potential multiple spin-unlock -&gt; deadlock scenario during the
overflow check within iscsit_build_sendtargets_resp() as found by
sparse static checking.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 904753da183566c71211d23c169a80184648c121 upstream.

Fix a potential multiple spin-unlock -&gt; deadlock scenario during the
overflow check within iscsit_build_sendtargets_resp() as found by
sparse static checking.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iscsi-target: Add explicit set of cache_dynamic_acls=1 for TPG demo-mode</title>
<updated>2012-10-17T02:49:24+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2012-09-30T19:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0450a208da987620b839d0eecd6dbf3bb50b38e8'/>
<id>0450a208da987620b839d0eecd6dbf3bb50b38e8</id>
<content type='text'>
commit 38b11bae6ba02da352340aff12ee25755977b222 upstream.

We've had reports in the past about this specific case, so it's time to
go ahead and explicitly set cache_dynamic_acls=1 for generate_node_acls=1
(TPG demo-mode) operation.

During normal generate_node_acls=0 operation with explicit NodeACLs -&gt;
se_node_acl memory is persistent to the configfs group located at
/sys/kernel/config/target/$TARGETNAME/$TPGT/acls/$INITIATORNAME, so in
the generate_node_acls=1 case we want the reservation logic to reference
existing per initiator IQN se_node_acl memory (not to generate a new
se_node_acl), so go ahead and always set cache_dynamic_acls=1 when
TPG demo-mode is enabled.

Reported-by: Ronnie Sahlberg &lt;ronniesahlberg@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 38b11bae6ba02da352340aff12ee25755977b222 upstream.

We've had reports in the past about this specific case, so it's time to
go ahead and explicitly set cache_dynamic_acls=1 for generate_node_acls=1
(TPG demo-mode) operation.

During normal generate_node_acls=0 operation with explicit NodeACLs -&gt;
se_node_acl memory is persistent to the configfs group located at
/sys/kernel/config/target/$TARGETNAME/$TPGT/acls/$INITIATORNAME, so in
the generate_node_acls=1 case we want the reservation logic to reference
existing per initiator IQN se_node_acl memory (not to generate a new
se_node_acl), so go ahead and always set cache_dynamic_acls=1 when
TPG demo-mode is enabled.

Reported-by: Ronnie Sahlberg &lt;ronniesahlberg@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
