<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include, branch v4.13.10</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.13.10</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.13.10'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-10-27T08:39:15Z</updated>
<entry>
<title>ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal</title>
<updated>2017-10-27T08:39:15Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-16T09:39:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=82d745a55779171d51eb4ce534a11e958ebd7b58'/>
<id>urn:sha1:82d745a55779171d51eb4ce534a11e958ebd7b58</id>
<content type='text'>
commit a91d66129fb9bcead12af3ed2008d6ddbf179509 upstream.

The commit 99b5c5bb9a54 ("ALSA: hda - Remove the use of set_fs()")
converted the get_kctl_0dB_offset() call for killing set_fs() usage in
HD-audio codec code.  The conversion assumed that the TLV callback
used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV
calculation locally.

Although this assumption is correct, and all slave kctls are actually
with that callback, the current code is still utterly buggy; it
doesn't hit this condition and falls back to the next check.  It's
because the function gets called after adding slave kctls to vmaster.
By assigning a slave kctl, the slave kctl object is faked inside
vmaster code, and the whole kctl ops are overridden.  Thus the
callback op points to a different value from what we've assumed.

More badly, as reported by the KERNEXEC and UDEREF features of PaX,
the code flow turns into the unexpected pitfall.  The next fallback
check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always
hits for each kctl with TLV.  Then it evaluates the callback function
pointer wrongly as if it were a TLV array.  Although currently its
side-effect is fairly limited, this incorrect reference may lead to an
unpleasant result.

For addressing the regression, this patch introduces a new helper to
vmaster code, snd_ctl_apply_vmaster_slaves().  This works similarly
like the existing map_slaves() in hda_codec.c: it loops over the slave
list of the given master, and applies the given function to each
slave.  Then the initializer function receives the right kctl object
and we can compare the correct pointer instead of the faked one.

Also, for catching the similar breakage in future, give an error
message when the unexpected TLV callback is found and bail out
immediately.

Fixes: 99b5c5bb9a54 ("ALSA: hda - Remove the use of set_fs()")
Reported-by: PaX Team &lt;pageexec@freemail.hu&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KEYS: Fix race between updating and finding a negative key</title>
<updated>2017-10-27T08:39:15Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2017-10-04T15:43:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f45b8fe12221c178ce708b1c9d634634f2261802'/>
<id>urn:sha1:f45b8fe12221c178ce708b1c9d634634f2261802</id>
<content type='text'>
commit 363b02dab09b3226f3bd1420dad9c72b79a42a76 upstream.

Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
error into one field such that:

 (1) The instantiation state can be modified/read atomically.

 (2) The error can be accessed atomically with the state.

 (3) The error isn't stored unioned with the payload pointers.

This deals with the problem that the state is spread over three different
objects (two bits and a separate variable) and reading or updating them
atomically isn't practical, given that not only can uninstantiated keys
change into instantiated or rejected keys, but rejected keys can also turn
into instantiated keys - and someone accessing the key might not be using
any locking.

The main side effect of this problem is that what was held in the payload
may change, depending on the state.  For instance, you might observe the
key to be in the rejected state.  You then read the cached error, but if
the key semaphore wasn't locked, the key might've become instantiated
between the two reads - and you might now have something in hand that isn't
actually an error code.

The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
code if the key is negatively instantiated.  The key_is_instantiated()
function is replaced with key_is_positive() to avoid confusion as negative
keys are also 'instantiated'.

Additionally, barriering is included:

 (1) Order payload-set before state-set during instantiation.

 (2) Order state-read before payload-read when using the key.

Further separate barriering is necessary if RCU is being used to access the
payload content after reading the payload pointers.

Fixes: 146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
Reported-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bus: mbus: fix window size calculation for 4GB windows</title>
<updated>2017-10-27T08:39:14Z</updated>
<author>
<name>Jan Luebbe</name>
<email>jlu@pengutronix.de</email>
</author>
<published>2017-08-28T15:25:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=59a33c5b7290ba0cd9cd4f136d9cc452b7559a7f'/>
<id>urn:sha1:59a33c5b7290ba0cd9cd4f136d9cc452b7559a7f</id>
<content type='text'>
commit 2bbbd96357ce76cc45ec722c00f654aa7b189112 upstream.

