<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/target/iscsi, branch v3.4.55</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.55</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.55'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2013-06-27T18:27:33+00:00</updated>
<entry>
<title>target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()</title>
<updated>2013-06-27T18:27:33+00:00</updated>
<author>
<name>Joern Engel</name>
<email>joern@logfs.org</email>
</author>
<published>2013-05-30T20:36:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c3017e4b2d21feed4a510c1ee69aa77d2384493'/>
<id>urn:sha1:4c3017e4b2d21feed4a510c1ee69aa77d2384493</id>
<content type='text'>
commit 574780fd5e6ec52bd43e0bdb777a19e4c4c6aa9c upstream.

Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
almost two years ago.  I have no idea why we only started seeing it now,
but we did.

Rough callgraph:
core_tpg_set_initiator_node_queue_depth()
`-&gt; spin_lock_irqsave(&amp;tpg-&gt;session_lock, flags);
`-&gt; lio_tpg_shutdown_session()
    `-&gt; iscsit_stop_time2retain_timer()
        `-&gt; spin_unlock_bh(&amp;se_tpg-&gt;session_lock);
        `-&gt; spin_lock_bh(&amp;se_tpg-&gt;session_lock);
`-&gt; spin_unlock_irqrestore(&amp;tpg-&gt;session_lock, flags);

core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
but 140854cb changed that to spin_lock_irqsave().  However,
lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
held, as does iscsit_stop_time2retain_timer():
 *      Called with spin_lock_bh(&amp;struct se_portal_group-&gt;session_lock) held

Stale documentation is mostly annoying, but in this case the dropping
the lock with the _bh variant is plain wrong.  It is also wrong to drop
locks two functions below the lock-holder, but I will ignore that bit
for now.

After some more locking and unlocking we eventually hit this backtrace:
------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
Call Trace:
 [&lt;ffffffff8103e5ff&gt;] warn_slowpath_common+0x7f/0xc0
 [&lt;ffffffffa040ae37&gt;] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
 [&lt;ffffffff8103e65a&gt;] warn_slowpath_null+0x1a/0x20
 [&lt;ffffffff810472f8&gt;] local_bh_enable_ip+0xe8/0x100
 [&lt;ffffffff815b8365&gt;] _raw_spin_unlock_bh+0x15/0x20
 [&lt;ffffffffa040ae37&gt;] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
 [&lt;ffffffffa041149a&gt;] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
 [&lt;ffffffffa0417fab&gt;] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
 [&lt;ffffffffa033ede4&gt;] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
 [&lt;ffffffffa0409032&gt;] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
 [&lt;ffffffffa0415c29&gt;] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
 [&lt;ffffffffa0331b49&gt;] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
 [&lt;ffffffff811b857d&gt;] configfs_write_file+0xbd/0x120
 [&lt;ffffffff81148f36&gt;] vfs_write+0xc6/0x180
 [&lt;ffffffff81149251&gt;] sys_write+0x51/0x90
 [&lt;ffffffff815c0969&gt;] system_call_fastpath+0x16/0x1b
---[ end trace 3747632b9b164652 ]---

As a pure band-aid, this patch drops the _bh.

Signed-off-by: Joern Engel &lt;joern@logfs.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;

</content>
</entry>
<entry>
<title>iscsi-target: fix heap buffer overflow on error</title>
<updated>2013-06-07T19:49:29+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2013-05-23T17:32:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c12b0057706c0694c96c06a2988fed65c8c7515'/>
<id>urn:sha1:7c12b0057706c0694c96c06a2988fed65c8c7515</id>
<content type='text'>
commit cea4dcfdad926a27a18e188720efe0f2c9403456 upstream.

If a key was larger than 64 bytes, as checked by iscsi_check_key(), the
error response packet, generated by iscsi_add_notunderstood_response(),
would still attempt to copy the entire key into the packet, overflowing
the structure on the heap.

Remote preauthentication kernel memory corruption was possible if a
target was configured and listening on the network.

CVE-2013-2850

Signed-off-by: Kees Cook &lt;keescook@chromium.org&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 processing of OOO commands</title>
<updated>2013-05-19T17:54:49+00:00</updated>
<author>
<name>Shlomo Pongratz</name>
<email>shlomop@mellanox.com</email>
</author>
<published>2013-05-05T14:36:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=173603ab8ed8aff22b3606abf3b1dc591cc5ccd7'/>
<id>urn:sha1:173603ab8ed8aff22b3606abf3b1dc591cc5ccd7</id>
<content type='text'>
commit 3eccfdb01da58fbd0f789ae6ca61cee3769e26de upstream.

Fix two issues in OOO commands processing done at iscsit_attach_ooo_cmdsn.

Handle command serial numbers wrap around by using iscsi_sna_lt and not regular comparisson.

The routine iterates until it finds an entry whose serial number is greater than the serial number of
the new one, thus the new entry should be inserted before that entry and not after.

Signed-off-by: Shlomo Pongratz &lt;shlomop@mellanox.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/iscsi: Fix mutual CHAP auth on big-endian arches</title>
<updated>2013-03-28T19:12:13+00:00</updated>
<author>
<name>Andy Grover</name>
<email>agrover@redhat.com</email>
</author>
<published>2013-03-04T21:52:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e8d94de159e7520e6ff1ecaf8419844b93631e7'/>
<id>urn:sha1:6e8d94de159e7520e6ff1ecaf8419844b93631e7</id>
<content type='text'>
commit 7ac9ad11b2a5cf77a92b58ee6b672ad2fa155eb1 upstream.

See https://bugzilla.redhat.com/show_bug.cgi?id=916290

Used a temp var since we take its address in sg_init_one.

Signed-off-by: Andy Grover &lt;agrover@redhat.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:44+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.radix-linux.su/kernel/linux.git/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>iscsi-target: Fix missed wakeup race in TX thread</title>
<updated>2012-11-17T21:15:55+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.radix-linux.su/kernel/linux.git/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>iscsi-target: Bump defaults for nopin_timeout + nopin_response_timeout values</title>
<updated>2012-10-21T16:27:58+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.radix-linux.su/kernel/linux.git/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:58+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.radix-linux.su/kernel/linux.git/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>
<entry>
<title>iscsit: remove incorrect unlock in iscsit_build_sendtargets_resp</title>
<updated>2012-10-21T16:27:58+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.radix-linux.su/kernel/linux.git/commit/?id=b095d61243b5f2333e2ae11a9051cd9d47597002'/>
<id>urn:sha1:b095d61243b5f2333e2ae11a9051cd9d47597002</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iscsi-target: Correctly set 0xffffffff field within ISCSI_OP_REJECT PDU</title>
<updated>2012-10-21T16:27:58+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2012-09-23T00:21:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1faef9285ad868082403da1cec5adefc0c505c2e'/>
<id>urn:sha1:1faef9285ad868082403da1cec5adefc0c505c2e</id>
<content type='text'>
commit f25590f39d543272f7ae7b00d533359c8d7ff331 upstream.

This patch adds a missing iscsi_reject-&gt;ffffffff assignment within
iscsit_send_reject() code to properly follow RFC-3720 Section 10.17
Bytes 16 -&gt; 19 for the PDU format definition of ISCSI_OP_REJECT.

We've not seen any initiators care about this bytes in practice, but
as Ronnie reported this was causing trouble with wireshark packet
decoding lets go ahead and fix this up now.

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>
