<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net, branch v5.4.113</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.113</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.113'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-04-14T06:24:18+00:00</updated>
<entry>
<title>drivers: net: fix memory leak in peak_usb_create_dev</title>
<updated>2021-04-14T06:24:18+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-04-01T13:27:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e7098f56c83cb7427f807b9382244f25f033eee'/>
<id>urn:sha1:6e7098f56c83cb7427f807b9382244f25f033eee</id>
<content type='text'>
commit a0b96b4a62745397aee662670cfc2157bac03f55 upstream.

syzbot reported memory leak in peak_usb.
The problem was in case of failure after calling
-&gt;dev_init()[2] in peak_usb_create_dev()[1]. The data
allocated int dev_init() wasn't freed, so simple
-&gt;dev_free() call fix this problem.

backtrace:
    [&lt;0000000079d6542a&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;0000000079d6542a&gt;] kzalloc include/linux/slab.h:682 [inline]
    [&lt;0000000079d6542a&gt;] pcan_usb_fd_init+0x156/0x210 drivers/net/can/usb/peak_usb/pcan_usb_fd.c:868   [2]
    [&lt;00000000c09f9057&gt;] peak_usb_create_dev drivers/net/can/usb/peak_usb/pcan_usb_core.c:851 [inline] [1]
    [&lt;00000000c09f9057&gt;] peak_usb_probe+0x389/0x490 drivers/net/can/usb/peak_usb/pcan_usb_core.c:949

Reported-by: syzbot+91adee8d9ebb9193d22d@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.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>drivers: net: fix memory leak in atusb_probe</title>
<updated>2021-04-14T06:24:18+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-04-01T04:46:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32e2f9a708e1c01c95302b005550223098089638'/>
<id>urn:sha1:32e2f9a708e1c01c95302b005550223098089638</id>
<content type='text'>
commit 6b9fbe16955152626557ec6f439f3407b7769941 upstream.

syzbot reported memory leak in atusb_probe()[1].
The problem was in atusb_alloc_urbs().
Since urb is anchored, we need to release the reference
to correctly free the urb

backtrace:
    [&lt;ffffffff82ba0466&gt;] kmalloc include/linux/slab.h:559 [inline]
    [&lt;ffffffff82ba0466&gt;] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74
    [&lt;ffffffff82ad3888&gt;] atusb_alloc_urbs drivers/net/ieee802154/atusb.c:362 [inline][2]
    [&lt;ffffffff82ad3888&gt;] atusb_probe+0x158/0x820 drivers/net/ieee802154/atusb.c:1038 [1]

Reported-by: syzbot+28a246747e0a465127f3@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.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: tun: set tun-&gt;dev-&gt;addr_len during TUNSETLINK processing</title>
<updated>2021-04-14T06:24:18+00:00</updated>
<author>
<name>Phillip Potter</name>
<email>phil@philpotter.co.uk</email>
</author>
<published>2021-04-06T17:45:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0a790ad1358b5fffece1ae05d45a9d5f2d3446e7'/>
<id>urn:sha1:0a790ad1358b5fffece1ae05d45a9d5f2d3446e7</id>
<content type='text'>
commit cca8ea3b05c972ffb5295367e6c544369b45fbdd upstream.

When changing type with TUNSETLINK ioctl command, set tun-&gt;dev-&gt;addr_len
to match the appropriate type, using new tun_get_addr_len utility function
which returns appropriate address length for given type. Fixes a
KMSAN-found uninit-value bug reported by syzbot at:
https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51

Reported-by: syzbot+001516d86dbe88862cec@syzkaller.appspotmail.com
Diagnosed-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Phillip Potter &lt;phil@philpotter.co.uk&gt;
Reviewed-by: Eric Dumazet &lt;edumazet@google.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: hns3: clear VF down state bit before request link status</title>
<updated>2021-04-14T06:24:17+00:00</updated>
<author>
<name>Guangbin Huang</name>
<email>huangguangbin2@huawei.com</email>
</author>
<published>2021-04-06T13:10:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9716aac1741970f299c0b1680c29baf90d2630ce'/>
<id>urn:sha1:9716aac1741970f299c0b1680c29baf90d2630ce</id>
<content type='text'>
[ Upstream commit ed7bedd2c3ca040f1e8ea02c6590a93116b1ec78 ]

Currently, the VF down state bit is cleared after VF sending
link status request command. There is problem that when VF gets
link status replied from PF, the down state bit may still set
as 1. In this case, the link status replied from PF will be
ignored and always set VF link status to down.

To fix this problem, clear VF down state bit before VF requests
link status.

Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
Signed-off-by: Guangbin Huang &lt;huangguangbin2@huawei.com&gt;
Signed-off-by: Huazhong Tan &lt;tanhuazhong@huawei.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: macb: restore cmp registers on resume path</title>
<updated>2021-04-14T06:24:16+00:00</updated>
<author>
<name>Claudiu Beznea</name>
<email>claudiu.beznea@microchip.com</email>
</author>
<published>2021-04-02T12:42:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3717885865c6d07d5b541a62958b46120e7646d'/>
<id>urn:sha1:b3717885865c6d07d5b541a62958b46120e7646d</id>
<content type='text'>
[ Upstream commit a14d273ba15968495896a38b7b3399dba66d0270 ]

