<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/net/ethernet, branch dev-5.2</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.2</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2019-09-10T13:43:25+00:00</updated>
<entry>
<title>Merge tag 'v5.2.14' into dev-5.2</title>
<updated>2019-09-10T13:43:25+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2019-09-10T13:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=386b5f6527184764f25f0b0f9ad4c0157ca99ea3'/>
<id>urn:sha1:386b5f6527184764f25f0b0f9ad4c0157ca99ea3</id>
<content type='text'>
This is the 5.2.14 stable release

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>ravb: Fix use-after-free ravb_tstamp_skb</title>
<updated>2019-09-10T09:35:19+00:00</updated>
<author>
<name>Tho Vu</name>
<email>tho.vu.wh@rvc.renesas.com</email>
</author>
<published>2019-08-16T15:17:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=086ddc5e71721ce385382e926b8112148c2ad58a'/>
<id>urn:sha1:086ddc5e71721ce385382e926b8112148c2ad58a</id>
<content type='text'>
[ Upstream commit cfef46d692efd852a0da6803f920cc756eea2855 ]

When a Tx timestamp is requested, a pointer to the skb is stored in the
ravb_tstamp_skb struct. This was done without an skb_get. There exists
the possibility that the skb could be freed by ravb_tx_free (when
ravb_tx_free is called from ravb_start_xmit) before the timestamp was
processed, leading to a use-after-free bug.

Use skb_get when filling a ravb_tstamp_skb struct, and add appropriate
frees/consumes when a ravb_tstamp_skb struct is freed.

Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Tho Vu &lt;tho.vu.wh@rvc.renesas.com&gt;
Signed-off-by: Kazuya Mizuguchi &lt;kazuya.mizuguchi.ks@renesas.com&gt;
Signed-off-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: cavium: fix driver name</title>
<updated>2019-09-10T09:35:19+00:00</updated>
<author>
<name>Stephen Hemminger</name>
<email>stephen@networkplumber.org</email>
</author>
<published>2019-08-15T19:49:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=461f5b613b4d3d890eb83f6773d93298220d3a43'/>
<id>urn:sha1:461f5b613b4d3d890eb83f6773d93298220d3a43</id>
<content type='text'>
[ Upstream commit 3434341004a380f4e47c3a03d4320d43982162a0 ]

The driver name gets exposed in sysfs under /sys/bus/pci/drivers
so it should look like other devices. Change it to be common
format (instead of "Cavium PTP").

This is a trivial fix that was observed by accident because
Debian kernels were building this driver into kernel (bug).

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ibmvnic: Unmap DMA address of TX descriptor buffers after use</title>
<updated>2019-09-10T09:35:18+00:00</updated>
<author>
<name>Thomas Falcon</name>
<email>tlfalcon@linux.ibm.com</email>
</author>
<published>2019-08-14T19:57:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1915dd1826be7a7f538945b87b655629272fc9ef'/>
<id>urn:sha1:1915dd1826be7a7f538945b87b655629272fc9ef</id>
<content type='text'>
[ Upstream commit 80f0fe0934cd3daa13a5e4d48a103f469115b160 ]

There's no need to wait until a completion is received to unmap
TX descriptor buffers that have been passed to the hypervisor.
Instead unmap it when the hypervisor call has completed. This patch
avoids the possibility that a buffer will not be unmapped because
a TX completion is lost or mishandled.

Reported-by: Abdul Haleem &lt;abdhalee@linux.vnet.ibm.com&gt;
Tested-by: Devesh K. Singh &lt;devesh_singh@in.ibm.com&gt;
Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: myri10ge: fix memory leaks</title>
<updated>2019-09-10T09:35:17+00:00</updated>
<author>
<name>Wenwen Wang</name>
<email>wenwen@cs.uga.edu</email>
</author>
<published>2019-08-14T06:38:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=7da16490e5a5dc596ae17062f93fe273c86e556d'/>
<id>urn:sha1:7da16490e5a5dc596ae17062f93fe273c86e556d</id>
<content type='text'>
[ Upstream commit 20fb7c7a39b5c719e2e619673b5f5729ee7d2306 ]

In myri10ge_probe(), myri10ge_alloc_slices() is invoked to allocate slices
related structures. Later on, myri10ge_request_irq() is used to get an irq.
However, if this process fails, the allocated slices related structures are
not deallocated, leading to memory leaks. To fix this issue, revise the
target label of the goto statement to 'abort_with_slices'.

Signed-off-by: Wenwen Wang &lt;wenwen@cs.uga.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>liquidio: add cleanup in octeon_setup_iq()</title>
<updated>2019-09-10T09:35:17+00:00</updated>
<author>
<name>Wenwen Wang</name>
<email>wenwen@cs.uga.edu</email>
</author>
<published>2019-08-14T05:14:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0f1c537cf09c687b57c15ce5e9309b7103592a38'/>
<id>urn:sha1:0f1c537cf09c687b57c15ce5e9309b7103592a38</id>
<content type='text'>
[ Upstream commit 6f967f8b1be7001b31c46429f2ee7d275af2190f ]