At least the Armada XP SoC supports 4GB on a single DRAM window. Because
the size register values contain the actual size - 1, the MSB is set in
that case. For example, the SDRAM window's control register's value is
0xffffffe1 for 4GB (bits 31 to 24 contain the size).

The MBUS driver reads back each window's size from registers and
calculates the actual size as (control_reg | ~DDR_SIZE_MASK) + 1, which
overflows for 32 bit values, resulting in other miscalculations further
on (a bad RAM window for the CESA crypto engine calculated by
mvebu_mbus_setup_cpu_target_nooverlap() in my case).

This patch changes the type in 'struct mbus_dram_window' from u32 to
u64, which allows us to keep using the same register calculation code in
most MBUS-using drivers (which calculate -&gt;size - 1 again).

Fixes: fddddb52a6c4 ("bus: introduce an Marvell EBU MBus driver")
Signed-off-by: Jan Luebbe &lt;jlu@pengutronix.de&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vmbus: eliminate duplicate cached index</title>
<updated>2017-10-21T15:55:07Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>stephen@networkplumber.org</email>
</author>
<published>2017-06-25T19:30:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=27ba39f28808d6e983ad028da15952f29918a6c4'/>
<id>urn:sha1:27ba39f28808d6e983ad028da15952f29918a6c4</id>
<content type='text'>
commit 05d00bc94ac27d220d8a78e365d7fa3a26dcca17 upstream.

Don't need cached read index anymore now that packet iterator
is used. The iterator has the original read index until the
visible read_index is updated.

Signed-off-by: Stephen Hemminger &lt;sthemmin@microsoft.com&gt;
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>vmbus: refactor hv_signal_on_read</title>
<updated>2017-10-21T15:55:07Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>stephen@networkplumber.org</email>
</author>
<published>2017-06-25T19:30:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=df95afa5960b806835f2fa4d167a828d9329ba87'/>
<id>urn:sha1:df95afa5960b806835f2fa4d167a828d9329ba87</id>
<content type='text'>
commit 8dd45f2ab005a1f3301296059b23b03ec3dbf79b upstream.

The function hv_signal_on_read was defined in hyperv.h and
only used in one place in ring_buffer code. Clearer to just
move it inline there.

Signed-off-by: Stephen Hemminger &lt;sthemmin@microsoft.com&gt;
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>Drivers: hv: vmbus: Fix bugs in rescind handling</title>
<updated>2017-10-21T15:55:06Z</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2017-09-30T04:09:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0cd8b4745ce2576daade5343dd270d36c3547a72'/>
<id>urn:sha1:0cd8b4745ce2576daade5343dd270d36c3547a72</id>
<content type='text'>
commit 192b2d78722ffea188e5ec6ae5d55010dce05a4b upstream.

This patch addresses the following bugs in the current rescind handling code:

1. Fixes a race condition where we may be invoking hv_process_channel_removal()
on an already freed channel.

2. Prevents indefinite wait when rescinding sub-channels by correctly setting
the probe_complete state.

I would like to thank Dexuan for patiently reviewing earlier versions of this
patch and identifying many of the issues fixed here.

Greg, please apply this to 4.14-final.

Fixes: '54a66265d675 ("Drivers: hv: vmbus: Fix rescind handling")'

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

</content>
</entry>
<entry>
<title>Drivers: hv: vmbus: Fix rescind handling issues</title>
<updated>2017-10-21T15:55:06Z</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2017-08-11T17:03:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6b32d45bd59982751beb8220e442b40b2706647f'/>
<id>urn:sha1:6b32d45bd59982751beb8220e442b40b2706647f</id>
<content type='text'>
commit 6f3d791f300618caf82a2be0c27456edd76d5164 upstream.

This patch handles the following issues that were observed when we are
handling racing channel offer message and rescind message for the same
offer:

1. Since the host does not respond to messages on a rescinded channel,
in the current code, we could be indefinitely blocked on the vmbus_open() call.

2. When a rescinded channel is being closed, if there is a pending interrupt on the
channel, we could end up freeing the channel that the interrupt handler would run on.

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

