Petr Machata [Wed, 15 Jan 2020 11:53:49 +0000 (13:53 +0200)]
mlxsw: spectrum_qdisc: Include MC TCs in Qdisc counters
mlxsw configures Spectrum in such a way that BUM traffic is passed not
through its nominal traffic class TC, but through its MC counterpart TC+8.
However, when collecting statistics, Qdiscs only look at the nominal TC and
ignore the MC TC.
Add two helpers to compute the value for logical TC from the constituents,
one for backlog, the other for tail drops. Use them throughout instead of
going through the xstats pointer directly.
Counters for TX bytes and packets are deduced from packet priority
counters, and therefore already include BUM traffic. wred_drop counter is
irrelevant on MC TCs, because RED is not enabled on them.
Fixes: 5a5bc736ee39 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports") Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Wed, 15 Jan 2020 11:53:48 +0000 (13:53 +0200)]
mlxsw: spectrum: Wipe xstats.backlog of down ports
Per-port counter cache used by Qdiscs is updated periodically, unless the
port is down. The fact that the cache is not updated for down ports is no
problem for most counters, which are relative in nature. However, backlog
is absolute in nature, and if there is a non-zero value in the cache around
the time that the port goes down, that value just stays there. This value
then leaks to offloaded Qdiscs that report non-zero backlog even if
there (obviously) is no traffic.
The HW does not keep backlog of a downed port, so do likewise: as the port
goes down, wipe the backlog value from xstats.
Fixes: 7dd377ef4f25 ("mlxsw: spectrum: Collect tclass related stats periodically") Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Mausezahn does not recognize "own" as a keyword on source IP address. As a
result, the MC stream is not running at all, and therefore no UC
degradation can be observed even in principle.
Fix the invocation, and tighten the test: due to the minimum shaper
configured at the MC TCs, we always expect about 20% degradation. Fail the
test if it is lower.
Fixes: 4398d6c252fb ("selftests: mlxsw: Add qos_lib.sh") Signed-off-by: Petr Machata <petrm@mellanox.com> Reported-by: Amit Cohen <amitc@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 15 Jan 2020 11:53:46 +0000 (13:53 +0200)]
mlxsw: switchx2: Do not modify cloned SKBs during xmit
The driver needs to prepend a Tx header to each packet it is
transmitting. The header includes information such as the egress port
and traffic class.
The addition of the header requires the driver to modify the SKB's
header and therefore it must not be shared. Otherwise, we risk hitting
various race conditions.
For example, when a packet is flooded (cloned) by the bridge driver to
two switch ports swp1 and swp2:
t0 - mlxsw_sp_port_xmit() is called for swp1. Tx header is prepended with
swp1's port number
t1 - mlxsw_sp_port_xmit() is called for swp2. Tx header is prepended with
swp2's port number, overwriting swp1's port number
t2 - The device processes data buffer from t0. Packet is transmitted via
swp2
t3 - The device processes data buffer from t1. Packet is transmitted via
swp2
Usually, the device is fast enough and transmits the packet before its
Tx header is overwritten, but this is not the case in emulated
environments.
Fix this by making sure the SKB's header is writable by calling
skb_cow_head(). Since the function ensures we have headroom to push the
Tx header, the check further in the function can be removed.
v2:
* Use skb_cow_head() instead of skb_unshare() as suggested by Jakub
* Remove unnecessary check regarding headroom
Fixes: 98d8057f0798 ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 15 Jan 2020 11:53:45 +0000 (13:53 +0200)]
mlxsw: spectrum: Do not modify cloned SKBs during xmit
The driver needs to prepend a Tx header to each packet it is
transmitting. The header includes information such as the egress port
and traffic class.
The addition of the header requires the driver to modify the SKB's
header and therefore it must not be shared. Otherwise, we risk hitting
various race conditions.
For example, when a packet is flooded (cloned) by the bridge driver to
two switch ports swp1 and swp2:
t0 - mlxsw_sp_port_xmit() is called for swp1. Tx header is prepended with
swp1's port number
t1 - mlxsw_sp_port_xmit() is called for swp2. Tx header is prepended with
swp2's port number, overwriting swp1's port number
t2 - The device processes data buffer from t0. Packet is transmitted via
swp2
t3 - The device processes data buffer from t1. Packet is transmitted via
swp2
Usually, the device is fast enough and transmits the packet before its
Tx header is overwritten, but this is not the case in emulated
environments.
Fix this by making sure the SKB's header is writable by calling
skb_cow_head(). Since the function ensures we have headroom to push the
Tx header, the check further in the function can be removed.
v2:
* Use skb_cow_head() instead of skb_unshare() as suggested by Jakub
* Remove unnecessary check regarding headroom
Fixes: a3f159160767 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: Shalom Toledo <shalomt@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 15 Jan 2020 11:53:44 +0000 (13:53 +0200)]
mlxsw: spectrum: Do not enforce same firmware version for multiple ASICs
In commit 576149f20d9a ("mlxsw: Enforce firmware version for
Spectrum-2") I added a required firmware version for Spectrum-2, but
missed the fact that mlxsw_sp2_init() is used by both Spectrum-2 and
Spectrum-3. This means that the same firmware version will be used for
both, which is wrong.
Fix this by creating a new init() callback for Spectrum-3.
Fixes: 576149f20d9a ("mlxsw: Enforce firmware version for Spectrum-2") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Shalom Toledo <shalomt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 15 Jan 2020 12:12:00 +0000 (04:12 -0800)]
Merge tag 'mac80211-for-net-2020-01-15' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
A few fixes:
* -O3 enablement fallout, thanks to Arnd who ran this
* fixes for a few leaks, thanks to Felix
* channel 12 regulatory fix for custom regdomains
* check for a crash reported by syzbot
(NULL function is called on drivers that don't have it)
* fix TKIP replay protection after setup with some APs
(from Jouni)
* restrict obtaining some mesh data to avoid WARN_ONs
* fix deadlocks with auto-disconnect (socket owner)
* fix radar detection events with multiple devices
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Felix Fietkau [Mon, 13 Jan 2020 18:21:07 +0000 (19:21 +0100)]
cfg80211: fix page refcount issue in A-MSDU decap
The fragments attached to a skb can be part of a compound page. In that case,
page_ref_inc will increment the refcount for the wrong page. Fix this by
using get_page instead, which calls page_ref_inc on the compound head and
also checks for overflow.
Fixes: bf471a342047 ("cfg80211: reuse existing page fragments in A-MSDU rx") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20200113182107.20461-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Arnd Bergmann [Tue, 7 Jan 2020 20:07:35 +0000 (21:07 +0100)]
wireless: wext: avoid gcc -O3 warning
After the introduction of CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3,
the wext code produces a bogus warning:
In function 'iw_handler_get_iwstats',
inlined from 'ioctl_standard_call' at net/wireless/wext-core.c:1015:9,
inlined from 'wireless_process_ioctl' at net/wireless/wext-core.c:935:10,
inlined from 'wext_ioctl_dispatch.part.8' at net/wireless/wext-core.c:986:8,
inlined from 'wext_handle_ioctl':
net/wireless/wext-core.c:671:3: error: argument 1 null where non-null expected [-Werror=nonnull]
memcpy(extra, stats, sizeof(struct iw_statistics));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/x86/include/asm/string.h:5,
net/wireless/wext-core.c: In function 'wext_handle_ioctl':
arch/x86/include/asm/string_64.h:14:14: note: in a call to function 'memcpy' declared here
The problem is that ioctl_standard_call() sometimes calls the handler
with a NULL argument that would cause a problem for iw_handler_get_iwstats.
However, iw_handler_get_iwstats never actually gets called that way.
Marking that function as noinline avoids the warning and leads
to slightly smaller object code as well.
Jouni Malinen [Tue, 7 Jan 2020 15:35:45 +0000 (17:35 +0200)]
mac80211: Fix TKIP replay protection immediately after key setup
TKIP replay protection was skipped for the very first frame received
after a new key is configured. While this is potentially needed to avoid
dropping a frame in some cases, this does leave a window for replay
attacks with group-addressed frames at the station side. Any earlier
frame sent by the AP using the same key would be accepted as a valid
frame and the internal RSC would then be updated to the TSC from that
frame. This would allow multiple previously transmitted group-addressed
frames to be replayed until the next valid new group-addressed frame
from the AP is received by the station.
Fix this by limiting the no-replay-protection exception to apply only
for the case where TSC=0, i.e., when this is for the very first frame
protected using the new key, and the local RSC had not been set to a
higher value when configuring the key (which may happen with GTK).
Orr Mazor [Sun, 22 Dec 2019 14:55:31 +0000 (14:55 +0000)]
cfg80211: Fix radar event during another phy CAC
In case a radar event of CAC_FINISHED or RADAR_DETECTED
happens during another phy is during CAC we might need
to cancel that CAC.
If we got a radar in a channel that another phy is now
doing CAC on then the CAC should be canceled there.
If, for example, 2 phys doing CAC on the same channels,
or on comptable channels, once on of them will finish his
CAC the other might need to cancel his CAC, since it is no
longer relevant.
To fix that the commit adds an callback and implement it in
mac80211 to end CAC.
This commit also adds a call to said callback if after a radar
event we see the CAC is no longer relevant
Ganapathi Bhat [Fri, 20 Dec 2019 10:14:32 +0000 (10:14 +0000)]
wireless: fix enabling channel 12 for custom regulatory domain
Commit 6473d5af7f36 ("Revert "cfg80211: Use 5MHz bandwidth by
default when checking usable channels"") fixed a broken
regulatory (leaving channel 12 open for AP where not permitted).
Apply a similar fix to custom regulatory domain processing.
Lorenzo Bianconi [Tue, 14 Jan 2020 10:21:16 +0000 (11:21 +0100)]
net: mvneta: fix dma sync size in mvneta_run_xdp
Page pool API will start syncing (if requested) starting from
page->dma_addr + pool->p.offset. Fix dma sync length in
mvneta_run_xdp since we do not need to account xdp headroom
Fixes: fabf8786d3c9 ("net: mvneta: get rid of huge dma sync in mvneta_rx_refill") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold [Tue, 14 Jan 2020 08:27:29 +0000 (09:27 +0100)]
r8152: add missing endpoint sanity check
Add missing endpoint sanity check to probe in order to prevent a
NULL-pointer dereference (or slab out-of-bounds access) when retrieving
the interrupt-endpoint bInterval on ndo_open() in case a device lacks
the expected endpoints.
Fixes: f5859f6e3744 ("net/usb/r8152: enable interrupt transfer") Cc: hayeswang <hayeswang@realtek.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sunil Muthuswamy [Tue, 14 Jan 2020 00:52:14 +0000 (00:52 +0000)]
hv_sock: Remove the accept port restriction
Currently, hv_sock restricts the port the guest socket can accept
connections on. hv_sock divides the socket port namespace into two parts
for server side (listening socket), 0-0x7FFFFFFF & 0x80000000-0xFFFFFFFF
(there are no restrictions on client port namespace). The first part
(0-0x7FFFFFFF) is reserved for sockets where connections can be accepted.
The second part (0x80000000-0xFFFFFFFF) is reserved for allocating ports
for the peer (host) socket, once a connection is accepted.
This reservation of the port namespace is specific to hv_sock and not
known by the generic vsock library (ex: af_vsock). This is problematic
because auto-binds/ephemeral ports are handled by the generic vsock
library and it has no knowledge of this port reservation and could
allocate a port that is not compatible with hv_sock (and legitimately so).
The issue hasn't surfaced so far because the auto-bind code of vsock
(__vsock_bind_stream) prior to the change 'VSOCK: bind to random port for
VMADDR_PORT_ANY' would start walking up from LAST_RESERVED_PORT (1023) and
start assigning ports. That will take a large number of iterations to hit
0x7FFFFFFF. But, after the above change to randomize port selection, the
issue has started coming up more frequently.
There has really been no good reason to have this port reservation logic
in hv_sock from the get go. Reserving a local port for peer ports is not
how things are handled generally. Peer ports should reflect the peer port.
This fixes the issue by lifting the port reservation, and also returns the
right peer port. Since the code converts the GUID to the peer port (by
using the first 4 bytes), there is a possibility of conflicts, but that
seems like a reasonable risk to take, given this is limited to vsock and
that only applies to all local sockets.
Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Mon, 13 Jan 2020 17:27:11 +0000 (09:27 -0800)]
net: usb: lan78xx: limit size of local TSO packets
lan78xx_tx_bh() makes sure to not exceed MAX_SINGLE_PACKET_SIZE
bytes in the aggregated packets it builds, but does
nothing to prevent large GSO packets being submitted.
Pierre-Francois reported various hangs when/if TSO is enabled.
For localy generated packets, we can use netif_set_gso_max_size()
to limit the size of TSO packets.
Note that forwarded packets could still hit the issue,
so a complete fix might require implementing .ndo_features_check
for this driver, forcing a software segmentation if the size
of the TSO packet exceeds MAX_SINGLE_PACKET_SIZE.
Fixes: f98af78833e9 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: RENARD Pierre-Francois <pfrenard@gmail.com> Tested-by: RENARD Pierre-Francois <pfrenard@gmail.com> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Woojung Huh <woojung.huh@microchip.com> Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vladis Dronov [Mon, 13 Jan 2020 13:00:09 +0000 (14:00 +0100)]
ptp: free ptp device pin descriptors properly
There is a bug in ptp_clock_unregister(), where ptp_cleanup_pin_groups()
first frees ptp->pin_{,dev_}attr, but then posix_clock_unregister() needs
them to destroy a related sysfs device.
These functions can not be just swapped, as posix_clock_unregister() frees
ptp which is needed in the ptp_cleanup_pin_groups(). Fix this by calling
ptp_cleanup_pin_groups() in ptp_clock_release(), right before ptp is freed.
This makes this patch fix an UAF bug in a patch which fixes an UAF bug.
Reported-by: Antti Laakso <antti.laakso@intel.com> Fixes: cfe094450df2 ("ptp: fix the race between the release of ptp_clock and cdev") Link: https://lore.kernel.org/netdev/3d2bd09735dbdaf003585ca376b7c1e5b69a19bd.camel@intel.com/ Signed-off-by: Vladis Dronov <vdronov@redhat.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold [Mon, 13 Jan 2020 17:23:58 +0000 (18:23 +0100)]
NFC: pn533: fix bulk-message timeout
The driver was doing a synchronous uninterruptible bulk-transfer without
using a timeout. This could lead to the driver hanging on probe due to a
malfunctioning (or malicious) device until the device is physically
disconnected. While sleeping in probe the driver prevents other devices
connected to the same hub from being added to (or removed from) the bus.
An arbitrary limit of five seconds should be more than enough.
Fixes: 4ee0926afbff ("NFC: pn533: don't send USB data off of the stack") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kristian Evensen [Mon, 13 Jan 2020 13:57:40 +0000 (14:57 +0100)]
qmi_wwan: Add support for Quectel RM500Q
RM500Q is a 5G module from Quectel, supporting both standalone and
non-standalone modes. The normal Quectel quirks apply (DTR and dynamic
interface numbers).
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Milind Parab [Mon, 13 Jan 2020 03:30:43 +0000 (03:30 +0000)]
net: macb: fix for fixed-link mode
This patch fix the issue with fixed link. With fixed-link
device opening fails due to macb_phylink_connect not
handling fixed-link mode, in which case no MAC-PHY connection
is needed and phylink_connect return success (0), however
in current driver attempt is made to search and connect to
PHY even for fixed-link.
Fixes: 46e1536937ee ("net: macb: convert to phylink") Signed-off-by: Milind Parab <mparab@cadence.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jacob Keller [Thu, 9 Jan 2020 19:08:20 +0000 (11:08 -0800)]
devlink: correct misspelling of snapshot
The function to obtain a unique snapshot id was mistakenly typo'd as
devlink_region_shapshot_id_get. Fix this typo by renaming the function
and all of its users.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 11 Jan 2020 07:32:54 +0000 (23:32 -0800)]
Merge branch 'DP83822-and-DP83TC811-Fixes'
Dan Murphy says:
====================
DP83822 and DP83TC811 Fixes
Two fixes on net/phy/Kconfig for the TI ethernet PHYs.
First fixed the typo in the Kconfig for the DP83TC811 where it incorretly stated
that the support was for a DP83TC822 which does not exist.
Second fix was to update the DP83822 Kconfig entry to indicate support for the
DP83825 devices in the description and the prompt.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Murphy [Fri, 10 Jan 2020 20:03:57 +0000 (14:03 -0600)]
net: phy: DP83822: Update Kconfig with DP83825I support
Update the Kconfig description to indicate support for the DP83825I
device as well.
Fixes: 32b12dc8fde1 ("net: phy: Add DP83825I to the DP83822 driver") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Murphy [Fri, 10 Jan 2020 20:03:56 +0000 (14:03 -0600)]
net: phy: DP83TC811: Fix typo in Kconfig
Fix typo in the Kconfig for the DP83TC811 as it indicates support for
the DP83TC822 which is incorrect.
Fixes: 6d749428788b {"net: phy: DP83TC811: Introduce support for the DP83TC811 phy") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Thu, 9 Jan 2020 17:57:41 +0000 (19:57 +0200)]
devlink: Wait longer before warning about unset port type
The commit cited below causes devlink to emit a warning if a type was
not set on a devlink port for longer than 30 seconds to "prevent
misbehavior of drivers". This proved to be problematic when
unregistering the backing netdev. The flow is always:
devlink_port_type_clear() // schedules the warning
unregister_netdev() // blocking
devlink_port_unregister() // cancels the warning
The call to unregister_netdev() can block for long periods of time for
various reasons: RTNL lock is contended, large amounts of configuration
to unroll following dismantle of the netdev, etc. This results in
devlink emitting a warning despite the driver behaving correctly.
In emulated environments (of future hardware) which are usually very
slow, the warning can also be emitted during port creation as more than
30 seconds can pass between the time the devlink port is registered and
when its type is set.
In addition, syzbot has hit this warning [1] 1974 times since 07/11/19
without being able to produce a reproducer. Probably because
reproduction depends on the load or other bugs (e.g., RTNL not being
released).
To prevent bogus warnings, increase the timeout to 1 hour.
Fixes: 0e9e3f6827d3 ("devlink: add warning in case driver does not set port type") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reported-by: syzbot+b0a18ed7b08b735d2f41@syzkaller.appspotmail.com Reported-by: Alex Veber <alexve@mellanox.com> Tested-by: Alex Veber <alexve@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Fri, 10 Jan 2020 17:03:58 +0000 (09:03 -0800)]
ipv4: Detect rollover in specific fib table dump
Sven-Haegar reported looping on fib dumps when 255.255.255.255 route has
been added to a table. The looping is caused by the key rolling over from FFFFFFFF to 0. When dumping a specific table only, we need a means to detect
when the table dump is done. The key and count saved to cb args are both 0
only at the start of the table dump. If key is 0 and count > 0, then we are
in the rollover case. Detect and return to avoid looping.
This only affects dumps of a specific table; for dumps of all tables
(the case prior to the change in the Fixes tag) inet_dump_fib moved
the entry counter to the next table and reset the cb args used by
fib_table_dump and fn_trie_dump_leaf, so the rollover ffffffff back
to 0 did not cause looping with the dumps.
Fixes: 0574e933d11d ("net: Enable kernel side filtering of route dumps") Reported-by: Sven-Haegar Koch <haegar@sdinet.de> Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jose Abreu [Fri, 10 Jan 2020 15:23:53 +0000 (16:23 +0100)]
net: stmmac: tc: Do not setup flower filtering if RSS is enabled
RSS, when enabled, will bypass the L3 and L4 filtering causing it not
to work. Add a check before trying to setup the filters.
Fixes: 8aaef7e4c5cc ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jose Abreu [Fri, 10 Jan 2020 15:23:52 +0000 (16:23 +0100)]
net: stmmac: selftests: Update status when disabling RSS
We are disabling RSS on HW but not updating the internal private status
to the 'disabled' state. This is needed for next tc commit that will
check if RSS is disabled before trying to apply filters.
Fixes: 2918c9431322 ("net: stmmac: selftests: Add selftest for L3/L4 Filters") Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 10 Jan 2020 12:38:32 +0000 (04:38 -0800)]
net/tls: fix async operation
Mallesham reports the TLS with async accelerator was broken by
commit 14210c49b09b ("net/tls: free the record on encryption error")
because encryption can return -EINPROGRESS in such setups, which
should not be treated as an error.
The error is also present in the BPF path (likely copied from there).
Reported-by: Mallesham Jatharakonda <mallesham.jatharakonda@oneconvergence.com> Fixes: 635a8c9b3da8 ("tls: add bpf support to sk_msg handling") Fixes: 14210c49b09b ("net/tls: free the record on encryption error") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 10 Jan 2020 12:36:55 +0000 (04:36 -0800)]
net/tls: avoid spurious decryption error with HW resync
When device loses sync mid way through a record - kernel
has to re-encrypt the part of the record which the device
already decrypted to be able to decrypt and authenticate
the record in its entirety.
The re-encryption piggy backs on the decryption routine,
but obviously because the partially decrypted record can't
be authenticated crypto API returns an error which is then
ignored by tls_device_reencrypt().
Commit 6ceb6e9e89b9 ("net/tls: add TlsDecryptError stat")
added a statistic to count decryption errors, this statistic
can't be incremented when we see the expected re-encryption
error. Move the inc to the caller.
Reported-and-tested-by: David Beckett <david.beckett@netronome.com> Fixes: 6ceb6e9e89b9 ("net/tls: add TlsDecryptError stat") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 10 Jan 2020 02:46:10 +0000 (18:46 -0800)]
Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2020-01-09
This series contains fixes to e1000e, igb, ixgbe, ixgbevf, i40e and iavf
drivers.
Brett fixes the validation of the virtchnl queue select bitmaps by
comparing the bitmaps against BIT(I40E_MAX_VF_QUEUES).
Radoslaw removes the limitation of only 10 filter entries for a VF and
allows use of all free RAR entries for the forwarding database, if
needed.
Cambda Zhu fixes the calculation of queue when restoring flow director
filters after resetting the adapter for ixgbe.
Manfred Rudigier fixes the SGMIISFP module discovery for 100FX/LX
modules for igb.
Stefan Assmann fixes iavf where during a VF reset event, MAC filters
were not altered, which could lead to a stale filter when an
administratively set MAC address is forced by the PF.
Adam adds the missing code to set the PHY access flag on X722 devices,
which supports accessing PHY registers with the admin queue command.
Revert a previous commit for e1000e to use "delayed work" which was
causing connections to reset unexpectedly and possible driver crashes.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Martin Schiller [Thu, 9 Jan 2020 06:31:14 +0000 (07:31 +0100)]
net/x25: fix nonblocking connect
This patch fixes 2 issues in x25_connect():
1. It makes absolutely no sense to reset the neighbour and the
connection state after a (successful) nonblocking call of x25_connect.
This prevents any connection from being established, since the response
(call accept) cannot be processed.
2. Any further calls to x25_connect() while a call is pending should
simply return, instead of creating new Call Request (on different
logical channels).
This patch should also fix the "KASAN: null-ptr-deref Write in
x25_connect" and "BUG: unable to handle kernel NULL pointer dereference
in x25_connect" bugs reported by syzbot.
Signed-off-by: Martin Schiller <ms@dev.tdt.de> Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com Signed-off-by: David S. Miller <davem@davemloft.net>
Sergei Shtylyov [Wed, 8 Jan 2020 20:42:42 +0000 (23:42 +0300)]
sh_eth: check sh_eth_cpu_data::dual_port when dumping registers
When adding the sh_eth_cpu_data::dual_port flag I forgot to add the flag
checks to __sh_eth_get_regs(), causing the non-existing TSU registers to
be dumped by 'ethtool' on the single port Ether controllers having TSU...
Fixes: 6424b8668927 ("sh_eth: fix TSU init on SH7734/R8A7740") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Thu, 9 Jan 2020 18:51:22 +0000 (10:51 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
- fix for OOB in hiddev, from Dmitry Torokhov
- _poll API fixes for hidraw, from Marcel Holtmann
- functional fix for Steam driver, from Rodrigo Rivas Costa
- a few new device IDs / device-specific quirks and other assorted
smaller fixes
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: steam: Fix input device disappearing
HID: intel-ish-hid: ipc: Add Tiger Lake PCI device ID
drivers/hid/hid-multitouch.c: fix a possible null pointer access.
HID: wacom: Recognize new MobileStudio Pro PID
HID: intel-ish-hid: ipc: add CMP device id
HID: hiddev: fix mess in hiddev_open()
HID: hid-input: clear unmapped usages
HID: Add quirk for incorrect input length on Lenovo Y720
HID: asus: Ignore Asus vendor-page usage-code 0xff events
HID: ite: Add USB id match for Acer SW5-012 keyboard dock
HID: Add quirk for Xin-Mo Dual Controller
HID: Fix slab-out-of-bounds read in hid_field_extract
HID: multitouch: Add LG MELF0410 I2C touchscreen support
HID: uhid: Fix returning EPOLLOUT from uhid_char_poll
HID: hidraw: Fix returning EPOLLOUT from hidraw_poll
1) Missing netns pointer init in arp_tables, from Florian Westphal.
2) Fix normal tcp SACK being treated as D-SACK, from Pengcheng Yang.
3) Fix divide by zero in sch_cake, from Wen Yang.
4) Len passed to skb_put_padto() is wrong in qrtr code, from Carl
Huang.
5) cmd->obj.chunk is leaked in sctp code error paths, from Xin Long.
6) cgroup bpf programs can be released out of order, fix from Roman
Gushchin.
7) Make sure stmmac debugfs entry name is changed when device name
changes, from Jiping Ma.
8) Fix memory leak in vlan_dev_set_egress_priority(), from Eric
Dumazet.
9) SKB leak in lan78xx usb driver, also from Eric Dumazet.
10) Ridiculous TCA_FQ_QUANTUM values configured can cause loops in fq
packet scheduler, reject them. From Eric Dumazet.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits)
tipc: fix wrong connect() return code
tipc: fix link overflow issue at socket shutdown
netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is present
netfilter: conntrack: dccp, sctp: handle null timeout argument
atm: eni: fix uninitialized variable warning
macvlan: do not assume mac_header is set in macvlan_broadcast()
net: sch_prio: When ungrafting, replace with FIFO
mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO
MAINTAINERS: Remove myself as co-maintainer for qcom-ethqos
gtp: fix bad unlock balance in gtp_encap_enable_socket
pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM
tipc: remove meaningless assignment in Makefile
tipc: do not add socket.o to tipc-y twice
net: stmmac: dwmac-sun8i: Allow all RGMII modes
net: stmmac: dwmac-sunxi: Allow all RGMII modes
net: usb: lan78xx: fix possible skb leak
net: stmmac: Fixed link does not need MDIO Bus
vlan: vlan_changelink() should propagate errors
vlan: fix memory leak in vlan_dev_set_egress_priority
stmmac: debugfs entry name is not be changed when udev rename device name.
...
Adam Ludkiewicz [Wed, 8 Jan 2020 21:44:10 +0000 (13:44 -0800)]
i40e: Set PHY Access flag on X722
The X722 FW API version 1.9 adds support for accessing PHY
registers with Admin Queue Command. This enables reading
EEPROM data from (Q)SFP+ transceivers, what was previously
possible only on X710 devices.
Signed-off-by: Adam Ludkiewicz <adam.ludkiewicz@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Stefan Assmann [Tue, 17 Dec 2019 10:29:23 +0000 (11:29 +0100)]
iavf: remove current MAC address filter on VF reset
Currently MAC filters are not altered during a VF reset event. This may
lead to a stale filter when an administratively set MAC is forced by the
PF.
For an administratively set MAC the PF driver deletes the VFs filters,
overwrites the VFs MAC address and triggers a VF reset. However
the VF driver itself is not aware of the filter removal, which is what
the VF reset is for.
The VF reset queues all filters present in the VF driver to be re-added
to the PF filter list (including the filter for the now stale VF MAC
address) and triggers a VIRTCHNL_OP_GET_VF_RESOURCES event, which
provides the new MAC address to the VF.
When this happens i40e will complain and reject the stale MAC filter,
at least in the untrusted VF case.
i40e 0000:08:00.0: Setting MAC 3c:fa:fa:fa:fa:01 on VF 0
iavf 0000:08:02.0: Reset warning received from the PF
iavf 0000:08:02.0: Scheduling reset task
i40e 0000:08:00.0: Bring down and up the VF interface to make this change effective.
i40e 0000:08:00.0: VF attempting to override administratively set MAC address, bring down and up the VF interface to resume normal operation
i40e 0000:08:00.0: VF 0 failed opcode 10, retval: -1
iavf 0000:08:02.0: Failed to add MAC filter, error IAVF_ERR_NVM
To avoid re-adding the stale MAC filter it needs to be removed from the
VF driver's filter list before queuing the existing filters. Then during
the VIRTCHNL_OP_GET_VF_RESOURCES event the correct filter needs to be
added again, at which point the MAC address has been updated.
As a bonus this change makes bringing the VF down and up again
superfluous for the administratively set MAC case.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Changing the link mode should also be done for 100BaseFX SGMII modules,
otherwise they just don't work when the default link mode in CTRL_EXT
coming from the EEPROM is SERDES.
Additionally 100Base-LX SGMII SFP modules are also supported now, which
was not the case before.
Tested with an i210 using Flexoptix S.1303.2M.G 100FX and
S.1303.10.G 100LX SGMII SFP modules.
Signed-off-by: Manfred Rudigier <manfred.rudigier@omicronenergy.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cambda Zhu [Wed, 27 Nov 2019 09:03:55 +0000 (17:03 +0800)]
ixgbe: Fix calculation of queue with VFs and flow director on interface flap
This patch fixes the calculation of queue when we restore flow director
filters after resetting adapter. In ixgbe_fdir_filter_restore(), filter's
vf may be zero which makes the queue outside of the rx_ring array.
The calculation is changed to the same as ixgbe_add_ethtool_fdir_entry().
Signed-off-by: Cambda Zhu <cambda@linux.alibaba.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Radoslaw Tyl [Mon, 25 Nov 2019 14:24:52 +0000 (15:24 +0100)]
ixgbevf: Remove limit of 10 entries for unicast filter list
Currently, though the FDB entry is added to VF, it does not appear in
RAR filters. VF driver only allows to add 10 entries. Attempting to add
another causes an error. This patch removes limitation and allows use of
all free RAR entries for the FDB if needed.
Fixes: 83fff73bb3 ("ixgbevf: Add macvlan support in the set rx mode op") Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Brett Creeley [Wed, 13 Nov 2019 19:28:17 +0000 (11:28 -0800)]
i40e: Fix virtchnl_queue_select bitmap validation
Currently in i40e_vc_disable_queues_msg() we are incorrectly
validating the virtchnl queue select bitmaps. The
virtchnl_queue_select rx_queues and tx_queue bitmap is being
compared against ICE_MAX_VF_QUEUES, but the problem is that
these bitmaps can have a value greater than I40E_MAX_VF_QUEUES.
Fix this by comparing the bitmaps against BIT(I40E_MAX_VF_QUEUES).
Also, add the function i40e_vc_validate_vqs_bitmaps() that checks to see
if both virtchnl_queue_select bitmaps are empty along with checking that
the bitmaps only have valid bits set. This function can then be used in
both the queue enable and disable flows.
Suggested-by: Arkady Gilinksky <arkady.gilinsky@harmonicinc.com> Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The `connected` value for wired devices was not properly initialized,
it must be set to `true` upon creation, because wired devices do not
generate connection events.
When a raw client (the Steam Client) uses the device, the input device
is destroyed. Then, when the raw client finishes, it must be recreated.
But since the `connected` variable was false this never happended.
Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Tuong Lien [Wed, 8 Jan 2020 02:19:00 +0000 (09:19 +0700)]
tipc: fix wrong connect() return code
The current 'tipc_wait_for_connect()' function does a wait-loop for the
condition 'sk->sk_state != TIPC_CONNECTING' to conclude if the socket
connecting has done. However, when the condition is met, it returns '0'
even in the case the connecting is actually failed, the socket state is
set to 'TIPC_DISCONNECTING' (e.g. when the server socket has closed..).
This results in a wrong return code for the 'connect()' call from user,
making it believe that the connection is established and go ahead with
building, sending a message, etc. but finally failed e.g. '-EPIPE'.
This commit fixes the issue by changing the wait condition to the
'tipc_sk_connected(sk)', so the function will return '0' only when the
connection is really established. Otherwise, either the socket 'sk_err'
if any or '-ETIMEDOUT'/'-EINTR' will be returned correspondingly.
Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Tuong Lien [Wed, 8 Jan 2020 02:18:15 +0000 (09:18 +0700)]
tipc: fix link overflow issue at socket shutdown
When a socket is suddenly shutdown or released, it will reject all the
unreceived messages in its receive queue. This applies to a connected
socket too, whereas there is only one 'FIN' message required to be sent
back to its peer in this case.
In case there are many messages in the queue and/or some connections
with such messages are shutdown at the same time, the link layer will
easily get overflowed at the 'TIPC_SYSTEM_IMPORTANCE' backlog level
because of the message rejections. As a result, the link will be taken
down. Moreover, immediately when the link is re-established, the socket
layer can continue to reject the messages and the same issue happens...
The commit refactors the '__tipc_shutdown()' function to only send one
'FIN' in the situation mentioned above. For the connectionless case, it
is unavoidable but usually there is no rejections for such socket
messages because they are 'dest-droppable' by default.
In addition, the new code makes the other socket states clear
(e.g.'TIPC_LISTEN') and treats as a separate case to avoid misbehaving.
Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Tue, 7 Jan 2020 20:43:59 +0000 (21:43 +0100)]
atm: eni: fix uninitialized variable warning
With -O3, gcc has found an actual unintialized variable stored
into an mmio register in two instances:
drivers/atm/eni.c: In function 'discard':
drivers/atm/eni.c:465:13: error: 'dma[1]' is used uninitialized in this function [-Werror=uninitialized]
writel(dma[i*2+1],eni_dev->rx_dma+dma_wr*8+4);
^
drivers/atm/eni.c:465:13: error: 'dma[3]' is used uninitialized in this function [-Werror=uninitialized]
Change the code to always write zeroes instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Mon, 6 Jan 2020 20:30:48 +0000 (12:30 -0800)]
macvlan: do not assume mac_header is set in macvlan_broadcast()
Use of eth_hdr() in tx path is error prone.
Many drivers call skb_reset_mac_header() before using it,
but others do not.
Commit b46e31649933 ("net: reset mac header in dev_start_xmit()")
attempted to fix this generically, but commit 564fa5c50cd9
("packet: introduce PACKET_QDISC_BYPASS socket option") brought
back the macvlan bug.
Lets add a new helper, so that tx paths no longer have
to call skb_reset_mac_header() only to get a pointer
to skb->data.
Hopefully we will be able to revert b46e31649933
("net: reset mac header in dev_start_xmit()") and save few cycles
in transmit fast path.
BUG: KASAN: use-after-free in __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline]
BUG: KASAN: use-after-free in mc_hash drivers/net/macvlan.c:251 [inline]
BUG: KASAN: use-after-free in macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277
Read of size 4 at addr ffff8880a4932401 by task syz-executor947/9579
Fixes: 95fcd9c9a4b1 ("[NET]: Add macvlan driver") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 8 Jan 2020 20:45:53 +0000 (12:45 -0800)]
Merge branch 'net-ungraft-prio'
Petr Machata says:
====================
When ungrafting from PRIO, replace child with FIFO
When a child Qdisc is removed from one of the PRIO Qdisc's bands, it is
replaced unconditionally by a NOOP qdisc. As a result, any traffic hitting
that band gets dropped. That is incorrect--no Qdisc was explicitly added
when PRIO was created, and after removal, none should have to be added
either.
In patch #2, this problem is fixed for PRIO by first attempting to create a
default Qdisc and only falling back to noop when that fails. This pattern
of attempting to create an invisible FIFO, using NOOP only as a fallback,
is also seen in some other Qdiscs.
The only driver currently offloading PRIO (and thus presumably the only one
impacted by this) is mlxsw. Therefore patch #1 extends mlxsw to handle the
replacement by an invisible FIFO gracefully.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Mon, 6 Jan 2020 18:01:56 +0000 (18:01 +0000)]
net: sch_prio: When ungrafting, replace with FIFO
When a child Qdisc is removed from one of the PRIO Qdisc's bands, it is
replaced unconditionally by a NOOP qdisc. As a result, any traffic hitting
that band gets dropped. That is incorrect--no Qdisc was explicitly added
when PRIO was created, and after removal, none should have to be added
either.
Fix PRIO by first attempting to create a default Qdisc and only falling
back to noop when that fails. This pattern of attempting to create an
invisible FIFO, using NOOP only as a fallback, is also seen in other
Qdiscs.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petr Machata [Mon, 6 Jan 2020 18:01:55 +0000 (18:01 +0000)]
mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO
The following patch will change PRIO to replace a removed Qdisc with an
invisible FIFO, instead of NOOP. mlxsw will see this replacement due to the
graft message that is generated. But because FIFO does not issue its own
REPLACE message, when the graft operation takes place, the Qdisc that mlxsw
tracks under the indicated band is still the old one. The child
handle (0:0) therefore does not match, and mlxsw rejects the graft
operation, which leads to an extack message:
Warning: Offloading graft operation failed.
Fix by ignoring the invisible children in the PRIO graft handler. The
DESTROY message of the removed Qdisc is going to follow shortly and handle
the removal.
Fixes: a8c4f3caf046 ("mlxsw: spectrum: qdiscs: prio: Handle graft command") Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Mon, 6 Jan 2020 14:45:37 +0000 (06:45 -0800)]
gtp: fix bad unlock balance in gtp_encap_enable_socket
WARNING: bad unlock balance detected!
5.5.0-rc5-syzkaller #0 Not tainted
-------------------------------------
syz-executor921/9688 is trying to release lock (sk_lock-AF_INET6) at:
[<ffffffff84bf8506>] gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830
but there are no more locks to release!
other info that might help us debug this:
2 locks held by syz-executor921/9688:
#0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:72 [inline]
#0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x405/0xaf0 net/core/rtnetlink.c:5421
#1: ffff88809304b560 (slock-AF_INET6){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline]
#1: ffff88809304b560 (slock-AF_INET6){+...}, at: release_sock+0x20/0x1c0 net/core/sock.c:2951
Chen-Yu Tsai [Mon, 6 Jan 2020 03:09:45 +0000 (11:09 +0800)]
net: stmmac: dwmac-sun8i: Allow all RGMII modes
Allow all the RGMII modes to be used. This would allow us to represent
the hardware better in the device tree with RGMII_ID where in most
cases the PHY's internal delay for both RX and TX are used.
Fixes: 6f537725a8ed ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Chen-Yu Tsai [Mon, 6 Jan 2020 03:09:22 +0000 (11:09 +0800)]
net: stmmac: dwmac-sunxi: Allow all RGMII modes
Allow all the RGMII modes to be used. This would allow us to represent
the hardware better in the device tree with RGMII_ID where in most
cases the PHY's internal delay for both RX and TX are used.
Fixes: 660c6466f627 ("net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Tadeusz Struk [Tue, 7 Jan 2020 22:04:48 +0000 (14:04 -0800)]
tpm: Handle negative priv->response_len in tpm_common_read()
The priv->response_length can hold the size of an response or an negative
error code, and the tpm_common_read() needs to handle both cases correctly.
Changed the type of response_length to signed and accounted for negative
value in tpm_common_read().
Cc: stable@vger.kernel.org Fixes: bfda1c5bafe1 ("tpm: fix invalid locking in NONBLOCKING mode") Reported-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Eric Dumazet [Tue, 7 Jan 2020 18:57:01 +0000 (10:57 -0800)]
net: usb: lan78xx: fix possible skb leak
If skb_linearize() fails, we need to free the skb.
TSO makes skb bigger, and this bug might be the reason
Raspberry Pi 3B+ users had to disable TSO.
Fixes: f98af78833e9 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: RENARD Pierre-Francois <pfrenard@gmail.com> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Woojung Huh <woojung.huh@microchip.com> Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 7 Jan 2020 09:42:25 +0000 (01:42 -0800)]
vlan: vlan_changelink() should propagate errors
Both vlan_dev_change_flags() and vlan_dev_set_egress_priority()
can return an error. vlan_changelink() should not ignore them.
Fixes: 150606db5e80 ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 7 Jan 2020 09:42:24 +0000 (01:42 -0800)]
vlan: fix memory leak in vlan_dev_set_egress_priority
There are few cases where the ndo_uninit() handler might be not
called if an error happens while device is initialized.
Since vlan_newlink() calls vlan_changelink() before
trying to register the netdevice, we need to make sure
vlan_dev_uninit() has been called at least once,
or we might leak allocated memory.
Fixe: 150606db5e80 ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jiping Ma [Tue, 7 Jan 2020 06:34:00 +0000 (14:34 +0800)]
stmmac: debugfs entry name is not be changed when udev rename device name.
Add one notifier for udev changes net device name. Fixes: b6601323ef9e ("net: stmmac: debugfs entry name is not be changed when udev rename") Signed-off-by: Jiping Ma <jiping.ma2@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Please pull and let me know if there is any problem.
For -stable v5.3
('net/mlx5: Move devlink registration before interfaces load')
For -stable v5.4
('net/mlx5e: Fix hairpin RSS table size')
('net/mlx5: DR, Init lists that are used in rule's member')
('net/mlx5e: Always print health reporter message to dmesg')
('net/mlx5: DR, No need for atomic refcount for internal SW steering resources')
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Mon, 6 Jan 2020 23:38:38 +0000 (15:38 -0800)]
Merge tag 'trace-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Various tracing fixes:
- kbuild found missing define of MCOUNT_INSN_SIZE for various build
configs
- Initialize variable to zero as gcc thinks it is used undefined (it
really isn't but the code is subtle enough that this doesn't hurt)
- Convert from do_div() to div64_ull() to prevent potential divide by
zero
- Unregister a trace point on error path in sched_wakeup tracer
- Use signed offset for archs that can have stext not be first
- A simple indentation fix (whitespace error)"
* tag 'trace-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix indentation issue
kernel/trace: Fix do not unregister tracepoints when register sched_migrate_task fail
tracing: Change offset type to s32 in preempt/irq tracepoints
ftrace: Avoid potential division by zero in function profiler
tracing: Have stack tracer compile when MCOUNT_INSN_SIZE is not defined
tracing: Define MCOUNT_INSN_SIZE when not defined without direct calls
tracing: Initialize val to zero in parse_entry of inject code
Eli Cohen [Wed, 11 Dec 2019 07:17:40 +0000 (09:17 +0200)]
net/mlx5e: Fix hairpin RSS table size
Set hairpin table size to the corret size, based on the groups that
would be created in it. Groups are laid out on the table such that a
group occupies a range of entries in the table. This implies that the
group ranges should have correspondence to the table they are laid upon.
The patch cited below made group 1's size to grow hence causing
overflow of group range laid on the table.
Fixes: edbee0300b28 ("net/mlx5e: Support RSS for IP-in-IP and IPv6 tunneled packets") Signed-off-by: Eli Cohen <eli@mellanox.com> Signed-off-by: Mark Bloch <markb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
During cleanup path, FTE's parent node group is removed which is
referenced by the FTE while freeing the FTE.
Hence FTE's lockless read lookup optimization done in cited commit is
not possible at the moment.
Hence, revert the commit.
This avoid below KAZAN call trace.
[ 110.390896] BUG: KASAN: use-after-free in find_root.isra.14+0x56/0x60
[mlx5_core]
[ 110.391048] Read of size 4 at addr ffff888c19e6d220 by task
swapper/12/0
Eran Ben Elisha [Wed, 4 Dec 2019 12:34:18 +0000 (14:34 +0200)]
net/mlx5e: Always print health reporter message to dmesg
In case a reporter exists, error message is logged only to the devlink
tracer. The devlink tracer is a visibility utility only, which user can
choose not to monitor.
After cited patch, 3rd party monitoring tools that tracks these error
message will no longer find them in dmesg, causing a regression.
With this patch, error messages are also logged into the dmesg.
Fixes: 9843142574e2 ("net/mlx5e: Generalize tx reporter's functionality") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Dmytro Linkin [Thu, 31 Oct 2019 16:15:51 +0000 (18:15 +0200)]
net/mlx5e: Avoid duplicating rule destinations
Following scenario easily break driver logic and crash the kernel:
1. Add rule with mirred actions to same device.
2. Delete this rule.
In described scenario rule is not added to database and on deletion
driver access invalid entry.
Example:
$ tc filter add dev ens1f0_0 ingress protocol ip prio 1 \
flower skip_sw \
action mirred egress mirror dev ens1f0_1 pipe \
action mirred egress redirect dev ens1f0_1
$ tc filter del dev ens1f0_0 ingress protocol ip prio 1
Linus Torvalds [Mon, 6 Jan 2020 22:49:52 +0000 (14:49 -0800)]
Merge tag 'tpmdd-next-20200106' of git://git.infradead.org/users/jjs/linux-tpmdd
Pull tpmd fixes from Jarkko Sakkinen:
"There has been a bunch of reports (e.g. [*]) reporting that when
commit 25bf41d1bfc8 ("tpm_tis_core: Turn on the TPM before probing
IRQ's") and subsequent fixes are applied it causes boot freezes on
some machines.
Unfortunately hardware where this causes a failure is not widely
available (only one I'm aware is Lenovo T490), which means we cannot
predict yet how long it will take to properly fix tpm_tis interrupt
probing.
Thus, the least worst short term action is to revert the code to the
state before this commit. In long term we need fix the tpm_tis probing
code to work on machines that Stefan's patches were supposed to fix.
With these patches reverted nothing fatal happens, TPM is fallbacked
to be used in polling mode (which is not in the end too bad because
there are no high throughput workloads for TPM).
* tag 'tpmdd-next-20200106' of git://git.infradead.org/users/jjs/linux-tpmdd:
tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"
tpm: Revert "tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts"
tpm: Revert "tpm_tis: reserve chip for duration of tpm_tis_core_init"
After further debugging, turns out while in case of other helper functions
we disallow passing modified ctx, the special case of ld/abs/ind instruction
which has similar semantics (except r6 being the ctx argument) is missing
such check. Modified ctx is impossible here as bpf_skb_load_helper_8_no_cache()
and others are expecting skb fields in original position, hence, add
check_ctx_reg() to reject any modified ctx. Issue was first introduced back
in 8e11845d64e4 ("bpf/verifier: rework value tracking").
Fixes: 8e11845d64e4 ("bpf/verifier: rework value tracking") Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200106215157.3553-1-daniel@iogearbox.net
Igor Russkikh [Mon, 6 Jan 2020 11:22:30 +0000 (14:22 +0300)]
net: atlantic: remove duplicate entries
Function entries were duplicated accidentally, removing the dups.
Fixes: 286f3f2a5fb9 ("net: atlantic: loopback tests via private flags") Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Igor Russkikh [Mon, 6 Jan 2020 11:22:29 +0000 (14:22 +0300)]
net: atlantic: loopback configuration in improper place
Initial loopback configuration should be called earlier, before
starting traffic on HW blocks. Otherwise depending on race conditions
it could be kept disabled.
Fixes: 286f3f2a5fb9 ("net: atlantic: loopback tests via private flags") Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Igor Russkikh [Mon, 6 Jan 2020 11:22:28 +0000 (14:22 +0300)]
net: atlantic: broken link status on old fw
Last code/checkpatch cleanup did a copy paste error where code from
firmware 3 API logic was moved to firmware 1 logic.
This resulted in FW1.x users would never see the link state as active.
Fixes: 4f779a9fcdad ("net: atlantic: code style cleanup") Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Roman Gushchin [Fri, 27 Dec 2019 21:50:34 +0000 (13:50 -0800)]
bpf: cgroup: prevent out-of-order release of cgroup bpf
Before commit effa617a068a ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself")
cgroup bpf structures were released with
corresponding cgroup structures. It guaranteed the hierarchical order
of destruction: children were always first. It preserved attached
programs from being released before their propagated copies.
But with cgroup auto-detachment there are no such guarantees anymore:
cgroup bpf is released as soon as the cgroup is offline and there are
no live associated sockets. It means that an attached program can be
detached and released, while its propagated copy is still living
in the cgroup subtree. This will obviously lead to an use-after-free
bug.
To reproduce the issue the following script can be used:
Fix this by grabbing a reference to the bpf structure of each ancestor
on the initialization of the cgroup bpf structure, and dropping the
reference at the end of releasing the cgroup bpf structure.
This will restore the hierarchical order of cgroup bpf releasing,
without adding any operations on hot paths.
Thanks to Josef Bacik for the debugging and the initial analysis of
the problem.
Fixes: effa617a068a ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself") Reported-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Roman Gushchin <guro@fb.com> Acked-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Vikas Gupta [Mon, 6 Jan 2020 06:24:02 +0000 (11:54 +0530)]
firmware: tee_bnxt: Fix multiple call to tee_client_close_context
Fix calling multiple tee_client_close_context in case of shm allocation
fails.
Fixes: b9d244ae05c1 (“firmware: broadcom: add OP-TEE based BNXT f/w manager”) Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Lunn [Sat, 4 Jan 2020 22:14:51 +0000 (23:14 +0100)]
net: dsa: mv88e6xxx: Preserve priority when setting CPU port.
The 6390 family uses an extended register to set the port connected to
the CPU. The lower 5 bits indicate the port, the upper three bits are
the priority of the frames as they pass through the switch, what
egress queue they should use, etc. Since frames being set to the CPU
are typically management frames, BPDU, IGMP, ARP, etc set the priority
to 7, the reset default, and the highest.
Fixes: fcf2e16a7f29 ("net: dsa: mv88e6xxx: Monitor and Management tables") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Fix up inconsistent usage of upper and lowercase letters in "Samsung"
name.
"SAMSUNG" is not an abbreviation but a regular trademarked name.
Therefore it should be written with lowercase letters starting with
capital letter.
Although advertisement materials usually use uppercase "SAMSUNG", the
lowercase version is used in all legal aspects (e.g. on Wikipedia and in
privacy/legal statements on
https://www.samsung.com/semiconductor/privacy-global/).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
net: wan: sdla: Fix cast from pointer to integer of different size
Since net_device.mem_start is unsigned long, it should not be cast to
int right before casting to pointer. This fixes warning (compile
testing on alpha architecture):
drivers/net/wan/sdla.c: In function ‘sdla_transmit’:
drivers/net/wan/sdla.c:711:13: warning:
cast to pointer from integer of different size [-Wint-to-pointer-cast]
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Sat, 4 Jan 2020 06:15:02 +0000 (14:15 +0800)]
sctp: free cmd->obj.chunk for the unprocessed SCTP_CMD_REPLY
This patch is to fix a memleak caused by no place to free cmd->obj.chunk
for the unprocessed SCTP_CMD_REPLY. This issue occurs when failing to
process a cmd while there're still SCTP_CMD_REPLY cmds on the cmd seq
with an allocated chunk in cmd->obj.chunk.
So fix it by freeing cmd->obj.chunk for each SCTP_CMD_REPLY cmd left on
the cmd seq when any cmd returns error. While at it, also remove 'nomem'
label.
Reported-by: syzbot+107c4aff5f392bf1517f@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The complaint above occurred because the memory region pointed by attrbuf
variable was not initialized. To eliminate this warning, we use kcalloc()
rather than kmalloc_array() to allocate memory for attrbuf.
Reported-by: syzbot+b1fd2bf2c89d8407e15f@syzkaller.appspotmail.com Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Mon, 6 Jan 2020 20:34:44 +0000 (12:34 -0800)]
Merge tag 'spi-fix-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of fixes here, one to make the newly added PTP
timestamping code more accurate, a few driver fixes and a fix for the
core DT binding to document the fact that we support eight wire buses"
* tag 'spi-fix-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: Document Octal mode as valid SPI bus width
spi: spi-dw: Add lock protect dw_spi rx/tx to prevent concurrent calls
spi: spi-fsl-dspi: Fix 16-bit word order in 32-bit XSPI mode
spi: Don't look at TX buffer for PTP system timestamping
spi: uniphier: Fix FIFO threshold
projects / kernel.git / log