<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v3.10.34</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.34</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.34'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-03-24T04:42:03Z</updated>
<entry>
<title>Linux 3.10.34</title>
<updated>2014-03-24T04:42:03Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2014-03-24T04:42:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=10f8245e0d3650144b034142c8f91e5d15c392ab'/>
<id>urn:sha1:10f8245e0d3650144b034142c8f91e5d15c392ab</id>
<content type='text'>
</content>
</entry>
<entry>
<title>PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures</title>
<updated>2014-03-24T04:38:22Z</updated>
<author>
<name>Zhang Rui</name>
<email>rui.zhang@intel.com</email>
</author>
<published>2014-03-11T14:40:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ae59ae911d2c14cf23843b9f12a935610c9c3db1'/>
<id>urn:sha1:ae59ae911d2c14cf23843b9f12a935610c9c3db1</id>
<content type='text'>
commit 89935315f192abf7068d0044cefc84f162c3c81f upstream.

Before commit b355cee88e3b (ACPI / resources: ignore invalid ACPI
device resources), if acpi_dev_resource_memory()/acpi_dev_resource_io()
returns false, it means the the resource is not a memeory/IO resource.

But after commit b355cee88e3b, those functions return false if the
given memory/IO resource entry is invalid (the length of the resource
is zero).

This breaks pnpacpi_allocated_resource(), because it now recognizes
the invalid memory/io resources as resources of unknown type.  Thus
users see confusing warning messages on machines with zero length
ACPI memory/IO resources.

Fix the problem by rearranging pnpacpi_allocated_resource() so that
it calls acpi_dev_resource_memory() for memory type and IO type
resources only, respectively.

Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Reported-and-tested-by: Markus Trippelsdorf &lt;markus@trippelsdorf.de&gt;
Reported-and-tested-by: Julian Wollrath &lt;jwollrath@web.de&gt;
Reported-and-tested-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iser-target: Fix post_send_buf_count for RDMA READ/WRITE</title>
<updated>2014-03-24T04:38:22Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-02-27T17:05:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0bf95498441319bcdba6fc4d8307091cd66bfc5e'/>
<id>urn:sha1:0bf95498441319bcdba6fc4d8307091cd66bfc5e</id>
<content type='text'>
commit b6b87a1df604678ed1be40158080db012a99ccca upstream.

This patch fixes the incorrect setting of -&gt;post_send_buf_count
related to RDMA WRITEs + READs where isert_rdma_rw-&gt;send_wr_num
was not being taken into account.

This includes incrementing -&gt;post_send_buf_count within
isert_put_datain() + isert_get_dataout(), decrementing within
__isert_send_completion() + isert_response_completion(), and
clearing wr-&gt;send_wr_num within isert_completion_rdma_read()

This is necessary because even though IB_SEND_SIGNALED is
not set for RDMA WRITEs + READs, during a QP failure event
the work requests will be returned with exception status
from the TX completion queue.

Acked-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Or Gerlitz &lt;ogerlitz@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>iscsi/iser-target: Fix isert_conn-&gt;state hung shutdown issues</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-02-03T20:54:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d8bd97a03ce979b216df151e3b991023e6b72917'/>
<id>urn:sha1:d8bd97a03ce979b216df151e3b991023e6b72917</id>
<content type='text'>
commit defd884845297fd5690594bfe89656b01f16d87e upstream.

This patch addresses a couple of different hug shutdown issues
related to wait_event() + isert_conn-&gt;state.  First, it changes
isert_conn-&gt;conn_wait + isert_conn-&gt;conn_wait_comp_err from
waitqueues to completions, and sets ISER_CONN_TERMINATING from
within isert_disconnect_work().

Second, it splits isert_free_conn() into isert_wait_conn() that
is called earlier in iscsit_close_connection() to ensure that
all outstanding commands have completed before continuing.

Finally, it breaks isert_cq_comp_err() into seperate TX / RX
related code, and adds logic in isert_cq_rx_comp_err() to wait
for outstanding commands to complete before setting ISER_CONN_DOWN
and calling complete(&amp;isert_conn-&gt;conn_wait_comp_err).

Acked-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Or Gerlitz &lt;ogerlitz@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>iscsi/iser-target: Use list_del_init for -&gt;i_conn_node</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-02-03T20:53:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=af737f6739b80e4a9fc471fa0595740caf720714'/>
<id>urn:sha1:af737f6739b80e4a9fc471fa0595740caf720714</id>
<content type='text'>
commit 5159d763f60af693a3fcec45dce2021f66e528a4 upstream.

There are a handful of uses of list_empty() for cmd-&gt;i_conn_node
within iser-target code that expect to return false once a cmd
has been removed from the per connect list.