</content>
</entry>
<entry>
<title>ALSA: seq: Fix copy_from_user() call inside lock</title>
<updated>2017-10-18T07:38:29Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-09T08:02:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ff021a7e03917ed526ce3cd321697b709a5c822f'/>
<id>urn:sha1:ff021a7e03917ed526ce3cd321697b709a5c822f</id>
<content type='text'>
commit 5803b023881857db32ffefa0d269c90280a67ee0 upstream.

The event handler in the virmidi sequencer code takes a read-lock for
the linked list traverse, while it's calling snd_seq_dump_var_event()
in the loop.  The latter function may expand the user-space data
depending on the event type.  It eventually invokes copy_from_user(),
which might be a potential dead-lock.

The sequencer core guarantees that the user-space data is passed only
with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it
and always takes read-lock().  For avoiding the problem above, this
patch introduces rwsem for non-atomic case, while keeping rwlock for
atomic case.

Also while we're at it: the superfluous irq flags is dropped in
snd_virmidi_input_open().

Reported-by: Jia-Ju Bai &lt;baijiaju1990@163.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fs/mpage.c: fix mpage_writepage() for pages with buffers</title>
<updated>2017-10-18T07:38:29Z</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@infradead.org</email>
</author>
<published>2017-10-13T22:58:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=936edc5ed9976c728ee91967ba099d84e6fb78e7'/>
<id>urn:sha1:936edc5ed9976c728ee91967ba099d84e6fb78e7</id>
<content type='text'>
commit f892760aa66a2d657deaf59538fb69433036767c upstream.

When using FAT on a block device which supports rw_page, we can hit
BUG_ON(!PageLocked(page)) in try_to_free_buffers().  This is because we
call clean_buffers() after unlocking the page we've written.  Introduce
a new clean_page_buffers() which cleans all buffers associated with a
page and call it from within bdev_write_page().

[akpm@linux-foundation.org: s/PAGE_SIZE/~0U/ per Linus and Matthew]
Link: http://lkml.kernel.org/r/20171006211541.GA7409@bombadil.infradead.org
Signed-off-by: Matthew Wilcox &lt;mawilcox@microsoft.com&gt;
Reported-by: Toshi Kani &lt;toshi.kani@hpe.com&gt;
Reported-by: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Tested-by: Toshi Kani &lt;toshi.kani@hpe.com&gt;
Acked-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Cc: Ross Zwisler &lt;ross.zwisler@linux.intel.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>udp: perform source validation for mcast early demux</title>
<updated>2017-10-12T09:56:19Z</updated>
<author>
<name>Paolo Abeni</name>
<email>pabeni@redhat.com</email>
</author>
<published>2017-09-28T13:51:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f8a055eadfd437689a6bf8749d5fef37ae242bfe'/>
<id>urn:sha1:f8a055eadfd437689a6bf8749d5fef37ae242bfe</id>
<content type='text'>
[ Upstream commit bc044e8db7962e727a75b591b9851ff2ac5cf846 ]

The UDP early demux can leverate the rx dst cache even for
multicast unconnected sockets.

In such scenario the ipv4 source address is validated only on
the first packet in the given flow. After that, when we fetch
the dst entry  from the socket rx cache, we stop enforcing
the rp_filter and we even start accepting any kind of martian
addresses.

Disabling the dst cache for unconnected multicast socket will
cause large performace regression, nearly reducing by half the
max ingress tput.

Instead we factor out a route helper to completely validate an
skb source address for multicast packets and we call it from
the UDP early demux for mcast packets landing on unconnected
sockets, after successful fetching the related cached dst entry.

This still gives a measurable, but limited performance
regression:

		rp_filter = 0		rp_filter = 1
edmux disabled:	1182 Kpps		1127 Kpps
edmux before:	2238 Kpps		2238 Kpps
edmux after:	2037 Kpps		2019 Kpps

The above figures are on top of current net tree.
Applying the net-next commit 6e617de84e87 ("net: avoid a full
fib lookup when rp_filter is disabled.") the delta with
rp_filter == 0 will decrease even more.

Fixes: 421b3885bf6d ("udp: ipv4: Add udp early demux")
Signed-off-by: Paolo Abeni &lt;pabeni@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>
</feed>
