<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/target, branch v3.4.26</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/target?h=v3.4.26</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/target?h=v3.4.26'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-01-17T16:50:45Z</updated>
<entry>
<title>target/tcm_fc: fix the lockdep warning due to inconsistent lock state</title>
<updated>2013-01-17T16:50:45Z</updated>
<author>
<name>Yi Zou</name>
<email>yi.zou@intel.com</email>
</author>
<published>2012-12-11T01:04:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=28a63b67b3d52e40826d82425307e8f067551106'/>
<id>urn:sha1:28a63b67b3d52e40826d82425307e8f067551106</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iscsit: use GFP_ATOMIC under spin lock</title>
<updated>2013-01-17T16:50:44Z</updated>
<author>
<name>Wei Yongjun</name>
<email>yongjun_wei@trendmicro.com.cn</email>
</author>
<published>2012-11-23T04:07:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=370caef9e8e2800a759d9c29e2c4d41375bdad62'/>
<id>urn:sha1:370caef9e8e2800a759d9c29e2c4d41375bdad62</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: Fix incorrect usage of nested IRQ spinlocks in ABORT_TASK path</title>
<updated>2012-11-17T21:15:55Z</updated>
<author>
<name>Steve Hodgson</name>
<email>steve@purestorage.com</email>
</author>
<published>2012-10-31T17:24:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bfc5de3bc907e97b9aabce6d6517a55d5ed6d791'/>
<id>urn:sha1:bfc5de3bc907e97b9aabce6d6517a55d5ed6d791</id>
<content type='text'>
commit ab74b3d62f05192bf8fb8f169e7999d1183b2e08 upstream.

This patch changes core_tmr_abort_task() to use spin_lock -&gt; spin_unlock
around se_cmd-&gt;t_state_lock while spin_lock_irqsave is held via
se_sess-&gt;sess_cmd_lock.

Signed-off-by: Steve Hodgson &lt;steve@purestorage.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iscsi-target: Fix missed wakeup race in TX thread</title>
<updated>2012-11-17T21:15:55Z</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-31T16:16:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7f83bc1f1bff2e9b89b3a505750b067f0073fe5c'/>
<id>urn:sha1:7f83bc1f1bff2e9b89b3a505750b067f0073fe5c</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: Avoid integer overflow in se_dev_align_max_sectors()</title>
<updated>2012-11-17T21:15:55Z</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-31T16:16:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=227ab73196544a25f0c03338c5b49d3fdc1d1e38'/>
<id>urn:sha1:227ab73196544a25f0c03338c5b49d3fdc1d1e38</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: Don't return success from module_init() if setup fails</title>
<updated>2012-11-17T21:15:55Z</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-31T16:16:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=506485a3c6d926cc01e6d05088eac94adf1d6ae5'/>
<id>urn:sha1:506485a3c6d926cc01e6d05088eac94adf1d6ae5</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: Fix double-free of se_cmd in target_complete_tmr_failure</title>
<updated>2012-11-05T08:50:42Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2012-10-26T22:35:45Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8c9c9dfcd1d31e2f149ea991f15bfdd4b5e1496e'/>
<id>urn:sha1:8c9c9dfcd1d31e2f149ea991f15bfdd4b5e1496e</id>
<content type='text'>
commit e13d5fef88c40b87c8430f8274c3a9ca32ef90bc upstream.

Fabric drivers currently expect to internally release se_cmd in the event
of a TMR failure during target_submit_tmr(), which means the immediate call
to transport_generic_free_cmd() after TFO-&gt;queue_tm_rsp() from within
target_complete_tmr_failure() workqueue context is wrong.

This is done as some fabrics expect TMR operations to be acknowledged
before releasing the descriptor, so the assumption that core is releasing
se_cmd associated TMR memory is incorrect.  This fixes a OOPs where
transport_generic_free_cmd() was being called more than once.

This bug was originally observed with tcm_qla2xxx fabric ports.

Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Andy Grover &lt;agrover@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: fix return code in target_core_init_configfs error path</title>
<updated>2012-10-21T16:27:58Z</updated>
<author>
<name>Peter Senna Tschudin</name>
<email>peter.senna@gmail.com</email>
</author>
<published>2012-09-17T18:05:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e1621ec4754097582c73c0ed8c394dcc50b1e0fd'/>
<id>urn:sha1:e1621ec4754097582c73c0ed8c394dcc50b1e0fd</id>
<content type='text'>
commit 37bb7899ca366dc212b71b150e78566d04808cc0 upstream.

This patch fixes error cases within target_core_init_configfs() to
properly set ret = -ENOMEM before jumping to the out_global exception
path.

This was originally discovered with the following Coccinelle semantic
match information:

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.  A simplified version of the semantic match
that finds this problem is as follows: (http://coccinelle.lip6.fr/)

// &lt;smpl&gt;
(
if@p1 (\(ret &lt; 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &amp;ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// &lt;/smpl&gt;

Signed-off-by: Peter Senna Tschudin &lt;peter.senna@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iscsi-target: Bump defaults for nopin_timeout + nopin_response_timeout values</title>
<updated>2012-10-21T16:27:58Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2012-10-03T22:42:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2a7c11208e542071eee2240dde98e1673f5c01d4'/>
<id>urn:sha1:2a7c11208e542071eee2240dde98e1673f5c01d4</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.

Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iscsi-target: Add explicit set of cache_dynamic_acls=1 for TPG demo-mode</title>
<updated>2012-10-21T16:27:58Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2012-09-30T19:20:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a114a8b43b038c327aff0298cfb69509469e84b4'/>
<id>urn:sha1:a114a8b43b038c327aff0298cfb69509469e84b4</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