This patch changes all uses of list_del -&gt; list_del_init in order
to ensure that list_empty() returns false as expected.

Acked-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; #3.10+
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>ARM: ignore memory below PHYS_OFFSET</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2014-01-11T11:22:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=22fc72288f35219585f11fd40e663c0d3a30a28a'/>
<id>urn:sha1:22fc72288f35219585f11fd40e663c0d3a30a28a</id>
<content type='text'>
commit 571b14375019c3a66ef70d4d4a7083f4238aca30 upstream.

If the kernel is loaded higher in physical memory than normal, and we
calculate PHYS_OFFSET higher than the start of RAM, this leads to
boot problems as we attempt to map part of this RAM into userspace.
Rather than struggle with this, just truncate the mapping.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 7864/1: Handle 64-bit memory in case of 32-bit phys_addr_t</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Magnus Damm</name>
<email>damm@opensource.se</email>
</author>
<published>2013-10-22T16:59:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=307af156795a3009398e609719cd557f58a20907'/>
<id>urn:sha1:307af156795a3009398e609719cd557f58a20907</id>
<content type='text'>
commit 6d7d5da7d75c6df676c8b72d32b02ff024438f0c upstream.

Use CONFIG_ARCH_PHYS_ADDR_T_64BIT to determine
if ignoring or truncating of memory banks is
neccessary. This may be needed in the case of
64-bit memory bank addresses but when phys_addr_t
is kept 32-bit.

Signed-off-by: Magnus Damm &lt;damm@opensource.se&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Cc: Wang Nan &lt;wangnan0@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: mvm: don't WARN when statistics are handled late</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2014-03-04T08:28:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=798610b539f631feef5af5bd713d197712e08ff1'/>
<id>urn:sha1:798610b539f631feef5af5bd713d197712e08ff1</id>
<content type='text'>
commit 1e9291996c4eedf79883f47ec635235e39d3d6cd upstream.

Since the statistics handler is asynchrous, it can very well
be that we will handle the statistics (hence the RSSI
fluctuation) when we already disassociated.
Don't WARN on this case.

This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998

Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power")
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>tick: Make oneshot broadcast robust vs. CPU offlining</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2013-06-26T10:17:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a191212af8f4895d6a40c9d53fa84e9ae575ecd0'/>
<id>urn:sha1:a191212af8f4895d6a40c9d53fa84e9ae575ecd0</id>
<content type='text'>
commit c9b5a266b103af873abb9ac03bc3d067702c8f4b upstream.

In periodic mode we remove offline cpus from the broadcast propagation
mask. In oneshot mode we fail to do so. This was not a problem so far,
but the recent changes to the broadcast propagation introduced a
constellation which can result in a NULL pointer dereference.

What happens is:

CPU0			CPU1
			idle()
			  arch_idle()
			    tick_broadcast_oneshot_control(OFF);
			      set cpu1 in tick_broadcast_force_mask
			  if (cpu_offline())
			     arch_cpu_dead()

cpu_dead_cleanup(cpu1)
 cpu1 tickdevice pointer = NULL

broadcast interrupt
  dereference cpu1 tickdevice pointer -&gt; OOPS

We dereference the pointer because cpu1 is still set in
tick_broadcast_force_mask and tick_do_broadcast() expects a valid
cpumask and therefor lacks any further checks.

Remove the cpu from the tick_broadcast_force_mask before we set the
tick device pointer to NULL. Also add a sanity check to the oneshot
broadcast function, so we can detect such issues w/o crashing the
machine.

Reported-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Cc: athorlton@sgi.com
Cc: CAI Qian &lt;caiqian@redhat.com&gt;
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1306261303260.4013@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Preeti U Murthy &lt;preeti@linux.vnet.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bio-integrity: Fix bio_integrity_verify segment start bug</title>
<updated>2014-03-24T04:38:21Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2014-01-22T04:32:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=68c52c3ef819b289473200e232bb940dbe87fc48'/>
<id>urn:sha1:68c52c3ef819b289473200e232bb940dbe87fc48</id>
<content type='text'>
commit 5837c80e870bc3b12ac6a98cdc9ce7a9522a8fb6 upstream.

This patch addresses a bug in bio_integrity_verify() code that has
been causing DIF READ verify operations to be silently skipped.

The issue is that bio-&gt;bi_idx will have been incremented within
bio_advance() code in the normal blk_update_request() -&gt;
req_bio_endio() completion path, and bio_integrity_verify() is
using bio_for_each_segment() which starts the bio segment walk
at the current bio-&gt;bi_idx.

So instead use bio_for_each_segment_all() to always start the bio
segment walk from zero, regardless of the current bio-&gt;bi_idx
value after bio_advance() has been called.

(Context change for v3.10.y -&gt; v3.13.y code - nab)

Cc: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


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