<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers, branch v3.12.24</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers?h=v3.12.24</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers?h=v3.12.24'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-07-02T10:06:43Z</updated>
<entry>
<title>efi-pstore: Fix an overflow on 32-bit builds</title>
<updated>2014-07-02T10:06:43Z</updated>
<author>
<name>Andrzej Zaborowski</name>
<email>andrew.zaborowski@intel.com</email>
</author>
<published>2014-06-09T14:50:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8c23d6e199b45b042ae76cdbcfac467c7ce4e52e'/>
<id>urn:sha1:8c23d6e199b45b042ae76cdbcfac467c7ce4e52e</id>
<content type='text'>
commit 783ee43118dc773bc8b0342c5b230e017d5a04d0 upstream.

In generic_id the long int timestamp is multiplied by 100000 and needs
an explicit cast to u64.

Without that the id in the resulting pstore filename is wrong and
userspace may have problems parsing it, but more importantly files in
pstore can never be deleted and may fill the EFI flash (brick device?).
This happens because when generic pstore code wants to delete a file,
it passes the id to the EFI backend which reinterpretes it and a wrong
variable name is attempted to be deleted.  There's no error message but
after remounting pstore, deleted files would reappear.

Signed-off-by: Andrew Zaborowski &lt;andrew.zaborowski@intel.com&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>target: Explicitly clear ramdisk_mcp backend pages</title>
<updated>2014-07-02T10:06:32Z</updated>
<author>
<name>Nicholas A. Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-06-16T20:59:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=186f32e2096c7d9cd9106b8dedd79c596f4c8398'/>
<id>urn:sha1:186f32e2096c7d9cd9106b8dedd79c596f4c8398</id>
<content type='text'>
[Note that a different patch to address the same issue went in during
v3.15-rc1 (commit 4442dc8a), but includes a bunch of other changes that
don't strictly apply to fixing the bug]

This patch changes rd_allocate_sgl_table() to explicitly clear
ramdisk_mcp backend memory pages by passing __GFP_ZERO into
alloc_pages().

This addresses a potential security issue where reading from a
ramdisk_mcp could return sensitive information, and follows what
&gt;= v3.15 does to explicitly clear ramdisk_mcp memory at backend
device initialization time.

Reported-by: Jorge Daniel Sequeira Matias &lt;jdsm@tecnico.ulisboa.pt&gt;
Cc: Jorge Daniel Sequeira Matias &lt;jdsm@tecnico.ulisboa.pt&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>target: Report correct response length for some commands</title>
<updated>2014-07-02T10:06:32Z</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2014-06-10T18:07:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3942c33e4b6b84653b04314f526907ae74984f87'/>
<id>urn:sha1:3942c33e4b6b84653b04314f526907ae74984f87</id>
<content type='text'>
commit 2426bd456a61407388b6e61fc5f98dbcbebc50e2 upstream.

When an initiator sends an allocation length bigger than what its
command consumes, the target should only return the actual response data
and set the residual length to the unused part of the allocation length.

Add a helper function that command handlers (INQUIRY, READ CAPACITY,
etc) can use to do this correctly, and use this code to get the correct
residual for commands that don't use the full initiator allocation in the
handlers for READ CAPACITY, READ CAPACITY(16), INQUIRY, MODE SENSE and
REPORT LUNS.

This addresses a handful of failures as reported by Christophe with
the Windows Certification Kit:

  http://permalink.gmane.org/gmane.linux.scsi.target.devel/6515

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Tested-by: Christophe Vu-Brugier &lt;cvubrugier@yahoo.fr&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Target/iscsi: Fix sendtargets response pdu for iser transport</title>
<updated>2014-07-02T10:06:31Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2014-06-10T15:27:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=53f1d104f250540853271653f507ac09b4bfc66e'/>
<id>urn:sha1:53f1d104f250540853271653f507ac09b4bfc66e</id>
<content type='text'>
commit 22c7aaa57e80853b4904a46c18f97db0036a3b97 upstream.

In case the transport is iser we should not include the
iscsi target info in the sendtargets text response pdu.
This causes sendtargets response to include the target
info twice.

Modify iscsit_build_sendtargets_response to filter
transport types that don't match.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Reported-by: Slava Shwartsman &lt;valyushash@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>iscsi-target: Fix ABORT_TASK + connection reset iscsi_queue_req memory leak</title>
<updated>2014-07-02T10:06:31Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-06-10T04:03:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=18b0e46ab4670436bcef4df0807ade2ffa7901ce'/>
<id>urn:sha1:18b0e46ab4670436bcef4df0807ade2ffa7901ce</id>
<content type='text'>
commit bbc050488525e1ab1194c27355f63c66814385b8 upstream.

This patch fixes a iscsi_queue_req memory leak when ABORT_TASK response
has been queued by TFO-&gt;queue_tm_rsp() -&gt; lio_queue_tm_rsp() after a
long standing I/O completes, but the connection has already reset and
waiting for cleanup to complete in iscsit_release_commands_from_conn()
-&gt; transport_generic_free_cmd() -&gt; transport_wait_for_tasks() code.

It moves iscsit_free_queue_reqs_for_conn() after the per-connection command
list has been released, so that the associated se_cmd tag can be completed +
released by target-core before freeing any remaining iscsi_queue_req memory
for the connection generated by lio_queue_tm_rsp().

Cc: Thomas Glanzmann &lt;thomas@glanzmann.de&gt;
Cc: Charalampos Pournaris &lt;charpour@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>target: Use complete_all for se_cmd-&gt;t_transport_stop_comp</title>
<updated>2014-07-02T10:06:30Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-06-09T23:36:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ab7f3e4697f12ad16c816fdb27e3e494809bad91'/>
<id>urn:sha1:ab7f3e4697f12ad16c816fdb27e3e494809bad91</id>
<content type='text'>
commit a95d6511303b848da45ee27b35018bb58087bdc6 upstream.

This patch fixes a bug where multiple waiters on -&gt;t_transport_stop_comp
occurs due to a concurrent ABORT_TASK and session reset both invoking
transport_wait_for_tasks(), while waiting for the associated se_cmd
descriptor backend processing to complete.

For this case, complete_all() should be invoked in order to wake up
both waiters in core_tmr_abort_task() + transport_generic_free_cmd()
process contexts.

Cc: Thomas Glanzmann &lt;thomas@glanzmann.de&gt;
Cc: Charalampos Pournaris &lt;charpour@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>target: Set CMD_T_ACTIVE bit for Task Management Requests</title>
<updated>2014-07-02T10:06:30Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-06-09T23:13:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a08f9367aa469714683c41b0780c598945fa1099'/>
<id>urn:sha1:a08f9367aa469714683c41b0780c598945fa1099</id>
<content type='text'>
commit f15e9cd910c4d9da7de43f2181f362082fc45f0f upstream.

This patch fixes a bug where se_cmd descriptors associated with a
Task Management Request (TMR) where not setting CMD_T_ACTIVE before
being dispatched into target_tmr_work() process context.

This is required in order for transport_generic_free_cmd() -&gt;
transport_wait_for_tasks() to wait on se_cmd-&gt;t_transport_stop_comp
if a session reset event occurs while an ABORT_TASK is outstanding
waiting for another I/O to complete.

Cc: Thomas Glanzmann &lt;thomas@glanzmann.de&gt;
Cc: Charalampos Pournaris &lt;charpour@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Target/iser: Wait for proper cleanup before unloading</title>
<updated>2014-07-02T10:06:29Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2014-05-19T14:44:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1d88b1199369e23dae9261f2861cda9e431aee76'/>
<id>urn:sha1:1d88b1199369e23dae9261f2861cda9e431aee76</id>
<content type='text'>
commit f5ebec9629cf78eeeea4b8258882a9f439ab2404 upstream.

disconnected_handler works are scheduled on system_wq.
When attempting to unload, first make sure all works
have cleaned up.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Target/iser: Improve cm events handling</title>
<updated>2014-07-02T10:06:29Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2014-05-19T14:44:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f3c158abb8cbde83e5c95431db41d8da9acd7e98'/>
<id>urn:sha1:f3c158abb8cbde83e5c95431db41d8da9acd7e98</id>
<content type='text'>
commit 88c4015fda6d014392f76d3b1688347950d7a12d upstream.

There are 4 RDMA_CM events that all basically mean that
the user should teardown the IB connection:
- DISCONNECTED
- ADDR_CHANGE
- DEVICE_REMOVAL
- TIMEWAIT_EXIT

Only in DISCONNECTED/ADDR_CHANGE it makes sense to
call rdma_disconnect (send DREQ/DREP to our initiator).
So we keep the same teardown handler for all of them
but only indicate calling rdma_disconnect for the relevant
events.

This patch also removes redundant debug prints for each single
event.

v2 changes:
 - Call isert_disconnected_handler() for DEVICE_REMOVAL (Or + Sag)

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
<entry>
<title>Target/iser: Fix hangs in connection teardown</title>
<updated>2014-07-02T10:06:28Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2014-05-19T14:44:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=34992ea555198a7c1df1700444773324254a7a87'/>
<id>urn:sha1:34992ea555198a7c1df1700444773324254a7a87</id>
<content type='text'>
commit 9d49f5e284e700576f3b65f1e28dea8539da6661 upstream.

In ungraceful teardowns isert close flows seem racy such that
isert_wait_conn hangs as RDMA_CM_EVENT_DISCONNECTED never
gets invoked (no one called rdma_disconnect).

Both graceful and ungraceful teardowns will have rx flush errors
(isert posts a batch once connection is established). Once all
flush errors are consumed we invoke isert_wait_conn and it will
be responsible for calling rdma_disconnect. This way it can be
sure that rdma_disconnect was called and it won't wait forever.

This patch also removes the logout_posted indicator. either the
logout completion was consumed and no problem decrementing the
post_send_buf_count, or it was consumed as a flush error. no point
of keeping it for isert_wait_conn as there is no danger that
isert_conn will be accidentally removed while it is running.

(Drop unnecessary sleep_on_conn_wait_comp check in
 isert_cq_rx_comp_err - nab)

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
</entry>
</feed>