If oct-&gt;fn_list.enable_io_queues() fails, no cleanup is executed, leading
to memory/resource leaks. To fix this issue, invoke
octeon_delete_instr_queue() before returning from the function.

Signed-off-by: Wenwen Wang &lt;wenwen@cs.uga.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cxgb4: fix a memory leak bug</title>
<updated>2019-09-10T09:35:16+00:00</updated>
<author>
<name>Wenwen Wang</name>
<email>wenwen@cs.uga.edu</email>
</author>
<published>2019-08-13T09:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bf31a46ead594390566032fae80fd1f66485bd68'/>
<id>urn:sha1:bf31a46ead594390566032fae80fd1f66485bd68</id>
<content type='text'>
[ Upstream commit c554336efa9bbc28d6ec14efbee3c7d63c61a34f ]

In blocked_fl_write(), 't' is not deallocated if bitmap_parse_user() fails,
leading to a memory leak bug. To fix this issue, free t before returning
the error.

Signed-off-by: Wenwen Wang &lt;wenwen@cs.uga.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ibmveth: Convert multicast list size for little-endian system</title>
<updated>2019-09-10T09:35:14+00:00</updated>
<author>
<name>Thomas Falcon</name>
<email>tlfalcon@linux.ibm.com</email>
</author>
<published>2019-08-12T21:13:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f6bd80bc62231a281b757059f8a7b1d8663d586a'/>
<id>urn:sha1:f6bd80bc62231a281b757059f8a7b1d8663d586a</id>
<content type='text'>
[ Upstream commit 66cf4710b23ab2adda11155684a2c8826f4fe732 ]

The ibm,mac-address-filters property defines the maximum number of
addresses the hypervisor's multicast filter list can support. It is
encoded as a big-endian integer in the OF device tree, but the virtual
ethernet driver does not convert it for use by little-endian systems.
As a result, the driver is not behaving as it should on affected systems
when a large number of multicast addresses are assigned to the device.

Reported-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Signed-off-by: Thomas Falcon &lt;tlfalcon@linux.ibm.com&gt;
Signed-off-by: Jakub Kicinski &lt;jakub.kicinski@netronome.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx</title>
<updated>2019-09-10T09:35:14+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>natechancellor@gmail.com</email>
</author>
<published>2019-08-12T03:13:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ab0f749707eadafe0b8ad9e3efb53f4aaf956599'/>
<id>urn:sha1:ab0f749707eadafe0b8ad9e3efb53f4aaf956599</id>
<content type='text'>
[ Upstream commit 125b7e0949d4e72b15c2b1a1590f8cece985a918 ]

clang warns:

drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
'&amp;&amp;' with constant operand [-Wconstant-logical-operand]
                        if (!HAVE_DMA_RXALIGN(lp) &amp;&amp; NET_IP_ALIGN)
                                                  ^  ~~~~~~~~~~~~
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&amp;' for a
bitwise operation
                        if (!HAVE_DMA_RXALIGN(lp) &amp;&amp; NET_IP_ALIGN)
                                                  ^~
                                                  &amp;
drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
silence this warning
                        if (!HAVE_DMA_RXALIGN(lp) &amp;&amp; NET_IP_ALIGN)
                                                 ~^~~~~~~~~~~~~~~
1 warning generated.

Explicitly check that NET_IP_ALIGN is not zero, which matches how this
is checked in other parts of the tree. Because NET_IP_ALIGN is a build
time constant, this check will be constant folded away during
optimization.

Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
Link: https://github.com/ClangBuiltLinux/linux/issues/608
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ixgbe: fix possible deadlock in ixgbe_service_task()</title>
<updated>2019-09-10T09:35:13+00:00</updated>
<author>
<name>Taehee Yoo</name>
<email>ap420073@gmail.com</email>
</author>
<published>2019-08-08T16:37:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=936315c0c94e2659ad48899e11da83c33f58bfe0'/>
<id>urn:sha1:936315c0c94e2659ad48899e11da83c33f58bfe0</id>
<content type='text'>
[ Upstream commit 8b6381600d59871fbe44d36522272f961ab42410 ]

ixgbe_service_task() calls unregister_netdev() under rtnl_lock().
But unregister_netdev() internally calls rtnl_lock().
So deadlock would occur.

Fixes: 59dd45d550c5 ("ixgbe: firmware recovery mode")
Signed-off-by: Taehee Yoo &lt;ap420073@gmail.com&gt;
Tested-by: Andrew Bowers &lt;andrewx.bowers@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
