<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v3.14.77</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.14.77</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.14.77'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-08-20T09:53:43+00:00</updated>
<entry>
<title>Linux 3.14.77</title>
<updated>2016-08-20T09:53:43+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2016-08-20T09:53:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb28cae901ddf2a4c708dbd03e9e304536c966dc'/>
<id>urn:sha1:bb28cae901ddf2a4c708dbd03e9e304536c966dc</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Documentation/module-signing.txt: Note need for version info if reusing a key</title>
<updated>2016-08-20T09:53:23+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2016-04-27T23:54:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b792e7f015c8030d54f3a0833d1193f81c2b393b'/>
<id>urn:sha1:b792e7f015c8030d54f3a0833d1193f81c2b393b</id>
<content type='text'>
commit b8612e517c3c9809e1200b72c474dbfd969e5a83 upstream.

Signing a module should only make it trusted by the specific kernel it
was built for, not anything else.  If a module signing key is used for
multiple ABI-incompatible kernels, the modules need to include enough
version information to distinguish them.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>module: Invalidate signatures on force-loaded modules</title>
<updated>2016-08-20T09:53:23+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2016-04-27T23:54:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc77c4ad276a03ac9217e7db44339003ba1de6bd'/>
<id>urn:sha1:fc77c4ad276a03ac9217e7db44339003ba1de6bd</id>
<content type='text'>
commit bca014caaa6130e57f69b5bf527967aa8ee70fdd upstream.

Signing a module should only make it trusted by the specific kernel it
was built for, not anything else.  Loading a signed module meant for a
kernel with a different ABI could have interesting effects.
Therefore, treat all signatures as invalid when a module is
force-loaded.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dm flakey: error READ bios during the down_interval</title>
<updated>2016-08-20T09:53:23+00:00</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2016-07-29T17:19:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7aca820d3b93fa028ecb2077b482587a26beeb6'/>
<id>urn:sha1:b7aca820d3b93fa028ecb2077b482587a26beeb6</id>
<content type='text'>
commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 upstream.

When the corrupt_bio_byte feature was introduced it caused READ bios to
no longer be errored with -EIO during the down_interval.  This had to do
with the complexity of needing to submit READs if the corrupt_bio_byte
feature was used.

Fix it so READ bios are properly errored with -EIO; doing so early in
flakey_map() as long as there isn't a match for the corrupt_bio_byte
feature.

Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
Reported-by: Akira Hayakawa &lt;ruby.wktk@gmail.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset</title>
<updated>2016-08-20T09:53:22+00:00</updated>
<author>
<name>Chris Blake</name>
<email>chrisrblake93@gmail.com</email>
</author>
<published>2016-05-30T12:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc72d914c05f530dec9c7f5f4e301700e6e4c4ba'/>
<id>urn:sha1:dc72d914c05f530dec9c7f5f4e301700e6e4c4ba</id>
<content type='text'>
commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 upstream.

Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake &lt;chrisrblake93@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>target: Fix max_unmap_lba_count calc overflow</title>
<updated>2016-08-20T09:53:22+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2016-06-03T01:12:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=034668ac914f360ac300d56d4cb80f2b919852fa'/>
<id>urn:sha1:034668ac914f360ac300d56d4cb80f2b919852fa</id>
<content type='text'>
commit ea263c7fada4af8ec7fe5fcfd6e7d7705a89351b upstream.

max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.

This fixes a regression caused by my patch:

commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie &lt;mchristi@redhat.com&gt;
Date:   Mon Jan 18 14:09:27 2016 -0600

    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.

Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.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 race between iscsi-target connection shutdown + ABORT_TASK</title>
<updated>2016-08-20T09:53:22+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-06-02T21:56:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4a233770354929cd5c0178c0f09aa12d2227715'/>
<id>urn:sha1:e4a233770354929cd5c0178c0f09aa12d2227715</id>
<content type='text'>
commit 064cdd2d91c2805d788876082f31cc63506f22c3 upstream.

This patch fixes a race in iscsit_release_commands_from_conn() -&gt;
iscsit_free_cmd() -&gt; transport_generic_free_cmd() + wait_for_tasks=1,
where CMD_T_FABRIC_STOP could end up being set after the final
kref_put() is called from core_tmr_abort_task() context.

This results in transport_generic_free_cmd() blocking indefinately
on se_cmd-&gt;cmd_wait_comp, because the target_release_cmd_kref()
check for CMD_T_FABRIC_STOP returns false.

To address this bug, make iscsit_release_commands_from_conn()
do list_splice and set CMD_T_FABRIC_STOP early while holding
iscsi_conn-&gt;cmd_lock.  Also make iscsit_aborted_task() only
remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
set.

Finally in target_release_cmd_kref(), only honor fabric_stop
if CMD_T_ABORTED has been set.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.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>ubi: Fix race condition between ubi device creation and udev</title>
<updated>2016-08-20T09:53:22+00:00</updated>
<author>
<name>Iosif Harutyunov</name>
<email>iharutyunov@SonicWALL.com</email>
</author>
<published>2016-07-22T23:22:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6117840dec60344167038f9511c3770d4c096eaa'/>
<id>urn:sha1:6117840dec60344167038f9511c3770d4c096eaa</id>
<content type='text'>
commit 714fb87e8bc05ff78255afc0dca981e8c5242785 upstream.

Install the UBI device object before we arm sysfs.
Otherwise udev tries to read sysfs attributes before UBI is ready and
udev rules will not match.

Signed-off-by: Iosif Harutyunov &lt;iharutyunov@sonicwall.com&gt;
[rw: massaged commit message]
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ubi: Make volume resize power cut aware</title>
<updated>2016-08-20T09:53:22+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-06-23T17:30:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=83770c0e1822e505bb71d8c1e118feb92eacf8a0'/>
<id>urn:sha1:83770c0e1822e505bb71d8c1e118feb92eacf8a0</id>
<content type='text'>
commit 4946784bd3924b1374f05eebff2fd68660bae866 upstream.

When the volume resize operation shrinks a volume,
LEBs will be unmapped. Since unmapping will not erase these
LEBs immediately we have to wait for that operation to finish.
Otherwise in case of a power cut right after writing the new
volume table the UBI attach process can find more LEBs than the
volume table knows. This will render the UBI image unattachable.

Fix this issue by waiting for erase to complete and write the new
volume table afterward.

Reported-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/mlx4: Fix the SQ size of an RC QP</title>
<updated>2016-08-20T09:53:22+00:00</updated>
<author>
<name>Yishai Hadas</name>
<email>yishaih@mellanox.com</email>
</author>
<published>2016-06-22T14:27:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b873cc9edceee10f05ee789ae633d87322edc1f4'/>
<id>urn:sha1:b873cc9edceee10f05ee789ae633d87322edc1f4</id>
<content type='text'>
commit f2940e2c76bb554a7fbdd28ca5b90904117a9e96 upstream.

When calculating the required size of an RC QP send queue, leave
enough space for masked atomic operations, which require more space than
"regular" atomic operation.

Fixes: 6fa8f719844b ("IB/mlx4: Add support for masked atomic operations")
Signed-off-by: Yishai Hadas &lt;yishaih@mellanox.com&gt;
Reviewed-by: Jack Morgenstein &lt;jackm@mellanox.co.il&gt;
Reviewed-by: Eran Ben Elisha &lt;eranbe@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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