<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include, branch v4.14.34</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.34</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.34'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-04-12T10:32:17Z</updated>
<entry>
<title>net/mlx5: Fix race for multiple RoCE enable</title>
<updated>2018-04-12T10:32:17Z</updated>
<author>
<name>Daniel Jurgens</name>
<email>danielj@mellanox.com</email>
</author>
<published>2018-01-04T15:25:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=35a9ebd920aaaa6425436b6660e71ca831531da1'/>
<id>urn:sha1:35a9ebd920aaaa6425436b6660e71ca831531da1</id>
<content type='text'>
[ Upstream commit 734dc065fc41f6143ff88225aa5d335cb1e0f6aa ]

There are two potential problems with the existing implementation.

1. Enable and disable can race after the atomic operations.
2. If a command fails the refcount is left in an inconsistent state.

Introduce a lock and perform error checking.

Fixes: a6f7d2aff623 ("net/mlx5: Add support for multiple RoCE enable")
Signed-off-by: Daniel Jurgens &lt;danielj@mellanox.com&gt;
Reviewed-by: Parav Pandit &lt;parav@mellanox.com&gt;
Signed-off-by: Leon Romanovsky &lt;leon@kernel.org&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>clk: divider: fix incorrect usage of container_of</title>
<updated>2018-04-12T10:32:13Z</updated>
<author>
<name>Jerome Brunet</name>
<email>jbrunet@baylibre.com</email>
</author>
<published>2017-12-21T16:30:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e6bc3a4b0c23ed8d754692fa15ceb280e3facc51'/>
<id>urn:sha1:e6bc3a4b0c23ed8d754692fa15ceb280e3facc51</id>
<content type='text'>
[ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ]

divider_recalc_rate() is an helper function used by clock divider of
different types, so the structure containing the 'hw' pointer is not
always a 'struct clk_divider'

At the following line:
&gt; div = _get_div(table, val, flags, divider-&gt;width);

in several cases, the value of 'divider-&gt;width' is garbage as the actual
structure behind this memory is not a 'struct clk_divider'

Fortunately, this width value is used by _get_val() only when
CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
far when the structure is not a 'struct clk_divider'. This is probably
why we did not notice this bug before

Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
Signed-off-by: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
Acked-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Acked-by: Sylvain Lemieux &lt;slemieux.tyco@gmail.com&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: 8250: Add Nuvoton NPCM UART</title>
<updated>2018-04-08T12:26:30Z</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2018-03-05T11:47:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cbf733ca587c93aebb4f4aa721dba95a11725a69'/>
<id>urn:sha1:cbf733ca587c93aebb4f4aa721dba95a11725a69</id>
<content type='text'>
commit f597fbce38d230af95384f4a04e0a13a1d0ad45d upstream.

The Nuvoton UART is almost compatible with the 8250 driver when probed
via the 8250_of driver, however it requires some extra configuration
at startup.

Reviewed-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bitmap: fix memset optimization on big-endian systems</title>
<updated>2018-04-08T12:26:30Z</updated>
<author>
<name>Omar Sandoval</name>
<email>osandov@fb.com</email>
</author>
<published>2018-04-02T22:58:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ac5a36bb69570bc5bdd68f21c6793abc0b110cb7'/>
<id>urn:sha1:ac5a36bb69570bc5bdd68f21c6793abc0b110cb7</id>
<content type='text'>
commit 21035965f60b0502fc6537b232839389bb4ce664 upstream.

Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and
bitmap_clear into memset when possible") introduced an optimization to
bitmap_{set,clear}() which uses memset() when the start and length are
constants aligned to a byte.

This is wrong on big-endian systems; our bitmaps are arrays of unsigned
long, so bit n is not at byte n / 8 in memory.  This was caught by the
Btrfs selftests, but the bitmap selftests also fail when run on a
big-endian machine.

