<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux, branch v4.9.14</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.14</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.14'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-03-12T05:41:52+00:00</updated>
<entry>
<title>mtd: nand: ifc: Fix location of eccstat registers for IFC V1.0</title>
<updated>2017-03-12T05:41:52+00:00</updated>
<author>
<name>Mark Marshall</name>
<email>mark.marshall@omicronenergy.com</email>
</author>
<published>2017-01-26T15:18:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9d82393e658cf7010b90a79d7c065e1766e5480c'/>
<id>urn:sha1:9d82393e658cf7010b90a79d7c065e1766e5480c</id>
<content type='text'>
commit 656441478ed55d960df5f3ccdf5a0f8c61dfd0b3 upstream.

The commit 7a654172161c ("mtd/ifc: Add support for IFC controller
version 2.0") added support for version 2.0 of the IFC controller.
The version 2.0 controller has the ECC status registers at a different
location to the previous versions.

Correct the fsl_ifc_nand structure so that the ECC status can be read
from the correct location for both version 1.0 and 2.0 of the controller.

Fixes: 7a654172161c ("mtd/ifc: Add support for IFC controller version 2.0")
Signed-off-by: Mark Marshall &lt;mark.marshall@omicronenergy.com&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Drivers: hv: vmbus: Fix a rescind handling bug</title>
<updated>2017-03-12T05:41:49+00:00</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2016-12-23T00:54:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=728fe696fd3ee551c24e02e7826dd9bdb89f1d47'/>
<id>urn:sha1:728fe696fd3ee551c24e02e7826dd9bdb89f1d47</id>
<content type='text'>
commit ccb61f8a99e6c29df4fb96a65dad4fad740d5be9 upstream.

The host can rescind a channel that has been offered to the
guest and once the channel is rescinded, the host does not
respond to any requests on that channel. Deal with the case where
the guest may be blocked waiting for a response from the host.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>PM / devfreq: Fix available_governor sysfs</title>
<updated>2017-03-12T05:41:44+00:00</updated>
<author>
<name>Chanwoo Choi</name>
<email>cw00.choi@samsung.com</email>
</author>
<published>2017-01-31T06:38:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2294b771a4b425d9365aabeaff8d33ccd0c0fffe'/>
<id>urn:sha1:2294b771a4b425d9365aabeaff8d33ccd0c0fffe</id>
<content type='text'>
commit bcf23c79c4e46130701370af4383b61a3cba755c upstream.

The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Signed-off-by: MyungJoo Ham &lt;myungjoo.ham@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sigaltstack: support SS_AUTODISARM for CONFIG_COMPAT</title>
<updated>2017-03-12T05:41:44+00:00</updated>
<author>
<name>Stas Sergeev</name>
<email>stsp@list.ru</email>
</author>
<published>2017-02-27T22:27:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6d94a6b32e97c56dfbe96cc489517b338608f091'/>
<id>urn:sha1:6d94a6b32e97c56dfbe96cc489517b338608f091</id>
<content type='text'>
commit 441398d378f29a5ad6d0fcda07918e54e4961800 upstream.

Currently SS_AUTODISARM is not supported in compatibility mode, but does
not return -EINVAL either.  This makes dosemu built with -m32 on x86_64
to crash.  Also the kernel's sigaltstack selftest fails if compiled with
-m32.

This patch adds the needed support.

Link: http://lkml.kernel.org/r/20170205101213.8163-2-stsp@list.ru
Signed-off-by: Stas Sergeev &lt;stsp@users.sourceforge.net&gt;
Cc: Milosz Tanski &lt;milosz@adfin.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Nicolas Pitre &lt;nicolas.pitre@linaro.org&gt;
Cc: Waiman Long &lt;Waiman.Long@hpe.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: Dmitry Safonov &lt;dsafonov@virtuozzo.com&gt;
Cc: Wang Xiaoqiang &lt;wangxq10@lzu.edu.cn&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm, vmscan: cleanup lru size claculations</title>
<updated>2017-03-12T05:41:43+00:00</updated>
<author>
<name>Michal Hocko</name>
<email>mhocko@suse.com</email>
</author>
<published>2017-02-22T23:45:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=710531320af876192d76b2c1f68190a1df941b02'/>
<id>urn:sha1:710531320af876192d76b2c1f68190a1df941b02</id>
<content type='text'>
commit fd538803731e50367b7c59ce4ad3454426a3d671 upstream.

lruvec_lru_size returns the full size of the LRU list while we sometimes
need a value reduced only to eligible zones (e.g.  for lowmem requests).
inactive_list_is_low is one such user.  Later patches will add more of
them.  Add a new parameter to lruvec_lru_size and allow it filter out
zones which are not eligible for the given context.

Link: http://lkml.kernel.org/r/20170117103702.28542-2-mhocko@kernel.org
Signed-off-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Acked-by: Hillf Danton &lt;hillf.zj@alibaba-inc.com&gt;
Acked-by: Minchan Kim &lt;minchan@kernel.org&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu</title>
<updated>2017-03-12T05:41:43+00:00</updated>
<author>
<name>CQ Tang</name>
<email>cq.tang@intel.com</email>
</author>
<published>2017-01-30T17:39:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=61cb3c6357fd77a2b1af49a9015955b9f82c68d4'/>
<id>urn:sha1:61cb3c6357fd77a2b1af49a9015955b9f82c68d4</id>
<content type='text'>
commit aaa59306b0b7e0ca4ba92cc04c5db101cbb1c096 upstream.

Some of the macros are incorrect with wrong bit-shifts resulting in picking
the incorrect invalidation granularity. Incorrect Source-ID in extended
devtlb invalidation caused device side errors.

To: Joerg Roedel &lt;joro@8bytes.org&gt;
To: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: iommu@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: CQ Tang &lt;cq.tang@intel.com&gt;
Cc: Ashok Raj &lt;ashok.raj@intel.com&gt;

Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support")
Signed-off-by: CQ Tang &lt;cq.tang@intel.com&gt;
Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Tested-by: CQ Tang &lt;cq.tang@intel.com&gt;
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ptr_ring: fix race conditions when resizing</title>
<updated>2017-02-26T10:10:51+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2017-02-19T05:17:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c56012e92b51030b13c4652a9494d422562d5d5'/>
<id>urn:sha1:7c56012e92b51030b13c4652a9494d422562d5d5</id>
<content type='text'>
[ Upstream commit e71695307114335be1ed912f4a347396c2ed0e69 ]

Resizing currently drops consumer lock.  This can cause entries to be
reordered, which isn't good in itself.  More importantly, consumer can
detect a false ring empty condition and block forever.

Further, nesting of consumer within producer lock is problematic for
tun, since it produces entries in a BH, which causes a lock order
reversal:

       CPU0                    CPU1
       ----                    ----
  consume:
  lock(&amp;(&amp;r-&gt;consumer_lock)-&gt;rlock);
                               resize:
                               local_irq_disable();
                               lock(&amp;(&amp;r-&gt;producer_lock)-&gt;rlock);
                               lock(&amp;(&amp;r-&gt;consumer_lock)-&gt;rlock);
  &lt;Interrupt&gt;
  produce:
  lock(&amp;(&amp;r-&gt;producer_lock)-&gt;rlock);

To fix, nest producer lock within consumer lock during resize,
and keep consumer lock during the whole swap operation.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: stable@vger.kernel.org
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Acked-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: introduce device min_header_len</title>
<updated>2017-02-18T14:11:43+00:00</updated>
<author>
<name>Willem de Bruijn</name>
<email>willemb@google.com</email>
</author>
<published>2017-02-07T20:57:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6ebde312a8ed469172fc9694ca0c8411994d47ff'/>
<id>urn:sha1:6ebde312a8ed469172fc9694ca0c8411994d47ff</id>
<content type='text'>
[ Upstream commit 217e6fa24ce28ec87fca8da93c9016cb78028612 ]

The stack must not pass packets to device drivers that are shorter
than the minimum link layer header length.

Previously, packet sockets would drop packets smaller than or equal
to dev-&gt;hard_header_len, but this has false positives. Zero length
payload is used over Ethernet. Other link layer protocols support
variable length headers. Support for validation of these protocols
removed the min length check for all protocols.

Introduce an explicit dev-&gt;min_header_len parameter and drop all
packets below this value. Initially, set it to non-zero only for
Ethernet and loopback. Other protocols can follow in a patch to
net-next.

Fixes: 9ed988cd5915 ("packet: validate variable length ll headers")
Reported-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>can: Fix kernel panic at security_sock_rcv_skb</title>
<updated>2017-02-18T14:11:40+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2017-01-27T16:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=adf86d59bb9b08d9eb67054251d29484c5ec102c'/>
<id>urn:sha1:adf86d59bb9b08d9eb67054251d29484c5ec102c</id>
<content type='text'>
[ Upstream commit f1712c73714088a7252d276a57126d56c7d37e64 ]

Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.

[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [&lt;ffffffff81495e25&gt;] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff81485d8c&gt;] security_sock_rcv_skb+0x4c/0x60
 [&lt;ffffffff81d55771&gt;] sk_filter+0x41/0x210
 [&lt;ffffffff81d12913&gt;] sock_queue_rcv_skb+0x53/0x3a0
 [&lt;ffffffff81f0a2b3&gt;] raw_rcv+0x2a3/0x3c0
 [&lt;ffffffff81f06eab&gt;] can_rcv_filter+0x12b/0x370
 [&lt;ffffffff81f07af9&gt;] can_receive+0xd9/0x120
 [&lt;ffffffff81f07beb&gt;] can_rcv+0xab/0x100
 [&lt;ffffffff81d362ac&gt;] __netif_receive_skb_core+0xd8c/0x11f0
 [&lt;ffffffff81d36734&gt;] __netif_receive_skb+0x24/0xb0
 [&lt;ffffffff81d37f67&gt;] process_backlog+0x127/0x280
 [&lt;ffffffff81d36f7b&gt;] net_rx_action+0x33b/0x4f0
 [&lt;ffffffff810c88d4&gt;] __do_softirq+0x184/0x440
 [&lt;ffffffff81f9e86c&gt;] do_softirq_own_stack+0x1c/0x30
 &lt;EOI&gt;
 [&lt;ffffffff810c76fb&gt;] do_softirq.part.18+0x3b/0x40
 [&lt;ffffffff810c8bed&gt;] do_softirq+0x1d/0x20
 [&lt;ffffffff81d30085&gt;] netif_rx_ni+0xe5/0x110
 [&lt;ffffffff8199cc87&gt;] slcan_receive_buf+0x507/0x520
 [&lt;ffffffff8167ef7c&gt;] flush_to_ldisc+0x21c/0x230
 [&lt;ffffffff810e3baf&gt;] process_one_work+0x24f/0x670
 [&lt;ffffffff810e44ed&gt;] worker_thread+0x9d/0x6f0
 [&lt;ffffffff810e4450&gt;] ? rescuer_thread+0x480/0x480
 [&lt;ffffffff810ebafc&gt;] kthread+0x12c/0x150
 [&lt;ffffffff81f9ccef&gt;] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin &lt;yanmin.zhang@intel.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()</title>
<updated>2017-02-14T23:25:39+00:00</updated>
<author>
<name>Dexuan Cui</name>
<email>decui@microsoft.com</email>
</author>
<published>2017-01-28T18:46:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1cf897fcc5a99e5ecf2f6fb12adec6d485a17e14'/>
<id>urn:sha1:1cf897fcc5a99e5ecf2f6fb12adec6d485a17e14</id>
<content type='text'>
commit 433e19cf33d34bb6751c874a9c00980552fe508c upstream.

Commit a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
hv_need_to_signal_on_read()")
added the proper mb(), but removed the test "prev_write_sz &lt; pending_sz"
when making the signal decision.

As a result, the guest can signal the host unnecessarily,
and then the host can throttle the guest because the host
thinks the guest is buggy or malicious; finally the user
running stress test can perceive intermittent freeze of
the guest.

This patch brings back the test, and properly handles the
in-place consumption APIs used by NetVSC (see get_next_pkt_raw(),
put_pkt_raw() and commit_rd_index()).

Fixes: a389fcfd2cb5 ("Drivers: hv: vmbus: Fix signaling logic in
hv_need_to_signal_on_read()")

Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Reported-by: Rolf Neugebauer &lt;rolf.neugebauer@docker.com&gt;
Tested-by: Rolf Neugebauer &lt;rolf.neugebauer@docker.com&gt;
Cc: "K. Y. Srinivasan" &lt;kys@microsoft.com&gt;
Cc: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
Cc: Stephen Hemminger &lt;sthemmin@microsoft.com&gt;
Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Cc: Rolf Neugebauer &lt;rolf.neugebauer@docker.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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