OSDN Git Service
David S. Miller [Wed, 16 Feb 2022 11:21:05 +0000 (11:21 +0000)]
Merge branch 'Replay-and-offload-host-VLAN-entries-in-DSA'
Vladimir Oltean says:
====================
Replay and offload host VLAN entries in DSA
v2->v3:
- make the bridge stop notifying switchdev for !BRENTRY VLANs
- create precommit and commit wrappers around __vlan_add_flags().
- special-case the BRENTRY transition from false to true, instead of
treating it as a change of flags and letting drivers figure out that
it really isn't.
- avoid setting *changed unless we know that functions will not error
out later.
- drop "old_flags" from struct switchdev_obj_port_vlan, nobody needs it
now, in v2 only DSA needed it to filter out BRENTRY transitions, that
is now solved cleaner.
- no BRIDGE_VLAN_INFO_BRENTRY flag checks and manipulations in DSA
whatsoever, use the "bool changed" bit as-is after changing what it
means.
- merge dsa_slave_host_vlan_{add,del}() with
dsa_slave_foreign_vlan_{add,del}(), since now they do the same thing,
because the host_vlan functions no longer need to mangle the vlan
BRENTRY flags and bool changed.
v1->v2:
- prune switchdev VLAN additions with no actual change differently
- no longer need to revert struct net_bridge_vlan changes on error from
switchdev
- no longer need to first delete a changed VLAN before readding it
- pass 'bool changed' and 'u16 old_flags' through switchdev_obj_port_vlan
so that DSA can do some additional post-processing with the
BRIDGE_VLAN_INFO_BRENTRY flag
- support VLANs on foreign interfaces
- fix the same -EOPNOTSUPP error in mv88e6xxx, this time on removal, due
to VLAN deletion getting replayed earlier than FDB deletion
The motivation behind these patches is that Rafael reported the
following error with mv88e6xxx when the first switch port joins a
bridge:
mv88e6085 0x0000000008b96000:00: port 0 failed to add a6:ef:77:c8:5f:3d vid 1 to fdb: -95 (-EOPNOTSUPP)
The FDB entry that's added is the MAC address of the bridge, in VID 1
(the default_pvid), being replayed as part of br_add_if() -> ... ->
nbp_switchdev_sync_objs().
-EOPNOTSUPP is the mv88e6xxx driver's way of saying that VID 1 doesn't
exist in the VTU, so it can't program the ATU with a FID, something
which it needs.
It appears to be a race, but it isn't, since we only end up installing
VID 1 in the VTU by coincidence. DSA's approximation of programming
VLANs on the CPU port together with the user ports breaks down with
host FDB entries on mv88e6xxx, since that strictly requires the VTU to
contain the VID. But the user may freely add VLANs pointing just towards
the bridge, and FDB entries in those VLANs, and DSA will not be aware of
them, because it only listens for VLANs on user ports.
To create a solution that scales properly to cross-chip setups and
doesn't leak entries behind, some changes in the bridge driver are
required. I believe that these are for the better overall, but I may be
wrong. Namely, the same refcounting procedure that DSA has in place for
host FDB and MDB entries can be replicated for VLANs, except that it's
garbage in, garbage out: the VLAN addition and removal notifications
from switchdev aren't balanced. So the first 2 patches attempt to deal
with that.
This patch set has been superficially tested on a board with 3 mv88e6xxx
switches in a daisy chain and appears to produce the primary desired
effect - the driver no longer returns -EOPNOTSUPP when the first port
joins a bridge, and is successful in performing local termination under
a VLAN-aware bridge.
As an additional side effect, it silences the annoying "p%d: already a
member of VLAN %d\n" warning messages that the mv88e6xxx driver produces
when coupled with systemd-networkd, and a few VLANs are configured.
Furthermore, it advances Florian's idea from a few years back, which
never got merged:
https://lore.kernel.org/lkml/
20180624153339.13572-1-f.fainelli@gmail.com/
v2 has also been tested on the NXP LS1028A felix switch.
Some testing:
root@debian:~# bridge vlan add dev br0 vid 101 pvid self
[ 100.709220] mv88e6085
d0032004.mdio-mii:10: mv88e6xxx_port_vlan_add: port 9 vlan 101
[ 100.873426] mv88e6085
d0032004.mdio-mii:10: mv88e6xxx_port_vlan_add: port 10 vlan 101
[ 100.892314] mv88e6085
d0032004.mdio-mii:11: mv88e6xxx_port_vlan_add: port 9 vlan 101
[ 101.053392] mv88e6085
d0032004.mdio-mii:11: mv88e6xxx_port_vlan_add: port 10 vlan 101
[ 101.076994] mv88e6085
d0032004.mdio-mii:12: mv88e6xxx_port_vlan_add: port 9 vlan 101
root@debian:~# bridge vlan add dev br0 vid 101 pvid self
root@debian:~# bridge vlan add dev br0 vid 101 pvid self
root@debian:~# bridge vlan
port vlan-id
eth0 1 PVID Egress Untagged
lan9 1 PVID Egress Untagged
lan10 1 PVID Egress Untagged
lan11 1 PVID Egress Untagged
lan12 1 PVID Egress Untagged
lan13 1 PVID Egress Untagged
lan14 1 PVID Egress Untagged
lan15 1 PVID Egress Untagged
lan16 1 PVID Egress Untagged
lan17 1 PVID Egress Untagged
lan18 1 PVID Egress Untagged
lan19 1 PVID Egress Untagged
lan20 1 PVID Egress Untagged
lan21 1 PVID Egress Untagged
lan22 1 PVID Egress Untagged
lan23 1 PVID Egress Untagged
lan24 1 PVID Egress Untagged
sfp 1 PVID Egress Untagged
lan1 1 PVID Egress Untagged
lan2 1 PVID Egress Untagged
lan3 1 PVID Egress Untagged
lan4 1 PVID Egress Untagged
lan5 1 PVID Egress Untagged
lan6 1 PVID Egress Untagged
lan7 1 PVID Egress Untagged
lan8 1 PVID Egress Untagged
br0 1 Egress Untagged
101 PVID
root@debian:~# bridge vlan del dev br0 vid 101 pvid self
[ 108.340487] mv88e6085
d0032004.mdio-mii:11: mv88e6xxx_port_vlan_del: port 9 vlan 101
[ 108.379167] mv88e6085
d0032004.mdio-mii:11: mv88e6xxx_port_vlan_del: port 10 vlan 101
[ 108.402319] mv88e6085
d0032004.mdio-mii:12: mv88e6xxx_port_vlan_del: port 9 vlan 101
[ 108.425866] mv88e6085
d0032004.mdio-mii:10: mv88e6xxx_port_vlan_del: port 9 vlan 101
[ 108.452280] mv88e6085
d0032004.mdio-mii:10: mv88e6xxx_port_vlan_del: port 10 vlan 101
root@debian:~# bridge vlan del dev br0 vid 101 pvid self
root@debian:~# bridge vlan del dev br0 vid 101 pvid self
root@debian:~# bridge vlan
port vlan-id
eth0 1 PVID Egress Untagged
lan9 1 PVID Egress Untagged
lan10 1 PVID Egress Untagged
lan11 1 PVID Egress Untagged
lan12 1 PVID Egress Untagged
lan13 1 PVID Egress Untagged
lan14 1 PVID Egress Untagged
lan15 1 PVID Egress Untagged
lan16 1 PVID Egress Untagged
lan17 1 PVID Egress Untagged
lan18 1 PVID Egress Untagged
lan19 1 PVID Egress Untagged
lan20 1 PVID Egress Untagged
lan21 1 PVID Egress Untagged
lan22 1 PVID Egress Untagged
lan23 1 PVID Egress Untagged
lan24 1 PVID Egress Untagged
sfp 1 PVID Egress Untagged
lan1 1 PVID Egress Untagged
lan2 1 PVID Egress Untagged
lan3 1 PVID Egress Untagged
lan4 1 PVID Egress Untagged
lan5 1 PVID Egress Untagged
lan6 1 PVID Egress Untagged
lan7 1 PVID Egress Untagged
lan8 1 PVID Egress Untagged
br0 1 Egress Untagged
root@debian:~# bridge vlan del dev br0 vid 101 pvid self
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:18 +0000 (19:02 +0200)]
net: dsa: offload bridge port VLANs on foreign interfaces
DSA now explicitly handles VLANs installed with the 'self' flag on the
bridge as host VLANs, instead of just replicating every bridge port VLAN
also on the CPU port and never deleting it, which is what it did before.
However, this leaves a corner case uncovered, as explained by
Tobias Waldekranz:
https://patchwork.kernel.org/project/netdevbpf/patch/
20220209213044.
2353153-6-vladimir.oltean@nxp.com/#
24735260
Forwarding towards a bridge port VLAN installed on a bridge port foreign
to DSA (separate NIC, Wi-Fi AP) used to work by virtue of the fact that
DSA itself needed to have at least one port in that VLAN (therefore, it
also had the CPU port in said VLAN). However, now that the CPU port may
not be member of all VLANs that user ports are members of, we need to
ensure this isn't the case if software forwarding to a foreign interface
is required.
The solution is to treat bridge port VLANs on standalone interfaces in
the exact same way as host VLANs. From DSA's perspective, there is no
difference between local termination and software forwarding; packets in
that VLAN must reach the CPU in both cases.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:17 +0000 (19:02 +0200)]
net: dsa: add explicit support for host bridge VLANs
Currently, DSA programs VLANs on shared (DSA and CPU) ports each time it
does so on user ports. This is good for basic functionality but has
several limitations:
- the VLAN group which must reach the CPU may be radically different
from the VLAN group that must be autonomously forwarded by the switch.
In other words, the admin may want to isolate noisy stations and avoid
traffic from them going to the control processor of the switch, where
it would just waste useless cycles. The bridge already supports
independent control of VLAN groups on bridge ports and on the bridge
itself, and when VLAN-aware, it will drop packets in software anyway
if their VID isn't added as a 'self' entry towards the bridge device.
- Replaying host FDB entries may depend, for some drivers like mv88e6xxx,
on replaying the host VLANs as well. The 2 VLAN groups are
approximately the same in most regular cases, but there are corner
cases when timing matters, and DSA's approximation of replicating
VLANs on shared ports simply does not work.
- If a user makes the bridge (implicitly the CPU port) join a VLAN by
accident, there is no way for the CPU port to isolate itself from that
noisy VLAN except by rebooting the system. This is because for each
VLAN added on a user port, DSA will add it on shared ports too, but
for each VLAN deletion on a user port, it will remain installed on
shared ports, since DSA has no good indication of whether the VLAN is
still in use or not.
Now that the bridge driver emits well-balanced SWITCHDEV_OBJ_ID_PORT_VLAN
addition and removal events, DSA has a simple and straightforward task
of separating the bridge port VLANs (these have an orig_dev which is a
DSA slave interface, or a LAG interface) from the host VLANs (these have
an orig_dev which is a bridge interface), and to keep a simple reference
count of each VID on each shared port.
Forwarding VLANs must be installed on the bridge ports and on all DSA
ports interconnecting them. We don't have a good view of the exact
topology, so we simply install forwarding VLANs on all DSA ports, which
is what has been done until now.
Host VLANs must be installed primarily on the dedicated CPU port of each
bridge port. More subtly, they must also be installed on upstream-facing
and downstream-facing DSA ports that are connecting the bridge ports and
the CPU. This ensures that the mv88e6xxx's problem (VID of host FDB
entry may be absent from VTU) is still addressed even if that switch is
in a cross-chip setup, and it has no local CPU port.
Therefore:
- user ports contain only bridge port (forwarding) VLANs, and no
refcounting is necessary
- DSA ports contain both forwarding and host VLANs. Refcounting is
necessary among these 2 types.
- CPU ports contain only host VLANs. Refcounting is also necessary.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:16 +0000 (19:02 +0200)]
net: switchdev: introduce switchdev_handle_port_obj_{add,del} for foreign interfaces
The switchdev_handle_port_obj_add() helper is good for replicating a
port object on the lower interfaces of @dev, if that object was emitted
on a bridge, or on a bridge port that is a LAG.
However, drivers that use this helper limit themselves to a box from
which they can no longer intercept port objects notified on neighbor
ports ("foreign interfaces").
One such driver is DSA, where software bridging with foreign interfaces
such as standalone NICs or Wi-Fi APs is an important use case. There, a
VLAN installed on a neighbor bridge port roughly corresponds to a
forwarding VLAN installed on the DSA switch's CPU port.
To support this use case while also making use of the benefits of the
switchdev_handle_* replication helper for port objects, introduce a new
variant of these functions that crawls through the neighbor ports of
@dev, in search of potentially compatible switchdev ports that are
interested in the event.
The strategy is identical to switchdev_handle_fdb_event_to_device():
if @dev wasn't a switchdev interface, then go one step upper, and
recursively call this function on the bridge that this port belongs to.
At the next recursion step, __switchdev_handle_port_obj_add() will
iterate through the bridge's lower interfaces. Among those, some will be
switchdev interfaces, and one will be the original @dev that we came
from. To prevent infinite recursion, we must suppress reentry into the
original @dev, and just call the @add_cb for the switchdev_interfaces.
It looks like this:
br0
/ | \
/ | \
/ | \
swp0 swp1 eth0
1. __switchdev_handle_port_obj_add(eth0)
-> check_cb(eth0) returns false
-> eth0 has no lower interfaces
-> eth0's bridge is br0
-> switchdev_lower_dev_find(br0, check_cb, foreign_dev_check_cb))
finds br0
2. __switchdev_handle_port_obj_add(br0)
-> check_cb(br0) returns false
-> netdev_for_each_lower_dev
-> check_cb(swp0) returns true, so we don't skip this interface
3. __switchdev_handle_port_obj_add(swp0)
-> check_cb(swp0) returns true, so we call add_cb(swp0)
(back to netdev_for_each_lower_dev from 2)
-> check_cb(swp1) returns true, so we don't skip this interface
4. __switchdev_handle_port_obj_add(swp1)
-> check_cb(swp1) returns true, so we call add_cb(swp1)
(back to netdev_for_each_lower_dev from 2)
-> check_cb(eth0) returns false, so we skip this interface to
avoid infinite recursion
Note: eth0 could have been a LAG, and we don't want to suppress the
recursion through its lowers if those exist, so when check_cb() returns
false, we still call switchdev_lower_dev_find() to estimate whether
there's anything worth a recursion beneath that LAG. Using check_cb()
and foreign_dev_check_cb(), switchdev_lower_dev_find() not only figures
out whether the lowers of the LAG are switchdev, but also whether they
actively offload the LAG or not (whether the LAG is "foreign" to the
switchdev interface or not).
The port_obj_info->orig_dev is preserved across recursive calls, so
switchdev drivers still know on which device was this notification
originally emitted.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:15 +0000 (19:02 +0200)]
net: switchdev: rename switchdev_lower_dev_find to switchdev_lower_dev_find_rcu
switchdev_lower_dev_find() assumes RCU read-side critical section
calling context, since it uses netdev_walk_all_lower_dev_rcu().
Rename it appropriately, in preparation of adding a similar iterator
that assumes writer-side rtnl_mutex protection.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:14 +0000 (19:02 +0200)]
net: bridge: switchdev: replay all VLAN groups
The major user of replayed switchdev objects is DSA, and so far it
hasn't needed information about anything other than bridge port VLANs,
so this is all that br_switchdev_vlan_replay() knows to handle.
DSA has managed to get by through replicating every VLAN addition on a
user port such that the same VLAN is also added on all DSA and CPU
ports, but there is a corner case where this does not work.
The mv88e6xxx DSA driver currently prints this error message as soon as
the first port of a switch joins a bridge:
mv88e6085 0x0000000008b96000:00: port 0 failed to add a6:ef:77:c8:5f:3d vid 1 to fdb: -95
where a6:ef:77:c8:5f:3d vid 1 is a local FDB entry corresponding to the
bridge MAC address in the default_pvid.
The -EOPNOTSUPP is returned by mv88e6xxx_port_db_load_purge() because it
tries to map VID 1 to a FID (the ATU is indexed by FID not VID), but
fails to do so. This is because ->port_fdb_add() is called before
->port_vlan_add() for VID 1.
The abridged timeline of the calls is:
br_add_if
-> netdev_master_upper_dev_link
-> dsa_port_bridge_join
-> switchdev_bridge_port_offload
-> br_switchdev_vlan_replay (*)
-> br_switchdev_fdb_replay
-> mv88e6xxx_port_fdb_add
-> nbp_vlan_init
-> nbp_vlan_add
-> mv88e6xxx_port_vlan_add
and the issue is that at the time of (*), the bridge port isn't in VID 1
(nbp_vlan_init hasn't been called), therefore br_switchdev_vlan_replay()
won't have anything to replay, therefore VID 1 won't be in the VTU by
the time mv88e6xxx_port_fdb_add() is called.
This happens only when the first port of a switch joins. For further
ports, the initial mv88e6xxx_port_vlan_add() is sufficient for VID 1 to
be loaded in the VTU (which is switch-wide, not per port).
The problem is somewhat unique to mv88e6xxx by chance, because most
other drivers offload an FDB entry by VID, so FDBs and VLANs can be
added asynchronously with respect to each other, but addressing the
issue at the bridge layer makes sense, since what mv88e6xxx requires
isn't absurd.
To fix this problem, we need to recognize that it isn't the VLAN group
of the port that we're interested in, but the VLAN group of the bridge
itself (so it isn't a timing issue, but rather insufficient information
being passed from switchdev to drivers).
As mentioned, currently nbp_switchdev_sync_objs() only calls
br_switchdev_vlan_replay() for VLANs corresponding to the port, but the
VLANs corresponding to the bridge itself, for local termination, also
need to be replayed. In this case, VID 1 is not (yet) present in the
port's VLAN group but is present in the bridge's VLAN group.
So to fix this bug, DSA is now obligated to explicitly handle VLANs
pointing towards the bridge in order to "close this race" (which isn't
really a race). As Tobias Waldekranz notices, this also implies that it
must explicitly handle port VLANs on foreign interfaces, something that
worked implicitly before:
https://patchwork.kernel.org/project/netdevbpf/patch/
20220209213044.
2353153-6-vladimir.oltean@nxp.com/#
24735260
So in the end, br_switchdev_vlan_replay() must replay all VLANs from all
VLAN groups: all the ports, and the bridge itself.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:13 +0000 (19:02 +0200)]
net: bridge: make nbp_switchdev_unsync_objs() follow reverse order of sync()
There may be switchdev drivers that can add/remove a FDB or MDB entry
only as long as the VLAN it's in has been notified and offloaded first.
The nbp_switchdev_sync_objs() method satisfies this requirement on
addition, but nbp_switchdev_unsync_objs() first deletes VLANs, then
deletes MDBs and FDBs. Reverse the order of the function calls to cater
to this requirement.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:12 +0000 (19:02 +0200)]
net: bridge: switchdev: differentiate new VLANs from changed ones
br_switchdev_port_vlan_add() currently emits a SWITCHDEV_PORT_OBJ_ADD
event with a SWITCHDEV_OBJ_ID_PORT_VLAN for 2 distinct cases:
- a struct net_bridge_vlan got created
- an existing struct net_bridge_vlan was modified
This makes it impossible for switchdev drivers to properly balance
PORT_OBJ_ADD with PORT_OBJ_DEL events, so if we want to allow that to
happen, we must provide a way for drivers to distinguish between a
VLAN with changed flags and a new one.
Annotate struct switchdev_obj_port_vlan with a "bool changed" that
distinguishes the 2 cases above.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:11 +0000 (19:02 +0200)]
net: bridge: vlan: notify switchdev only when something changed
Currently, when a VLAN entry is added multiple times in a row to a
bridge port, nbp_vlan_add() calls br_switchdev_port_vlan_add() each
time, even if the VLAN already exists and nothing about it has changed:
bridge vlan add dev lan12 vid 100 master static
Similarly, when a VLAN is added multiple times in a row to a bridge,
br_vlan_add_existing() doesn't filter at all the calls to
br_switchdev_port_vlan_add():
bridge vlan add dev br0 vid 100 self
This behavior makes driver-level accounting of VLANs impossible, since
it is enough for a single deletion event to remove a VLAN, but the
addition event can be emitted an unlimited number of times.
The cause for this can be identified as follows: we rely on
__vlan_add_flags() to retroactively tell us whether it has changed
anything about the VLAN flags or VLAN group pvid. So we'd first have to
call __vlan_add_flags() before calling br_switchdev_port_vlan_add(), in
order to have access to the "bool *changed" information. But we don't
want to change the event ordering, because we'd have to revert the
struct net_bridge_vlan changes we've made if switchdev returns an error.
So to solve this, we need another function that tells us whether any
change is going to occur in the VLAN or VLAN group, _prior_ to calling
__vlan_add_flags().
Split __vlan_add_flags() into a precommit and a commit stage, and rename
it to __vlan_flags_update(). The precommit stage,
__vlan_flags_would_change(), will determine whether there is any reason
to notify switchdev due to a change of flags (note: the BRENTRY flag
transition from false to true is treated separately: as a new switchdev
entry, because we skipped notifying the master VLAN when it wasn't a
brentry yet, and therefore not as a change of flags).
With this lookahead/precommit function in place, we can avoid notifying
switchdev if nothing changed for the VLAN and VLAN group.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:10 +0000 (19:02 +0200)]
net: bridge: vlan: make __vlan_add_flags react only to PVID and UNTAGGED
Currently there is a very subtle aspect to the behavior of
__vlan_add_flags(): it changes the struct net_bridge_vlan flags and
pvid, yet it returns true ("changed") even if none of those changed,
just a transition of br_vlan_is_brentry(v) took place from false to
true.
This can be seen in br_vlan_add_existing(), however we do not actually
rely on this subtle behavior, since the "if" condition that checks that
the vlan wasn't a brentry before had a useless (until now) assignment:
*changed = true;
Make things more obvious by actually making __vlan_add_flags() do what's
written on the box, and be more specific about what is actually written
on the box. This is needed because further transformations will be done
to __vlan_add_flags().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:09 +0000 (19:02 +0200)]
net: bridge: vlan: don't notify to switchdev master VLANs without BRENTRY flag
When a VLAN is added to a bridge port and it doesn't exist on the bridge
device yet, it gets created for the multicast context, but it is
'hidden', since it doesn't have the BRENTRY flag yet:
ip link add br0 type bridge && ip link set swp0 master br0
bridge vlan add dev swp0 vid 100 # the master VLAN 100 gets created
bridge vlan add dev br0 vid 100 self # that VLAN becomes brentry just now
All switchdev drivers ignore switchdev notifiers for VLAN entries which
have the BRENTRY unset, and for good reason: these are merely private
data structures used by the bridge driver. So we might just as well not
notify those at all.
Cleanup in the switchdev drivers that check for the BRENTRY flag is now
possible, and will be handled separately, since those checks just became
dead code.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Tue, 15 Feb 2022 17:02:08 +0000 (19:02 +0200)]
net: bridge: vlan: check early for lack of BRENTRY flag in br_vlan_add_existing
When a VLAN is added to a bridge port, a master VLAN gets created on the
bridge for context, but it doesn't have the BRENTRY flag.
Then, when the same VLAN is added to the bridge itself, that enters
through the br_vlan_add_existing() code path and gains the BRENTRY flag,
thus it becomes "existing".
It seems natural to check for this condition early, because the current
code flow is to notify switchdev of the addition of a VLAN that isn't a
brentry, just to delete it immediately afterwards.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Haiyue Wang [Tue, 15 Feb 2022 05:17:49 +0000 (13:17 +0800)]
gve: enhance no queue page list detection
The commit
a5886ef4f4bf ("gve: Introduce per netdev `enum gve_queue_format`")
introduces three queue format type, only GVE_GQI_QPL_FORMAT queue has
page list. So it should use the queue page list number to detect the
zero size queue page list. Correct the design logic.
Using the 'queue_format == GVE_GQI_RDA_FORMAT' may lead to request zero
sized memory allocation, like if the queue format is GVE_DQO_RDA_FORMAT.
The kernel memory subsystem will return ZERO_SIZE_PTR, which is not NULL
address, so the driver can run successfully. Also the code still checks
the queue page list number firstly, then accesses the allocated memory,
so zero number queue page list allocation will not lead to access fault.
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Reviewed-by: Bailey Forrest <bcf@google.com>
Link: https://lore.kernel.org/r/20220215051751.260866-1-haiyue.wang@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Colin Ian King [Tue, 15 Feb 2022 10:39:20 +0000 (10:39 +0000)]
net: dm9051: Fix spelling mistake "eror" -> "error"
There are spelling mistakes in debug messages. Fix them.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yang Li [Tue, 15 Feb 2022 01:09:13 +0000 (09:09 +0800)]
dpaa2-eth: Simplify bool conversion
Fix the following coccicheck warnings:
./drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:1199:42-47: WARNING:
conversion to bool not needed here
./drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:1218:54-59: WARNING:
conversion to bool not needed here
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Mon, 14 Feb 2022 23:36:46 +0000 (01:36 +0200)]
net: bridge: vlan: check for errors from __vlan_del in __vlan_flush
If the following call path returns an error from switchdev:
nbp_vlan_flush
-> __vlan_del
-> __vlan_vid_del
-> br_switchdev_port_vlan_del
-> __vlan_group_free
-> WARN_ON(!list_empty(&vg->vlan_list));
then the deletion of the net_bridge_vlan is silently halted, which will
trigger the WARN_ON from __vlan_group_free().
The WARN_ON is rather unhelpful, because nothing about the source of the
error is printed. Add a print to catch errors from __vlan_del.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christophe JAILLET [Mon, 14 Feb 2022 19:09:06 +0000 (20:09 +0100)]
net: hso: Use GFP_KERNEL instead of GFP_ATOMIC when possible
hso_create_device() is only called from function that already use
GFP_KERNEL. And all the callers are called from the probe function.
So there is no need here to explicitly require a GFP_ATOMIC when
allocating memory.
Use GFP_KERNEL instead.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Catanzaro [Sun, 13 Feb 2022 08:01:41 +0000 (02:01 -0600)]
virtio_net: Fix code indent error
This patch fixes the checkpatch.pl warning:
ERROR: code indent should use tabs where possible #3453: FILE: drivers/net/virtio_net.c:3453: ret = register_virtio_driver(&virtio_net_driver);$
Uneccessary newline was also removed making line 3453 now 3452.
Signed-off-by: Michael Catanzaro <mcatanzaro.kernel@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Tue, 15 Feb 2022 10:35:09 +0000 (10:35 +0000)]
Merge tag 'mlx5-updates-2022-02-14' of git://git./linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2022-02-14
mlx5 TX routines improvements
1) From Aya and Tariq, first 3 patches, Use the Max size of the TX descriptor
as advertised by the device and not the fixed value of 16 that the driver
always assumed, this is not a bug fix as all existing devices have Max value
larger than 16, but the series is necessary for future proofing the driver.
2) TX Synchronization improvements from Maxim, last 12 patches
Maxim Mikityanskiy Says:
=======================
mlx5e: Synchronize ndo_select_queue with configuration changes
The kernel can call ndo_select_queue at any time, and there is no direct
way to block it. The implementation of ndo_select_queue in mlx5e expects
the parameters to be consistent and may crash (invalid pointer, division
by zero) if they aren't.
There were attempts to partially fix some of the most frequent crashes,
see commit
846d6da1fcdb ("net/mlx5e: Fix division by 0 in
mlx5e_select_queue") and commit
84c8a87402cf ("net/mlx5e: Fix division
by 0 in mlx5e_select_queue for representors"). However, they don't
address the issue completely.
This series introduces the proper synchronization mechanism between
mlx5e configuration and TX data path:
1. txq2sq updates are synchronized properly with ndo_start_xmit
(mlx5e_xmit). The TX queue is stopped when it configuration is being
updated, and memory barriers ensure the changes are visible before
restarting.
2. The set of parameters needed for mlx5e_select_queue is reduced, and
synchronization using RCU is implemented. This way, changes are
atomic, and the state in mlx5e_select_queue is always consistent.
3. A few optimizations are applied to the new implementation of
mlx5e_select_queue.
=======================
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:53:00 +0000 (12:53 +0200)]
net/mlx5e: Optimize the common case condition in mlx5e_select_queue
Check all booleans for special queues at once, when deciding whether to
go to the fast path in mlx5e_select_queue. Pack them into bitfields to
have some room for extensibility.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:59 +0000 (12:52 +0200)]
net/mlx5e: Optimize modulo in mlx5e_select_queue
To improve the performance of the modulo operation (%), it's replaced by
a subtracting the divisor in a loop. The modulo is used to fix up an
out-of-bounds value that might be returned by netdev_pick_tx or to
convert the queue number to the channel number when num_tcs > 1. Both
situations are unlikely, because XPS is configured not to pick higher
queues (qid >= num_channels) by default, so under normal circumstances
the flow won't go inside the loop, and it will be faster than %.
num_tcs == 8 adds at most 7 iterations to the loop. PTP adds at most 1
iteration to the loop. HTB would add at most 256 iterations (when
num_channels == 1), so there is an additional boundary check in the HTB
flow, which falls back to % if more than 7 iterations are expected.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:57 +0000 (12:52 +0200)]
net/mlx5e: Optimize mlx5e_select_queue
This commit optimizes mlx5e_select_queue for HTB and PTP cases by
short-cutting some checks, without sacrificing performance of the common
non-HTB non-PTP flow.
1. The HTB flow uses the fact that num_tcs == 1 to drop these checks
(it's not possible to attach both mqprio and htb as the root qdisc).
It's also enough to calculate `txq_ix % num_channels` only once, instead
of twice.
2. The PTP flow drops the check for HTB and the second calculation of
`txq_ix % num_channels`.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:56 +0000 (12:52 +0200)]
net/mlx5e: Use READ_ONCE/WRITE_ONCE for DCBX trust state
trust_state can be written while mlx5e_select_queue() is reading it. To
avoid inconsistencies, use READ_ONCE and WRITE_ONCE for access and
updates, and touch the variable only once per operation.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:55 +0000 (12:52 +0200)]
net/mlx5e: Move repeating code that gets TC prio into a function
Both mlx5e_select_queue and mlx5e_select_ptpsq contain the same logic to
get user priority of a packet, according to the current trust state
settings. This commit moves this repeating code to its own function.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:54 +0000 (12:52 +0200)]
net/mlx5e: Use select queue parameters to sync with control flow
Start using the select queue parameters introduced in the previous
commit to have proper synchronization with changing the configuration
(such as number of channels and queues). It ensures that the state that
mlx5e_select_queue() sees is always consistent and stays the same while
the function is running. Also it allows mlx5e_select_queue to stop using
data structures that weren't synchronized properly: txq2sq,
channel_tc2realtxq, port_ptp_tc2realtxq. The last two are removed
completely, as they were used only in mlx5e_select_queue.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:52 +0000 (12:52 +0200)]
net/mlx5e: Move mlx5e_select_queue to en/selq.c
This commit moves mlx5e_select_queue and all stuff related to
ndo_select_queue to en/selq.c to put all stuff working with selq into a
separate file.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:51 +0000 (12:52 +0200)]
net/mlx5e: Introduce select queue parameters
ndo_select_queue can be called at any time, and there is no way to stop
the kernel from calling it to synchronize with configuration changes
(real_num_tx_queues, num_tc). This commit introduces an internal way in
mlx5e to sync mlx5e_select_queue() with these changes. The configuration
needed by this function is stored in a struct mlx5e_selq_params, which
is modified and accessed in an atomic way using RCU methods. The whole
ndo_select_queue is called under an RCU lock, providing the necessary
guarantees.
The parameters stored in the new struct mlx5e_selq_params should only be
used from inside mlx5e_select_queue. It's the minimal set of parameters
needed for mlx5e_select_queue to do its job efficiently, derived from
parameters stored elsewhere. That means that when the configuration
change, mlx5e_selq_params may need to be updated. In such cases, the
mlx5e_selq_prepare/mlx5e_selq_apply API should be used.
struct mlx5e_selq contains two slots for the params: active and standby.
mlx5e_selq_prepare updates the standby slot, and mlx5e_selq_apply swaps
the slots in a safe atomic way using the RCU API. It integrates well
with the open/activate stages of the configuration change flow.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:50 +0000 (12:52 +0200)]
net/mlx5e: Sync txq2sq updates with mlx5e_xmit for HTB queues
This commit makes necessary changes to guarantee that txq2sq remains
stable while mlx5e_xmit is running. Proper synchronization is added for
HTB TX queues.
All updates to txq2sq are performed while the corresponding queue is
disabled (i.e. mlx5e_xmit doesn't run on that queue). smp_wmb after each
change guarantees that mlx5e_xmit can see the updated value after the
queue is enabled. Comments explaining this mechanism are added to
mlx5e_xmit.
When an HTB SQ can be deleted (after deleting an HTB node), synchronize
with RCU to wait for mlx5e_select_queue to finish and stop selecting
that queue, before we re-enable it to avoid TX timeout watchdog alarms.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:49 +0000 (12:52 +0200)]
net/mlx5e: Use a barrier after updating txq2sq
mlx5e_build_txq_maps updates txq2sq while TX queues are stopped. Add a
barrier to ensure that these changes are visible before the queues are
started and mlx5e_xmit reads from txq2sq.
This commit handles regular TX queues. Synchronization between HTB TX
queues and mlx5e_xmit is handled in the following commit.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:48 +0000 (12:52 +0200)]
net/mlx5e: Disable TX queues before registering the netdev
Normally, the queues are disabled when the channels are deactivated, and
enabled when the channels are activated. However, on register, the
channels are not active, but the queues are enabled by default. This
change fixes it, preventing mlx5e_xmit from running when the channels
are deactivated in the beginning.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Maxim Mikityanskiy [Tue, 25 Jan 2022 10:52:43 +0000 (12:52 +0200)]
net/mlx5e: Cleanup of start/stop all queues
mlx5e_activate_priv_channels() and mlx5e_deactivate_priv_channels()
start and stop all netdev TX queues. This commit removes the unneeded
call to netif_tx_stop_all_queues and adds explanatory comments why these
operations are needed.
netif_tx_disable() does the same thing that netif_tx_stop_all_queues(),
but taking the TX lock, thus guaranteeing that ndo_start_xmit is not
running after return. That means that the netif_tx_stop_all_queues()
call is not really necessary.
The comments are improved: the TX watchdog timeout explanation is moved
to the start stage where it really belongs (it used to be in both
places, but was lost during some old refactoring) and rephrased in more
details; the explanation for stopping all TX queues is added.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Aya Levin [Mon, 10 May 2021 07:13:06 +0000 (10:13 +0300)]
net/mlx5e: Use FW limitation for max MPW WQEBBs
Calculate maximal count of MPW WQEBBs on SQ's creation and store it
there. Remove MLX5E_TX_MPW_MAX_NUM_DS and MLX5E_TX_MPW_MAX_WQEBBS.
Update mlx5e_tx_mpwqe_is_full() and mlx5e_xdp_mpqwe_is_full() .
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Aya Levin [Mon, 17 Jan 2022 09:46:35 +0000 (11:46 +0200)]
net/mlx5e: Read max WQEBBs on the SQ from firmware
Prior to this patch the maximal value for max WQEBBs (WQE Basic Blocks,
where WQE is a Work Queue Element) on the TX side was assumed to be 16
(fixed value). All firmware versions till today comply to this. In order
to be more flexible and resilient, read from FW the corresponding:
max_wqe_sz_sq. This value describes the maximum WQE size given in bytes,
thus max WQEBBs is given by the division in WQEBB's byte size. The
driver uses the top between 16 and the division result. This ensures
synchronization between driver and firmware and avoids unexpected
behavior. Store this value on the different SQs (Send Queues) for easy
access.
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Tariq Toukan [Thu, 20 May 2021 09:31:44 +0000 (12:31 +0300)]
net/mlx5e: Remove unused tstamp SQ field
Remove tstamp pointer in mlx5e_txqsq as it's no longer used after
commit
7c39afb394c7 ("net/mlx5: PTP code migration to driver core section").
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Aya Levin <ayal@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Tobias Waldekranz [Sun, 13 Feb 2022 18:51:54 +0000 (19:51 +0100)]
net: dsa: mv88e6xxx: Fix validation of built-in PHYs on 6095/6097
These chips have 8 built-in FE PHYs and 3 SERDES interfaces that can
run at 1G. With the blamed commit, the built-in PHYs could no longer
be connected to, using an MII PHY interface mode.
Create a separate .phylink_get_caps callback for these chips, which
takes the FE/GE split into consideration.
Fixes:
2ee84cfefb1e ("net: dsa: mv88e6xxx: convert to phylink_generic_validate()")
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/20220213185154.3262207-1-tobias@waldekranz.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Colin Ian King [Mon, 14 Feb 2022 09:38:10 +0000 (09:38 +0000)]
selftests: net: cmsg_sender: Fix spelling mistake "MONOTINIC" -> "MONOTONIC"
There is a spelling mistake in an error message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Volodymyr Mytnyk [Mon, 14 Feb 2022 08:20:06 +0000 (10:20 +0200)]
net: prestera: acl: add multi-chain support offload
Add support of rule offloading added to the non-zero index chain,
which was previously forbidden. Also, goto action is offloaded
allowing to jump for processing of desired chain.
Note that only implicit chain 0 is bound to the device port(s) for
processing. The rest of chains have to be jumped by actions.
Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 14 Feb 2022 14:09:59 +0000 (14:09 +0000)]
Merge branch 'wwan-debugfs'
M Chetan Kumar says:
====================
net: wwan: debugfs dev reference not dropped
This patch series contains WWAN subsystem & IOSM Driver changes to
drop dev reference obtained as part of wwan debugfs dir entry retrieval.
PATCH1: A new debugfs interface is introduced in wwan subsystem so
that wwan driver can drop the obtained dev reference post debugfs use.
PATCH2: IOSM Driver uses new debugfs interface to drop dev reference.
Please refer to commit messages for details.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
M Chetan Kumar [Mon, 14 Feb 2022 07:16:53 +0000 (12:46 +0530)]
net: wwan: iosm: drop debugfs dev reference
Post debugfs use call wwan_put_debugfs_dir()to drop
debugfs dev reference.
Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
M Chetan Kumar [Mon, 14 Feb 2022 07:16:52 +0000 (12:46 +0530)]
net: wwan: debugfs obtained dev reference not dropped
WWAN driver call's wwan_get_debugfs_dir() to obtain
WWAN debugfs dir entry. As part of this procedure it
returns a reference to a found device.
Since there is no debugfs interface available at WWAN
subsystem, it is not possible to drop dev reference post
debugfs use. This leads to side effects like post wwan
driver load and reload the wwan instance gets increment
from wwanX to wwanX+1.
A new debugfs interface is added in wwan subsystem so that
wwan driver can drop the obtained dev reference post debugfs
use.
void wwan_put_debugfs_dir(struct dentry *dir)
Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 14 Feb 2022 14:06:11 +0000 (14:06 +0000)]
Merge branch 'dsa-realtek-next'
Luiz Angelo Daros de Luca says:
====================
net: dsa: realtek: realtek-mdio: reset before setup
This patch series cleans the realtek-smi reset code and copy that to the
realtek-mdio.
v1-v2)
- do not run reset code block if GPIO is missing. It was printing "RESET
deasserted" even when there is no GPIO configured.
- reset switch after dsa_unregister_switch()
- demote reset messages to debug
v2-v3)
- do not assert the reset on gpiod_get. Do it explicitly aferwards.
- split the commit into two (one for each module)
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Mon, 14 Feb 2022 02:20:12 +0000 (23:20 -0300)]
net: dsa: realtek: realtek-mdio: reset before setup
Some devices, like the switch in Banana Pi BPI R64 only starts to answer
after a HW reset. It is the same reset code from realtek-smi.
Reported-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Tested-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Mon, 14 Feb 2022 02:20:11 +0000 (23:20 -0300)]
net: dsa: realtek: realtek-smi: clean-up reset
When reset GPIO was missing, the driver was still printing an info
message and still trying to assert the reset. Although gpiod_set_value()
will silently ignore calls with NULL gpio_desc, it is better to make it
clear the driver might allow gpio_desc to be NULL.
The initial value for the reset pin was changed to GPIOD_OUT_LOW,
followed by a gpiod_set_value() asserting the reset. This way, it will
be easier to spot if and where the reset really happens.
A new "asserted RESET" message was added just after the reset is
asserted, similar to the existing "deasserted RESET" message. Both
messages were demoted to dbg. The code comment is not needed anymore.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Mon, 14 Feb 2022 02:10:56 +0000 (18:10 -0800)]
ipv6: blackhole_netdev needs snmp6 counters
Whenever rt6_uncached_list_flush_dev() swaps rt->rt6_idev
to the blackhole device, parts of IPv6 stack might still need
to increment one SNMP counter.
Root cause, patch from Ido, changelog from Eric :)
This bug suggests that we need to audit rt->rt6_idev usages
and make sure they are properly using RCU protection.
Fixes:
e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Sat, 12 Feb 2022 02:25:34 +0000 (23:25 -0300)]
net: dsa: realtek: rename macro to match filename
The macro was missed while renaming realtek-smi.h to realtek.h.
Fixes:
f5f119077b1c (net: dsa: realtek: rename realtek_smi to)
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 14 Feb 2022 13:38:36 +0000 (13:38 +0000)]
Merge branch 'netdev-RT'
Sebastian Andrzej Siewior says:
====================
net: dev: PREEMPT_RT fixups.
this series removes or replaces preempt_disable() and local_irq_save()
sections which are problematic on PREEMPT_RT.
Patch 2 makes netif_rx() work from any context after I found suggestions
for it in an old thread. Should that work, then the context-specific
variants could be removed.
v2…v3:
- #2
- Export __netif_rx() so it can be used by everyone.
- Add a lockdep assert to check for interrupt context.
- Update the kernel doc and mention that the skb is posted to
backlog NAPI.
- Use __netif_rx() also in drivers/net/*.c.
- Added Toke''s review tag and kept Eric's desptite the changes
made.
v1…v2:
- #1 and #2
- merge patch 1 und 2 from the series (as per Toke).
- updated patch description and corrected the first commit number (as
per Eric).
- #2
- Provide netif_rx() as in v1 and additionally __netif_rx() without
local_bh disable()+enable() for the loopback driver. __netif_rx() is
not exported (loopback is built-in only) so it won't be used
drivers. If this doesn't work then we can still export/ define a
wrapper as Eric suggested.
- Added a comment that netif_rx() considered legacy.
- #3
- Moved ____napi_schedule() into rps_ipi_queued() and
renamed it napi_schedule_rps().
https://lore.kernel.org/all/
20220204201259.
1095226-1-bigeasy@linutronix.de/
v1:
https://lore.kernel.org/all/
20220202122848.647635-1-bigeasy@linutronix.de
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Sebastian Andrzej Siewior [Fri, 11 Feb 2022 23:38:39 +0000 (00:38 +0100)]
net: dev: Make rps_lock() disable interrupts.
Disabling interrupts and in the RPS case locking input_pkt_queue is
split into local_irq_disable() and optional spin_lock().
This breaks on PREEMPT_RT because the spinlock_t typed lock can not be
acquired with disabled interrupts.
The sections in which the lock is acquired is usually short in a sense that it
is not causing long und unbounded latiencies. One exception is the
skb_flow_limit() invocation which may invoke a BPF program (and may
require sleeping locks).
By moving local_irq_disable() + spin_lock() into rps_lock(), we can keep
interrupts disabled on !PREEMPT_RT and enabled on PREEMPT_RT kernels.
Without RPS on a PREEMPT_RT kernel, the needed synchronisation happens
as part of local_bh_disable() on the local CPU.
____napi_schedule() is only invoked if sd is from the local CPU. Replace
it with __napi_schedule_irqoff() which already disables interrupts on
PREEMPT_RT as needed. Move this call to rps_ipi_queued() and rename the
function to napi_schedule_rps as suggested by Jakub.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sebastian Andrzej Siewior [Fri, 11 Feb 2022 23:38:38 +0000 (00:38 +0100)]
net: dev: Makes sure netif_rx() can be invoked in any context.
Dave suggested a while ago (eleven years by now) "Let's make netif_rx()
work in all contexts and get rid of netif_rx_ni()". Eric agreed and
pointed out that modern devices should use netif_receive_skb() to avoid
the overhead.
In the meantime someone added another variant, netif_rx_any_context(),
which behaves as suggested.
netif_rx() must be invoked with disabled bottom halves to ensure that
pending softirqs, which were raised within the function, are handled.
netif_rx_ni() can be invoked only from process context (bottom halves
must be enabled) because the function handles pending softirqs without
checking if bottom halves were disabled or not.
netif_rx_any_context() invokes on the former functions by checking
in_interrupts().
netif_rx() could be taught to handle both cases (disabled and enabled
bottom halves) by simply disabling bottom halves while invoking
netif_rx_internal(). The local_bh_enable() invocation will then invoke
pending softirqs only if the BH-disable counter drops to zero.
Eric is concerned about the overhead of BH-disable+enable especially in
regard to the loopback driver. As critical as this driver is, it will
receive a shortcut to avoid the additional overhead which is not needed.
Add a local_bh_disable() section in netif_rx() to ensure softirqs are
handled if needed.
Provide __netif_rx() which does not disable BH and has a lockdep assert
to ensure that interrupts are disabled. Use this shortcut in the
loopback driver and in drivers/net/*.c.
Make netif_rx_ni() and netif_rx_any_context() invoke netif_rx() so they
can be removed once they are no more users left.
Link: https://lkml.kernel.org/r/20100415.020246.218622820.davem@davemloft.net
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sebastian Andrzej Siewior [Fri, 11 Feb 2022 23:38:37 +0000 (00:38 +0100)]
net: dev: Remove preempt_disable() and get_cpu() in netif_rx_internal().
The preempt_disable() () section was introduced in commit
cece1945bffcf ("net: disable preemption before call smp_processor_id()")
and adds it in case this function is invoked from preemtible context and
because get_cpu() later on as been added.
The get_cpu() usage was added in commit
b0e28f1effd1d ("net: netif_rx() must disable preemption")
because ip_dev_loopback_xmit() invoked netif_rx() with enabled preemption
causing a warning in smp_processor_id(). The function netif_rx() should
only be invoked from an interrupt context which implies disabled
preemption. The commit
e30b38c298b55 ("ip: Fix ip_dev_loopback_xmit()")
was addressing this and replaced netif_rx() with in netif_rx_ni() in
ip_dev_loopback_xmit().
Based on the discussion on the list, the former patch (
b0e28f1effd1d)
should not have been applied only the latter (
e30b38c298b55).
Remove get_cpu() and preempt_disable() since the function is supposed to
be invoked from context with stable per-CPU pointers. Bottom halves have
to be disabled at this point because the function may raise softirqs
which need to be processed.
Link: https://lkml.kernel.org/r/20100415.013347.98375530.davem@davemloft.net
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Ertman [Fri, 11 Feb 2022 18:26:03 +0000 (10:26 -0800)]
ice: Simplify tracking status of RDMA support
The status of support for RDMA is currently being tracked with two
separate status flags. This is unnecessary with the current state of
the driver.
Simplify status tracking down to a single flag.
Rename the helper function to denote the RDMA specific status and
universally use the helper function to test the status bit.
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Tested-by: Leszek Kaliszczuk <leszek.kaliszczuk@intel.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 14 Feb 2022 13:24:29 +0000 (13:24 +0000)]
Merge branch 'ocelot-stats'
Colin Foster says:
====================
use bulk reads for ocelot statistics
Ocelot loops over memory regions to gather stats on different ports.
These regions are mostly continuous, and are ordered. This patch set
uses that information to break the stats reads into regions that can get
read in bulk.
The motiviation is for general cleanup, but also for SPI. Performing two
back-to-back reads on a SPI bus require toggling the CS line, holding,
re-toggling the CS line, sending 3 address bytes, sending N padding
bytes, then actually performing the read. Bulk reads could reduce almost
all of that overhead, but require that the reads are performed via
regmap_bulk_read.
Verified with eth0 hooked up to the CPU port:
NIC statistics:
Good Rx Frames: 905
Rx Octets: 78848
Good Tx Frames: 691
Tx Octets: 52516
Rx + Tx 65-127 Octet Frames: 1574
Rx + Tx 128-255 Octet Frames: 22
Net Octets: 131364
Rx DMA chan 0: head_enqueue: 1
Rx DMA chan 0: tail_enqueue: 1032
Rx DMA chan 0: busy_dequeue: 628
Rx DMA chan 0: good_dequeue: 905
Tx DMA chan 0: head_enqueue: 346
Tx DMA chan 0: tail_enqueue: 345
Tx DMA chan 0: misqueued: 345
Tx DMA chan 0: empty_dequeue: 346
Tx DMA chan 0: good_dequeue: 691
p00_rx_octets: 52516
p00_rx_unicast: 691
p00_rx_frames_65_to_127_octets: 691
p00_tx_octets: 78848
p00_tx_unicast: 905
p00_tx_frames_65_to_127_octets: 883
p00_tx_frames_128_255_octets: 22
p00_tx_green_prio_0: 905
And with swp2 connected to swp3 with STP enabled:
NIC statistics:
tx_packets: 379
tx_bytes: 19708
rx_packets: 1
rx_bytes: 46
rx_octets: 64
rx_multicast: 1
rx_frames_below_65_octets: 1
rx_classified_drops: 1
tx_octets: 44630
tx_multicast: 387
tx_broadcast: 290
tx_frames_below_65_octets: 379
tx_frames_65_to_127_octets: 294
tx_frames_128_255_octets: 4
tx_green_prio_0: 298
tx_green_prio_7: 379
NIC statistics:
tx_packets: 1
tx_bytes: 52
rx_packets: 713
rx_bytes: 34148
rx_octets: 46982
rx_multicast: 407
rx_broadcast: 306
rx_frames_below_65_octets: 399
rx_frames_65_to_127_octets: 310
rx_frames_128_to_255_octets: 4
rx_classified_drops: 399
rx_green_prio_0: 314
tx_octets: 64
tx_multicast: 1
tx_frames_below_65_octets: 1
tx_green_prio_7: 1
v1 > v2: reword commit messages
v2 > v3: correctly mark this for net-next when sending
v3 > v4: calloc array instead of zalloc per review
v4 > v5:
Apply CR suggestions for whitespace
Fix calloc / zalloc mixup
Properly destroy workqueues
Add third commit to split long macros
v5 > v6:
Fix functionality - v5 was improperly tested
Add bugfix for ethtool mutex lock
Remove unnecessary ethtool stats reads
v6 > v7:
Remove mutex bug patch that was applied via net
Rename function based on CR
Add missed error check
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Colin Foster [Sun, 13 Feb 2022 19:12:54 +0000 (11:12 -0800)]
net: mscc: ocelot: use bulk reads for stats
Create and utilize bulk regmap reads instead of single access for gathering
stats. The background reading of statistics happens frequently, and over
a few contiguous memory regions.
High speed PCIe buses and MMIO access will probably see negligible
performance increase. Lower speed buses like SPI and I2C could see
significant performance increase, since the bus configuration and register
access times account for a large percentage of data transfer time.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Colin Foster [Sun, 13 Feb 2022 19:12:53 +0000 (11:12 -0800)]
net: mscc: ocelot: add ability to perform bulk reads
Regmap supports bulk register reads. Ocelot does not. This patch adds
support for Ocelot to invoke bulk regmap reads. That will allow any driver
that performs consecutive reads over memory regions to optimize that
access.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Colin Foster [Sun, 13 Feb 2022 19:12:52 +0000 (11:12 -0800)]
net: ocelot: align macros for consistency
In the ocelot.h file, several read / write macros were split across
multiple lines, while others weren't. Split all macros that exceed the 80
character column width and match the style of the rest of the file.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Colin Foster [Sun, 13 Feb 2022 19:12:51 +0000 (11:12 -0800)]
net: mscc: ocelot: remove unnecessary stat reading from ethtool
The ocelot_update_stats function only needs to read from one port, yet it
was updating the stats for all ports. Update to only read the stats that
are necessary.
Signed-off-by: Colin Foster <colin.foster@in-advantage.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Fri, 11 Feb 2022 17:15:07 +0000 (09:15 -0800)]
ipv6: Add reasons for skb drops to __udp6_lib_rcv
Add reasons to __udp6_lib_rcv for skb drops. The only twist is that the
NO_SOCKET takes precedence over the CSUM or other counters for that
path (motivation behind this patch - csum counter was misleading).
Signed-off-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 14 Feb 2022 11:18:47 +0000 (11:18 +0000)]
Merge branch 'dm9051'
Joseph CHAMG says:
====================
ADD DM9051 ETHERNET DRIVER
DM9051 is a spi interface chip,
need cs/mosi/miso/clock with an interrupt gpio pin
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Joseph CHAMG [Fri, 11 Feb 2022 09:27:56 +0000 (17:27 +0800)]
net: Add dm9051 driver
Add davicom dm9051 spi ethernet driver, The driver work for the
device platform which has the spi master
Signed-off-by: Joseph CHAMG <josright123@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Joseph CHAMG [Fri, 11 Feb 2022 09:27:55 +0000 (17:27 +0800)]
dt-bindings: net: Add Davicom dm9051 SPI ethernet controller
This is a new yaml base data file for configure davicom dm9051 with
device tree
Signed-off-by: Joseph CHAMG <josright123@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tony Lu [Fri, 11 Feb 2022 06:52:21 +0000 (14:52 +0800)]
net/smc: Add comment for smc_tx_pending
The previous patch introduces a lock-free version of smc_tx_work() to
solve unnecessary lock contention, which is expected to be held lock.
So this adds comment to remind people to keep an eye out for locks.
Suggested-by: Stefan Raspl <raspl@linux.ibm.com>
Signed-off-by: Tony Lu <tonylu@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kalash Nainwal [Thu, 10 Feb 2022 22:09:35 +0000 (14:09 -0800)]
Generate netlink notification when default IPv6 route preference changes
Generate RTM_NEWROUTE netlink notification when the route preference
changes on an existing kernel generated default route in response to
RA messages. Currently netlink notifications are generated only when
this route is added or deleted but not when the route preference
changes, which can cause userspace routing application state to go
out of sync with kernel.
Signed-off-by: Kalash Nainwal <kalash@arista.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Davide Caratti [Thu, 10 Feb 2022 17:56:08 +0000 (18:56 +0100)]
net/sched: act_police: more accurate MTU policing
in current Linux, MTU policing does not take into account that packets at
the TC ingress have the L2 header pulled. Thus, the same TC police action
(with the same value of tcfp_mtu) behaves differently for ingress/egress.
In addition, the full GSO size is compared to tcfp_mtu: as a consequence,
the policer drops GSO packets even when individual segments have the L2 +
L3 + L4 + payload length below the configured valued of tcfp_mtu.
Improve the accuracy of MTU policing as follows:
- account for mac_len for non-GSO packets at TC ingress.
- compare MTU threshold with the segmented size for GSO packets.
Also, add a kselftest that verifies the correct behavior.
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kees Cook [Sat, 12 Feb 2022 17:14:49 +0000 (09:14 -0800)]
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
With GCC 12, -Wstringop-overread was warning about an implicit cast from
char[6] to char[8]. However, the extra 2 bytes are always thrown away,
alignment doesn't matter, and the risk of hitting the edge of unallocated
memory has been accepted, so this prototype can just be converted to a
regular char *. Silences:
net/core/dev.c: In function ‘bpf_prog_run_generic_xdp’: net/core/dev.c:4618:21: warning: ‘ether_addr_equal_64bits’ reading 8 bytes from a region of size 6 [-Wstringop-overread]
4618 | orig_host = ether_addr_equal_64bits(eth->h_dest, > skb->dev->dev_addr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/core/dev.c:4618:21: note: referencing argument 1 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’}
net/core/dev.c:4618:21: note: referencing argument 2 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’}
In file included from net/core/dev.c:91: include/linux/etherdevice.h:375:20: note: in a call to function ‘ether_addr_equal_64bits’
375 | static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
| ^~~~~~~~~~~~~~~~~~~~~~~
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/netdev/20220212090811.uuzk6d76agw2vv73@pengutronix.de
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Horatiu Vultur [Sat, 12 Feb 2022 20:03:43 +0000 (21:03 +0100)]
net: lan966x: Fix when CONFIG_IPV6 is not set
When CONFIG_IPV6 is not set, then the linking of the lan966x driver
fails with the following error:
drivers/net/ethernet/microchip/lan966x/lan966x_main.c:444: undefined
reference to `ipv6_mc_check_mld'
The fix consists in adding a check also for IS_ENABLED(CONFIG_IPV6)
Fixes:
47aeea0d57e80c ("net: lan966x: Implement the callback SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Horatiu Vultur [Sat, 12 Feb 2022 20:45:44 +0000 (21:45 +0100)]
net: lan966x: Fix when CONFIG_PTP_1588_CLOCK is compiled as module
When CONFIG_PTP_1588_CLOCK is compiled as a module, then the linking of
the lan966x fails because it can't find references to the following
functions 'ptp_clock_index', 'ptp_clock_register' and
'ptp_clock_unregister'
The fix consists in adding CONFIG_PTP_1588_CLOCK_OPTIONAL as a
dependency for the driver.
Fixes:
d096459494a887 ("net: lan966x: Add support for ptp clocks")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sun, 13 Feb 2022 12:07:26 +0000 (12:07 +0000)]
Merge branch 'lan743x-enhancements'
Raju Lakkaraju says:
====================
net: lan743x: PCI11010 / PCI11414 devices Enhancements
This patch series adds support of the Ethernet function of the PCI11010 / PCI11414 devices to the LAN743x driver.
The PCI1xxxx family of devices consists of a PCIe switch with a variety of embedded PCI endpoints on its downstream ports.
The PCI11010 / PCI11414 devices include an Ethernet 10/100/1000/2500 function as one of those embedded endpoints.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Raju Lakkaraju [Sat, 12 Feb 2022 15:53:15 +0000 (21:23 +0530)]
net: lan743x: Add support for Clause-45 MDIO PHY management
Add support for Clause-45 MDIO PHY management
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Raju Lakkaraju [Sat, 12 Feb 2022 15:53:14 +0000 (21:23 +0530)]
net: lan743x: Add support for SGMII interface
This change facilitates the selection between SGMII and (R)GIII
interfaces
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Raju Lakkaraju [Sat, 12 Feb 2022 15:53:13 +0000 (21:23 +0530)]
net: lan743x: Increase MSI(x) vectors to 16 and Int de-assertion timers to 10
Increase MSI / MSI-X vectors supported from 8 to 16 and
Interrupt De-assertion timers from 8 to 10
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Raju Lakkaraju [Sat, 12 Feb 2022 15:53:12 +0000 (21:23 +0530)]
net: lan743x: Add support for 4 Tx queues
Add support for 4 Tx queues
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Raju Lakkaraju [Sat, 12 Feb 2022 15:53:11 +0000 (21:23 +0530)]
net: lan743x: Add PCI11010 / PCI11414 device IDs
PCI11010/PCI11414 devices are enhancement of Ethernet LAN743x chip family.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
M Chetan Kumar [Thu, 10 Feb 2022 15:34:45 +0000 (21:04 +0530)]
net: wwan: iosm: Enable M.2 7360 WWAN card support
This patch enables Intel M.2 7360 WWAN card support on
IOSM Driver.
Control path implementation is a reuse whereas data path
implementation it uses a different protocol called as MUX
Aggregation. The major portion of this patch covers the MUX
Aggregation protocol implementation used for IP traffic
communication.
For M.2 7360 WWAN card, driver exposes 2 wwan AT ports for
control communication. The user space application or the
modem manager to use wwan AT port for data path establishment.
During probe, driver reads the mux protocol device capability
register to know the mux protocol version supported by device.
Base on which the right mux protocol is initialized for data
path communication.
An overview of an Aggregation Protocol
1> An IP packet is encapsulated with 16 octet padding header
to form a Datagram & the start offset of the Datagram is
indexed into Datagram Header (DH).
2> Multiple such Datagrams are composed & the start offset of
each DH is indexed into Datagram Table Header (DTH).
3> The Datagram Table (DT) is IP session specific & table_length
item in DTH holds the number of composed datagram pertaining
to that particular IP session.
4> And finally the offset of first DTH is indexed into DBH (Datagram
Block Header).
So in TX/RX flow Datagram Block (Datagram Block Header + Payload)is
exchanged between driver & device.
Signed-off-by: M Chetan Kumar <m.chetan.kumar@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 11 Feb 2022 02:05:44 +0000 (18:05 -0800)]
Revert "net: ethernet: cavium: use div64_u64() instead of do_div()"
This reverts commit
038fcdaf0470de89619bc4cc199e329391e6566c.
Christophe points out div64_u64() and do_div() have different
calling conventions. One updates the param, the other returns
the result.
Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/all/056a7276-c6f0-cd7e-9e46-1d8507a0b6b1@wanadoo.fr/
Fixes:
038fcdaf0470 ("net: ethernet: cavium: use div64_u64() instead of do_div()")
Link: https://lore.kernel.org/r/20220211020544.3262694-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Julia Lawall [Thu, 10 Feb 2022 20:42:15 +0000 (21:42 +0100)]
net: moxa: use GFP_KERNEL
Platform_driver probe functions aren't called with locks
held and thus don't need GFP_ATOMIC. Use GFP_KERNEL instead.
Problem found with Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/20220210204223.104181-1-Julia.Lawall@inria.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hariprasad Kelam [Fri, 11 Feb 2022 15:55:39 +0000 (21:25 +0530)]
octeontx2-af: fix array bound error
This patch fixes below error by using proper data type.
drivers/net/ethernet/marvell/octeontx2/af/rpm.c: In function
'rpm_cfg_pfc_quanta_thresh':
include/linux/find.h:40:23: error: array subscript 'long unsigned
int[0]' is partly outside array bounds of 'u16[1]' {aka 'short unsigned
int[1]'} [-Werror=array-bounds]
40 | val = *addr & GENMASK(size - 1, offset);
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Link: https://lore.kernel.org/r/20220211155539.13931-1-hkelam@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David S. Miller [Fri, 11 Feb 2022 14:19:23 +0000 (14:19 +0000)]
Merge tag 'wireless-next-2022-02-11' of git://git./linux/kernel/git/wireless/wireless-next
wireless-next patches for v5.18
First set of patches for v5.18, with both wireless and stack patches.
rtw89 now has AP mode support and wcn36xx has survey support. But
otherwise pretty normal.
Major changes:
ath11k
* add LDPC FEC type in 802.11 radiotap header
* enable RX PPDU stats in monitor co-exist mode
wcn36xx
* implement survey reporting
brcmfmac
* add CYW43570 PCIE device
rtw88
* rtw8821c: enable RFE 6 devices
rtw89
* AP mode support
mt76
* mt7916 support
* background radar detection support
David S. Miller [Fri, 11 Feb 2022 11:44:27 +0000 (11:44 +0000)]
Merge branch 'ipv6-loopback'
Eric Dumazet says:
====================
ipv6: remove addrconf reliance on loopback
Second patch in this series removes IPv6 requirement about the netns
loopback device being the last device being dismantled.
This was needed because rt6_uncached_list_flush_dev()
and ip6_dst_ifdown() had to switch dst dev to a known
device (loopback).
Instead of loopback, we can use the (hidden) blackhole_netdev
which is also always there.
This will allow future simplfications of netdev_run_to()
and other parts of the stack like default_device_exit_batch().
Last two patches are optimizations for both IP families.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Thu, 10 Feb 2022 21:42:31 +0000 (13:42 -0800)]
ipv4: add (struct uncached_list)->quarantine list
This is an optimization to keep the per-cpu lists as short as possible:
Whenever rt_flush_dev() changes one rtable dst.dev
matching the disappearing device, it can can transfer the object
to a quarantine list, waiting for a final rt_del_uncached_list().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Thu, 10 Feb 2022 21:42:30 +0000 (13:42 -0800)]
ipv6: add (struct uncached_list)->quarantine list
This is an optimization to keep the per-cpu lists as short as possible:
Whenever rt6_uncached_list_flush_dev() changes one rt6_info
matching the disappearing device, it can can transfer the object
to a quarantine list, waiting for a final rt6_uncached_list_del().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Thu, 10 Feb 2022 21:42:29 +0000 (13:42 -0800)]
ipv6: give an IPv6 dev to blackhole_netdev
IPv6 addrconf notifiers wants the loopback device to
be the last device being dismantled at netns deletion.
This caused many limitations and work arounds.
Back in linux-5.3, Mahesh added a per host blackhole_netdev
that can be used whenever we need to make sure objects no longer
refer to a disappearing device.
If we attach to blackhole_netdev an ip6_ptr (allocate an idev),
then we can use this special device (which is never freed)
in place of the loopback_dev (which can be freed).
This will permit improvements in netdev_run_todo() and other parts
of the stack where had steps to make sure loopback_dev was
the last device to disappear.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Thu, 10 Feb 2022 21:42:28 +0000 (13:42 -0800)]
ipv6: get rid of net->ipv6.rt6_stats->fib_rt_uncache
This counter has never been visible, there is little point
trying to maintain it.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Holger Brunck [Thu, 10 Feb 2022 17:48:23 +0000 (18:48 +0100)]
dsa: mv88e6xxx: make serdes SGMII/Fiber tx amplitude configurable
The mv88e6352, mv88e6240 and mv88e6176 have a serdes interface. This patch
allows to configure the output swing to a desired value in the
phy-handle of the port. The value which is peak to peak has to be
specified in microvolts. As the chips only supports eight dedicated
values we return EINVAL if the value in the DTS does not match one of
these values.
Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Marek Behún <kabel@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Marek Behún [Thu, 10 Feb 2022 17:48:22 +0000 (18:48 +0100)]
dt-bindings: phy: Add `tx-p2p-microvolt` property binding
Common PHYs and network PCSes often have the possibility to specify
peak-to-peak voltage on the differential pair - the default voltage
sometimes needs to be changed for a particular board.
Add properties `tx-p2p-microvolt` and `tx-p2p-microvolt-names` for this
purpose. The second property is needed to specify the mode for the
corresponding voltage in the `tx-p2p-microvolt` property, if the voltage
is to be used only for speficic mode. More voltage-mode pairs can be
specified.
Example usage with only one voltage (it will be used for all supported
PHY modes, the `tx-p2p-microvolt-names` property is not needed in this
case):
tx-p2p-microvolt = <915000>;
Example usage with voltages for multiple modes:
tx-p2p-microvolt = <915000>, <
1100000>, <
1200000>;
tx-p2p-microvolt-names = "2500base-x", "usb", "pcie";
Add these properties into a separate file phy/transmit-amplitude.yaml,
which should be referenced by any binding that uses it.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Guillaume Nault [Thu, 10 Feb 2022 15:08:08 +0000 (16:08 +0100)]
ipv6: Reject routes configurations that specify dsfield (tos)
The ->rtm_tos option is normally used to route packets based on both
the destination address and the DS field. However it's ignored for
IPv6 routes. Setting ->rtm_tos for IPv6 is thus invalid as the route
is going to work only on the destination address anyway, so it won't
behave as specified.
Suggested-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 11 Feb 2022 11:17:33 +0000 (11:17 +0000)]
Merge branch 'dsa-cleanup'
Vladimir Oltean says:
====================
More aggressive DSA cleanup
This series deletes some code which is apparently not needed.
I've had these patches in my tree for a while, and testing on my boards
didn't reveal any issues.
Compared to the RFC v1 series, the only change is the addition of patch 3.
https://patchwork.kernel.org/project/netdevbpf/cover/
20220107184842.550334-1-vladimir.oltean@nxp.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Thu, 10 Feb 2022 13:45:00 +0000 (15:45 +0200)]
net: dsa: remove lockdep class for DSA slave address list
Since commit
2f1e8ea726e9 ("net: dsa: link interfaces with the DSA
master to get rid of lockdep warnings"), suggested by Cong Wang, the
DSA interfaces and their master have different dev->nested_level, which
makes netif_addr_lock() stop complaining about potentially recursive
locking on the same lock class.
So we no longer need DSA slave interfaces to have their own lockdep
class.
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Thu, 10 Feb 2022 13:44:59 +0000 (15:44 +0200)]
net: dsa: remove lockdep class for DSA master address list
Since commit
2f1e8ea726e9 ("net: dsa: link interfaces with the DSA
master to get rid of lockdep warnings"), suggested by Cong Wang, the
DSA interfaces and their master have different dev->nested_level, which
makes netif_addr_lock() stop complaining about potentially recursive
locking on the same lock class.
So we no longer need DSA masters to have their own lockdep class.
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Thu, 10 Feb 2022 13:44:58 +0000 (15:44 +0200)]
net: dsa: remove ndo_get_phys_port_name and ndo_get_port_parent_id
There are no legacy ports, DSA registers a devlink instance with ports
unconditionally for all switch drivers. Therefore, delete the old-style
ndo operations used for determining bridge forwarding domains.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 11 Feb 2022 11:14:58 +0000 (11:14 +0000)]
Merge branch 'smc-optimizations'
D. Wythe says:
====================
net/smc: Optimizing performance in short-lived scenarios
This patch set aims to optimizing performance of SMC in short-lived
links scenarios, which is quite unsatisfactory right now.
In our benchmark, we test it with follow scripts:
./wrk -c 10000 -t 4 -H 'Connection: Close' -d 20 http://smc-server
Current performance figures like that:
Running 20s test @ http://11.213.45.6
4 threads and 10000 connections
4956 requests in 20.06s, 3.24MB read
Socket errors: connect 0, read 0, write 672, timeout 0
Requests/sec: 247.07
Transfer/sec: 165.28KB
There are many reasons for this phenomenon, this patch set doesn't
solve it all though, but it can be well alleviated with it in.
Patch 1/5 (Make smc_tcp_listen_work() independent) :
Separate smc_tcp_listen_work() from smc_listen_work(), make them
independent of each other, the busy SMC handshake can not affect new TCP
connections visit any more. Avoid discarding a large number of TCP
connections after being overstock, which is undoubtedly raise the
connection establishment time.
Patch 2/5 (Limit SMC backlog connections):
Since patch 1 has separated smc_tcp_listen_work() from
smc_listen_work(), an unrestricted TCP accept have come into being. This
patch try to put a limit on SMC backlog connections refers to
implementation of TCP.
Patch 3/5 (Limit SMC visits when handshake workqueue congested):
Considering the complexity of SMC handshake right now, in short-lived
links scenarios, this may not be the main scenario of SMC though, it's
performance is still quite poor. This patch try to provide constraint on
SMC handshake when handshake workqueue congested, which is the sign of
SMC handshake stacking in our opinion.
Patch 4/5 (Dynamic control handshake limitation by socket options)
This patch allow applications dynamically control the ability of SMC
handshake limitation. Since SMC don't support set SMC socket option
before,
this patch also have to support SMC's owns socket options.
Patch 5/5 (Add global configure for handshake limitation by netlink)
This patch provides a way to get benefit of handshake limitation
without
modifying any code for applications, which is quite useful for most
existing applications.
After this patch set, performance figures like that:
Running 20s test @ http://11.213.45.6
4 threads and 10000 connections
693253 requests in 20.10s, 452.88MB read
Requests/sec: 34488.13
Transfer/sec: 22.53MB
That's a quite well performance improvement, about to 6 to 7 times in my
environment.
---
changelog:
v1 -> v2:
- fix compile warning
- fix invalid dependencies in kconfig
v2 -> v3:
- correct spelling mistakes
- fix useless variable declare
v3 -> v4
- make smc_tcp_ls_wq be static
v4 -> v5
- add dynamic control for SMC auto fallback by socket options
- add global configure for SMC auto fallback through netlink
v5 -> v6
- move auto fallback to net namespace scope
- remove auto fallback attribute in SMC_GEN_SYS_INFO
- add independent attributes for auto fallback
v6 -> v7
- fix wording and the naming issues, rename 'auto fallback' to handshake
limitation.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
D. Wythe [Thu, 10 Feb 2022 09:11:38 +0000 (17:11 +0800)]
net/smc: Add global configure for handshake limitation by netlink
Although we can control SMC handshake limitation through socket options,
which means that applications who need it must modify their code. It's
quite troublesome for many existing applications. This patch modifies
the global default value of SMC handshake limitation through netlink,
providing a way to put constraint on handshake without modifies any code
for applications.
Suggested-by: Tony Lu <tonylu@linux.alibaba.com>
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
D. Wythe [Thu, 10 Feb 2022 09:11:37 +0000 (17:11 +0800)]
net/smc: Dynamic control handshake limitation by socket options
This patch aims to add dynamic control for SMC handshake limitation for
every smc sockets, in production environment, it is possible for the
same applications to handle different service types, and may have
different opinion on SMC handshake limitation.
This patch try socket options to complete it, since we don't have socket
option level for SMC yet, which requires us to implement it at the same
time.
This patch does the following:
- add new socket option level: SOL_SMC.
- add new SMC socket option: SMC_LIMIT_HS.
- provide getter/setter for SMC socket options.
Link: https://lore.kernel.org/all/20f504f961e1a803f85d64229ad84260434203bd.1644323503.git.alibuda@linux.alibaba.com/
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
D. Wythe [Thu, 10 Feb 2022 09:11:36 +0000 (17:11 +0800)]
net/smc: Limit SMC visits when handshake workqueue congested
This patch intends to provide a mechanism to put constraint on SMC
connections visit according to the pressure of SMC handshake process.
At present, frequent visits will cause the incoming connections to be
backlogged in SMC handshake queue, raise the connections established
time. Which is quite unacceptable for those applications who base on
short lived connections.
There are two ways to implement this mechanism:
1. Put limitation after TCP established.
2. Put limitation before TCP established.
In the first way, we need to wait and receive CLC messages that the
client will potentially send, and then actively reply with a decline
message, in a sense, which is also a sort of SMC handshake, affect the
connections established time on its way.
In the second way, the only problem is that we need to inject SMC logic
into TCP when it is about to reply the incoming SYN, since we already do
that, it's seems not a problem anymore. And advantage is obvious, few
additional processes are required to complete the constraint.
This patch use the second way. After this patch, connections who beyond
constraint will not informed any SMC indication, and SMC will not be
involved in any of its subsequent processes.
Link: https://lore.kernel.org/all/1641301961-59331-1-git-send-email-alibuda@linux.alibaba.com/
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
D. Wythe [Thu, 10 Feb 2022 09:11:35 +0000 (17:11 +0800)]
net/smc: Limit backlog connections
Current implementation does not handling backlog semantics, one
potential risk is that server will be flooded by infinite amount
connections, even if client was SMC-incapable.
This patch works to put a limit on backlog connections, referring to the
TCP implementation, we divides SMC connections into two categories:
1. Half SMC connection, which includes all TCP established while SMC not
connections.
2. Full SMC connection, which includes all SMC established connections.
For half SMC connection, since all half SMC connections starts with TCP
established, we can achieve our goal by put a limit before TCP
established. Refer to the implementation of TCP, this limits will based
on not only the half SMC connections but also the full connections,
which is also a constraint on full SMC connections.
For full SMC connections, although we know exactly where it starts, it's
quite hard to put a limit before it. The easiest way is to block wait
before receive SMC confirm CLC message, while it's under protection by
smc_server_lgr_pending, a global lock, which leads this limit to the
entire host instead of a single listen socket. Another way is to drop
the full connections, but considering the cast of SMC connections, we
prefer to keep full SMC connections.
Even so, the limits of full SMC connections still exists, see commits
about half SMC connection below.
After this patch, the limits of backend connection shows like:
For SMC:
1. Client with SMC-capability can makes 2 * backlog full SMC connections
or 1 * backlog half SMC connections and 1 * backlog full SMC
connections at most.
2. Client without SMC-capability can only makes 1 * backlog half TCP
connections and 1 * backlog full TCP connections.
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
D. Wythe [Thu, 10 Feb 2022 09:11:34 +0000 (17:11 +0800)]
net/smc: Make smc_tcp_listen_work() independent
In multithread and 10K connections benchmark, the backend TCP connection
established very slowly, and lots of TCP connections stay in SYN_SENT
state.
Client: smc_run wrk -c 10000 -t 4 http://server
the netstate of server host shows like:
145042 times the listen queue of a socket overflowed
145042 SYNs to LISTEN sockets dropped
One reason of this issue is that, since the smc_tcp_listen_work() shared
the same workqueue (smc_hs_wq) with smc_listen_work(), while the
smc_listen_work() do blocking wait for smc connection established. Once
the workqueue became congested, it's will block the accept() from TCP
listen.
This patch creates a independent workqueue(smc_tcp_ls_wq) for
smc_tcp_listen_work(), separate it from smc_listen_work(), which is
quite acceptable considering that smc_tcp_listen_work() runs very fast.
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Luiz Angelo Daros de Luca [Wed, 9 Feb 2022 18:41:16 +0000 (15:41 -0300)]
dt-bindings: net: dsa: realtek: convert to YAML schema, add MDIO
Schema changes:
- support for mdio-connected switches (mdio driver), recognized by
checking the presence of property "reg"
- new compatible strings for rtl8367s and rtl8367rb
- "interrupt-controller" was not added as a required property. It might
still work polling the ports when missing.
Examples changes:
- renamed "switch_intc" to make it unique between examples
- removed "dsa-mdio" from mdio compatible property
- renamed phy@0 to ethernet-phy@0 (not tested with real HW)
phy@ requires #phy-cells
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 11 Feb 2022 01:29:56 +0000 (17:29 -0800)]
Merge git://git./linux/kernel/git/netdev/net
No conflicts.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Linus Torvalds [Fri, 11 Feb 2022 00:01:22 +0000 (16:01 -0800)]
Merge tag 'net-5.17-rc4' of git://git./linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from netfilter and can.
Current release - new code bugs:
- sparx5: fix get_stat64 out-of-bound access and crash
- smc: fix netdev ref tracker misuse
Previous releases - regressions:
- eth: ixgbevf: require large buffers for build_skb on 82599VF, avoid
overflows
- eth: ocelot: fix all IP traffic getting trapped to CPU with PTP
over IP
- bonding: fix rare link activation misses in 802.3ad mode
Previous releases - always broken:
- tcp: fix tcp sock mem accounting in zero-copy corner cases
- remove the cached dst when uncloning an skb dst and its metadata,
since we only have one ref it'd lead to an UaF
- netfilter:
- conntrack: don't refresh sctp entries in closed state
- conntrack: re-init state for retransmitted syn-ack, avoid
connection establishment getting stuck with strange stacks
- ctnetlink: disable helper autoassign, avoid it getting lost
- nft_payload: don't allow transport header access for fragments
- dsa: fix use of devres for mdio throughout drivers
- eth: amd-xgbe: disable interrupts during pci removal
- eth: dpaa2-eth: unregister netdev before disconnecting the PHY
- eth: ice: fix IPIP and SIT TSO offload"
* tag 'net-5.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (53 commits)
net: dsa: mv88e6xxx: fix use-after-free in mv88e6xxx_mdios_unregister
net: mscc: ocelot: fix mutex lock error during ethtool stats read
ice: Avoid RTNL lock when re-creating auxiliary device
ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler
ice: fix IPIP and SIT TSO offload
ice: fix an error code in ice_cfg_phy_fec()
net: mpls: Fix GCC 12 warning
dpaa2-eth: unregister the netdev before disconnecting from the PHY
skbuff: cleanup double word in comment
net: macb: Align the dma and coherent dma masks
mptcp: netlink: process IPv6 addrs in creating listening sockets
selftests: mptcp: add missing join check
net: usb: qmi_wwan: Add support for Dell DW5829e
vlan: move dev_put into vlan_dev_uninit
vlan: introduce vlan_dev_free_egress_priority
ax25: fix UAF bugs of net_device caused by rebinding operation
net: dsa: fix panic when DSA master device unbinds on shutdown
net: amd-xgbe: disable interrupts during pci removal
tipc: rate limit warning for received illegal binding update
net: mdio: aspeed: Add missing MODULE_DEVICE_TABLE
...
Linus Torvalds [Thu, 10 Feb 2022 23:42:48 +0000 (15:42 -0800)]
Merge tag 'linux-kselftest-fixes-5.17-rc4' of git://git./linux/kernel/git/shuah/linux-kselftest
Pull Kselftest fixes from Shuah Khan:
"Build and run-time fixes to pidfd, clone3, and ir tests"
* tag 'linux-kselftest-fixes-5.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests/ir: fix build with ancient kernel headers
selftests: fixup build warnings in pidfd / clone3 tests
pidfd: fix test failure due to stack overflow on some arches
Linus Torvalds [Thu, 10 Feb 2022 23:39:59 +0000 (15:39 -0800)]
Merge tag 'linux-kselftest-kunit-fixes-5.17-rc4' of git://git./linux/kernel/git/shuah/linux-kselftest
Pull KUnit fixes from Shuah Khan:
"Fixes to the test and usage documentation"
* tag 'linux-kselftest-kunit-fixes-5.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
Documentation: KUnit: Fix usage bug
kunit: fix missing f in f-string in run_checks.py
Vladimir Oltean [Thu, 10 Feb 2022 17:40:17 +0000 (19:40 +0200)]
net: dsa: mv88e6xxx: fix use-after-free in mv88e6xxx_mdios_unregister
Since struct mv88e6xxx_mdio_bus *mdio_bus is the bus->priv of something
allocated with mdiobus_alloc_size(), this means that mdiobus_free(bus)
will free the memory backing the mdio_bus as well. Therefore, the
mdio_bus->list element is freed memory, but we continue to iterate
through the list of MDIO buses using that list element.
To fix this, use the proper list iterator that handles element deletion
by keeping a copy of the list element next pointer.
Fixes:
f53a2ce893b2 ("net: dsa: mv88e6xxx: don't use devres for mdiobus")
Reported-by: Rafael Richter <rafael.richter@gin.de>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20220210174017.3271099-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
OSDN Git Service