We can still use memset if the start and length are aligned to an
unsigned long, so do that on big-endian.  The same problem applies to
the memcmp in bitmap_equal(), so fix it there, too.

Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
Cc: stable@kernel.org
Reported-by: "Erhard F." &lt;erhard_f@mailbox.org&gt;
Cc: Matthew Wilcox &lt;mawilcox@microsoft.com&gt;
Cc: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Omar Sandoval &lt;osandov@fb.com&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>netfilter: x_tables: add and use xt_check_proc_name</title>
<updated>2018-04-08T12:26:29Z</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2018-03-10T00:15:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=839a4c3b4a48805af8d8fd84a203cd6b0e53105c'/>
<id>urn:sha1:839a4c3b4a48805af8d8fd84a203cd6b0e53105c</id>
<content type='text'>
commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.

recent and hashlimit both create /proc files, but only check that
name is 0 terminated.

This can trigger WARN() from procfs when name is "" or "/".
Add helper for this and then use it for both.

Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Reported-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Reported-by: &lt;syzbot+0502b00edac2a0680b61@syzkaller.appspotmail.com&gt;
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>RDMA/ucma: Introduce safer rdma_addr_size() variants</title>
<updated>2018-04-08T12:26:29Z</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2018-03-28T18:27:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b0d95e686f454c3af6a908707c2e047796ea4280'/>
<id>urn:sha1:b0d95e686f454c3af6a908707c2e047796ea4280</id>
<content type='text'>
commit 84652aefb347297aa08e91e283adf7b18f77c2d5 upstream.

There are several places in the ucma ABI where userspace can pass in a
sockaddr but set the address family to AF_IB.  When that happens,
rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
and the ucma kernel code might end up copying past the end of a buffer
not sized for a struct sockaddr_ib.

Fix this by introducing new variants

    int rdma_addr_size_in6(struct sockaddr_in6 *addr);
    int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);

that are type-safe for the types used in the ucma ABI and return 0 if the
size computed is bigger than the size of the type passed in.  We can use
these new variants to check what size userspace has passed in before
copying any addresses.

Reported-by: &lt;syzbot+6800425d54ed3ed8135d@syzkaller.appspotmail.com&gt;
Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net: use skb_to_full_sk() in skb_update_prio()</title>
<updated>2018-03-31T16:10:40Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2018-03-14T16:04:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4ff5078b0396960c69718a41f916f81a6c59b074'/>
<id>urn:sha1:4ff5078b0396960c69718a41f916f81a6c59b074</id>
<content type='text'>
[ Upstream commit 4dcb31d4649df36297296b819437709f5407059c ]

Andrei Vagin reported a KASAN: slab-out-of-bounds error in
skb_update_prio()

Since SYNACK might be attached to a request socket, we need to
get back to the listener socket.
Since this listener is manipulated without locks, add const
qualifiers to sock_cgroup_prioidx() so that the const can also
be used in skb_update_prio()

Also add the const qualifier to sock_cgroup_classid() for consistency.

Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Andrei Vagin &lt;avagin@virtuozzo.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>sch_netem: fix skb leak in netem_enqueue()</title>
<updated>2018-03-31T16:10:40Z</updated>
<author>
<name>Alexey Kodanev</name>
<email>alexey.kodanev@oracle.com</email>
</author>
<published>2018-03-05T17:52:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f77ff13a06c1185491169b78e33bfb6a169a933c'/>
<id>urn:sha1:f77ff13a06c1185491169b78e33bfb6a169a933c</id>
<content type='text'>
[ Upstream commit 35d889d10b649fda66121891ec05eca88150059d ]

When we exceed current packets limit and we have more than one
segment in the list returned by skb_gso_segment(), netem drops
only the first one, skipping the rest, hence kmemleak reports:

unreferenced object 0xffff880b5d23b600 (size 1024):
  comm "softirq", pid 0, jiffies 4384527763 (age 2770.629s)
  hex dump (first 32 bytes):
    00 80 23 5d 0b 88 ff ff 00 00 00 00 00 00 00 00  ..#]............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000d8a19b9d&gt;] __alloc_skb+0xc9/0x520
    [&lt;000000001709b32f&gt;] skb_segment+0x8c8/0x3710
    [&lt;00000000c7b9bb88&gt;] tcp_gso_segment+0x331/0x1830
    [&lt;00000000c921cba1&gt;] inet_gso_segment+0x476/0x1370
    [&lt;000000008b762dd4&gt;] skb_mac_gso_segment+0x1f9/0x510
    [&lt;000000002182660a&gt;] __skb_gso_segment+0x1dd/0x620
    [&lt;00000000412651b9&gt;] netem_enqueue+0x1536/0x2590 [sch_netem]
    [&lt;0000000005d3b2a9&gt;] __dev_queue_xmit+0x1167/0x2120
    [&lt;00000000fc5f7327&gt;] ip_finish_output2+0x998/0xf00
    [&lt;00000000d309e9d3&gt;] ip_output+0x1aa/0x2c0
    [&lt;000000007ecbd3a4&gt;] tcp_transmit_skb+0x18db/0x3670
    [&lt;0000000042d2a45f&gt;] tcp_write_xmit+0x4d4/0x58c0
    [&lt;0000000056a44199&gt;] tcp_tasklet_func+0x3d9/0x540
    [&lt;0000000013d06d02&gt;] tasklet_action+0x1ca/0x250
    [&lt;00000000fcde0b8b&gt;] __do_softirq+0x1b4/0x5a3
    [&lt;00000000e7ed027c&gt;] irq_exit+0x1e2/0x210

Fix it by adding the rest of the segments, if any, to skb 'to_free'
list. Add new __qdisc_drop_all() and qdisc_drop_all() functions
because they can be useful in the future if we need to drop segmented
GSO packets in other places.

Fixes: 6071bd1aa13e ("netem: Segment GSO packets on enqueue")
Signed-off-by: Alexey Kodanev &lt;alexey.kodanev@oracle.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.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>rhashtable: Fix rhlist duplicates insertion</title>
<updated>2018-03-31T16:10:40Z</updated>
<author>
<name>Paul Blakey</name>
<email>paulb@mellanox.com</email>
</author>
<published>2018-03-04T15:29:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=07cf9d303c7ce8620ea34e3407e08facf65c732d'/>
<id>urn:sha1:07cf9d303c7ce8620ea34e3407e08facf65c732d</id>
<content type='text'>
[ Upstream commit d3dcf8eb615537526bd42ff27a081d46d337816e ]

When inserting duplicate objects (those with the same key),
current rhlist implementation messes up the chain pointers by
updating the bucket pointer instead of prev next pointer to the
newly inserted node. This causes missing elements on removal and
travesal.

Fix that by properly updating pprev pointer to point to
the correct rhash_head next pointer.

Issue: 1241076
Change-Id: I86b2c140bcb4aeb10b70a72a267ff590bb2b17e7
Fixes: ca26893f05e8 ('rhashtable: Add rhlist interface')
Signed-off-by: Paul Blakey &lt;paulb@mellanox.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&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: phy: Tell caller result of phy_change()</title>
<updated>2018-03-31T16:10:39Z</updated>
<author>
<name>Brad Mouring</name>
<email>brad.mouring@ni.com</email>
</author>
<published>2018-03-08T22:23:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2274d77c36752d80e3bc91eb289c601c3f3795d9'/>
<id>urn:sha1:2274d77c36752d80e3bc91eb289c601c3f3795d9</id>
<content type='text'>
[ Upstream commit a2c054a896b8ac794ddcfc7c92e2dc7ec4ed4ed5 ]

In 664fcf123a30e (net: phy: Threaded interrupts allow some simplification)
the phy_interrupt system was changed to use a traditional threaded
interrupt scheme instead of a workqueue approach.

With this change, the phy status check moved into phy_change, which
did not report back to the caller whether or not the interrupt was
handled. This means that, in the case of a shared phy interrupt,
only the first phydev's interrupt registers are checked (since
phy_interrupt() would always return IRQ_HANDLED). This leads to
interrupt storms when it is a secondary device that's actually the
interrupt source.

Signed-off-by: Brad Mouring &lt;brad.mouring@ni.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>