Restore CMP screener registers on resume path.

Fixes: c1e85c6ce57ef ("net: macb: save/restore the remaining registers and features")
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@microchip.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>i40e: Fix display statistics for veb_tc</title>
<updated>2021-04-14T06:24:16+00:00</updated>
<author>
<name>Eryk Rybak</name>
<email>eryk.roch.rybak@intel.com</email>
</author>
<published>2021-03-02T07:46:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e22ce1d21b42a9232c1faf38c03be30a6d7984b8'/>
<id>urn:sha1:e22ce1d21b42a9232c1faf38c03be30a6d7984b8</id>
<content type='text'>
[ Upstream commit c3214de929dbf1b7374add8bbed30ce82b197bbb ]

If veb-stats was enabled, the ethtool stats triggered a warning
due to invalid size: 'unexpected stat size for veb.tc_%u_tx_packets'.
This was due to an incorrect structure definition for the statistics.
Structures and functions have been improved in line with requirements
for the presentation of statistics, in particular for the functions:
'i40e_add_ethtool_stats' and 'i40e_add_stat_strings'.

Fixes: 1510ae0be2a4 ("i40e: convert VEB TC stats to use an i40e_stats array")
Signed-off-by: Eryk Rybak &lt;eryk.roch.rybak@intel.com&gt;
Signed-off-by: Grzegorz Szczurek &lt;grzegorzx.szczurek@intel.com&gt;
Reviewed-by: Aleksandr Loktionov &lt;aleksandr.loktionov@intel.com&gt;
Tested-by: Dave Switzer &lt;david.switzer@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Don't request more than supported EQs</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Daniel Jurgens</name>
<email>danielj@mellanox.com</email>
</author>
<published>2019-12-05T22:58:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=73f88cc2bf5c1385bfe20169572fdb4c8a8f12df'/>
<id>urn:sha1:73f88cc2bf5c1385bfe20169572fdb4c8a8f12df</id>
<content type='text'>
[ Upstream commit a7b76002ae78cd230ee652ccdfedf21aa94fcecc ]

Calculating the number of compeltion EQs based on the number of
available IRQ vectors doesn't work now that all async EQs share one IRQ.
Thus the max number of EQs can be exceeded on systems with more than
approximately 256 CPUs. Take this into account when calculating the
number of available completion EQs.

Fixes: 81bfa206032a ("net/mlx5: Use a single IRQ for all async EQs")
Signed-off-by: Daniel Jurgens &lt;danielj@mellanox.com&gt;
Reviewed-by: Parav Pandit &lt;parav@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5e: Fix ethtool indication of connector type</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Aya Levin</name>
<email>ayal@nvidia.com</email>
</author>
<published>2021-03-24T10:25:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=029416e14be2276cca6d1d46b09129f044646308'/>
<id>urn:sha1:029416e14be2276cca6d1d46b09129f044646308</id>
<content type='text'>
[ Upstream commit 3211434dfe7a66fcf55e43961ea524b78336c04c ]

Use connector_type read from PTYS register when it's valid, based on
corresponding capability bit.

Fixes: 5b4793f81745 ("net/mlx5e: Add support for reading connector type from PTYS")
Signed-off-by: Aya Levin &lt;ayal@nvidia.com&gt;
Reviewed-by: Eran Ben Elisha &lt;eranbe@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: broadcom: Only advertise EEE for supported modes</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2021-03-30T22:00:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=db4600aa938c471f17baa211618ec9f9ab673676'/>
<id>urn:sha1:db4600aa938c471f17baa211618ec9f9ab673676</id>
<content type='text'>
[ Upstream commit c056d480b40a68f2520ccc156c7fae672d69d57d ]

We should not be advertising EEE for modes that we do not support,
correct that oversight by looking at the PHY device supported linkmodes.

Fixes: 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE")
Signed-off-by: Florian Fainelli &lt;f.fainelli@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>nfp: flower: ignore duplicate merge hints from FW</title>
<updated>2021-04-14T06:24:15+00:00</updated>
<author>
<name>Yinjun Zhang</name>
<email>yinjun.zhang@corigine.com</email>
</author>
<published>2021-03-30T08:30:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6aa7d2621b19da344ebcc56b2e00601c27272202'/>
<id>urn:sha1:6aa7d2621b19da344ebcc56b2e00601c27272202</id>
<content type='text'>
[ Upstream commit 2ea538dbee1c79f6f6c24a6f2f82986e4b7ccb78 ]

A merge hint message needs some time to process before the merged
flow actually reaches the firmware, during which we may get duplicate
merge hints if there're more than one packet that hit the pre-merged
flow. And processing duplicate merge hints will cost extra host_ctx's
which are a limited resource.

Avoid the duplicate merge by using hash table to store the sub_flows
to be merged.

Fixes: 8af56f40e53b ("nfp: flower: offload merge flows")
Signed-off-by: Yinjun Zhang &lt;yinjun.zhang@corigine.com&gt;
Signed-off-by: Louis Peens &lt;louis.peens@corigine.com&gt;
Signed-off-by: Simon Horman &lt;simon.horman@netronome.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>
