Vadim Pasternak [Tue, 22 Feb 2022 17:16:59 +0000 (19:16 +0200)]
mlxsw: core: Remove unnecessary asserts
Remove unnecessary asserts for module index validation. Leave only one
that is actually necessary in mlxsw_env_pmpe_listener_func() where the
module index is directly read from the firmware event.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vadim Pasternak [Tue, 22 Feb 2022 17:16:58 +0000 (19:16 +0200)]
mlxsw: reg: Add "mgpir_" prefix to MGPIR fields comments
Do the same as for other registers and have "mgpir_" prefix for the
MGPIR fields.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vadim Pasternak [Tue, 22 Feb 2022 17:16:57 +0000 (19:16 +0200)]
mlxsw: core_thermal: Remove obsolete API for query resource
Remove obsolete API mlxsw_core_res_query_enabled(), which is only
relevant for end-of-life SwitchX-2 ASICs. Support for these ASICs was
removed in commit
b0d80c013b04 ("mlxsw: Remove Mellanox SwitchX-2 ASIC
support").
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vadim Pasternak [Tue, 22 Feb 2022 17:16:56 +0000 (19:16 +0200)]
mlxsw: core_thermal: Rename labels according to naming convention
Rename labels for error flow handling in order to align with naming
convention used in rest of 'mlxsw' code.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vadim Pasternak [Tue, 22 Feb 2022 17:16:55 +0000 (19:16 +0200)]
mlxsw: core_hwmon: Fix variable names for hwmon attributes
Replace all local variables 'mlwsw_hwmon_attr' by 'mlxsw_hwmon_attr'.
All variable prefixes should start with 'mlxsw' according to the naming
convention, so 'mlwsw' is changed to 'mlxsw'.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vadim Pasternak [Tue, 22 Feb 2022 17:16:54 +0000 (19:16 +0200)]
mlxsw: core_thermal: Avoid creation of virtual hwmon objects by thermal module
The driver registers with both the hwmon and thermal subsystems.
Therefore, there is no need for the thermal subsystem to automatically
create hwmon entries upon registration of a thermal zone, as this
results in duplicate information.
Avoid creation of virtual hwmon objects by thermal subsystem by
registering a thermal zone with 'no_hwmon' set to 'true'.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Tue, 22 Feb 2022 17:16:53 +0000 (19:16 +0200)]
mlxsw: spectrum_span: Ignore VLAN entries not used by the bridge in mirroring
Only VLAN entries installed on the bridge device itself should be
considered when checking whether a packet with a specific VLAN can be
mirrored via a bridge device. VLAN entries only used to keep context
(i.e., entries with 'BRIDGE_VLAN_INFO_BRENTRY' unset) should be ignored.
Fix this by preventing mirroring when the VLAN entry does not have the
'BRIDGE_VLAN_INFO_BRENTRY' flag set.
Fixes:
ddaff5047003 ("mlxsw: spectrum: remove guards against !BRIDGE_VLAN_INFO_BRENTRY")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vadim Pasternak [Tue, 22 Feb 2022 17:16:52 +0000 (19:16 +0200)]
mlxsw: core: Prevent trap group setting if driver does not support EMAD
Avoid trap group setting if driver is not capable of EMAD support.
For example, "mlxsw_minimal" driver works over I2C bus, overs which
EMADs cannot be sent.
Validation is performed by testing feature 'MLXSW_BUS_F_TXRX'.
Fixes:
74e0494d35ac ("mlxsw: core: Move basic_trap_groups_set() call out of EMAD init code")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Matt Johnston [Tue, 22 Feb 2022 04:29:36 +0000 (12:29 +0800)]
mctp: Fix warnings reported by clang-analyzer
net/mctp/device.c:140:11: warning: Assigned value is garbage or undefined
[clang-analyzer-core.uninitialized.Assign]
mcb->idx = idx;
- Not a real problem due to how the callback runs, fix the warning.
net/mctp/route.c:458:4: warning: Value stored to 'msk' is never read
[clang-analyzer-deadcode.DeadStores]
msk = container_of(key->sk, struct mctp_sock, sk);
- 'msk' dead assignment can be removed here.
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 23 Feb 2022 12:29:15 +0000 (12:29 +0000)]
Merge branch 'mctp-incorrect-addr-refs'
Matt Johnston says:
====================
mctp: Fix incorrect refs for extended addr
This fixes an incorrect netdev unref and also addresses the race
condition identified by Jakub in v2. Thanks for the review.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Matt Johnston [Tue, 22 Feb 2022 04:17:39 +0000 (12:17 +0800)]
mctp: Fix incorrect netdev unref for extended addr
In the extended addressing local route output codepath
dev_get_by_index_rcu() doesn't take a dev_hold() so we shouldn't
dev_put().
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Matt Johnston [Tue, 22 Feb 2022 04:17:38 +0000 (12:17 +0800)]
mctp: make __mctp_dev_get() take a refcount hold
Previously there was a race that could allow the mctp_dev refcount
to hit zero:
rcu_read_lock();
mdev = __mctp_dev_get(dev);
// mctp_unregister() happens here, mdev->refs hits zero
mctp_dev_hold(dev);
rcu_read_unlock();
Now we make __mctp_dev_get() take the hold itself. It is safe to test
against the zero refcount because __mctp_dev_get() is called holding
rcu_read_lock and mctp_dev uses kfree_rcu().
Reported-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 23 Feb 2022 12:24:29 +0000 (12:24 +0000)]
Merge branch 'dsa-realtek-phy-read-corruption'
Alvin Šipraga says:
====================
net: dsa: realtek: fix PHY register read corruption
These two patches fix the issue reported by Arınç where PHY register
reads sometimes return garbage data.
v1 -> v2:
- no code changes
- just update the commit message of patch 2 to reflect the conclusion
of further investigation requested by Vladimir
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Alvin Šipraga [Mon, 21 Feb 2022 18:46:31 +0000 (19:46 +0100)]
net: dsa: realtek: rtl8365mb: serialize indirect PHY register access
Realtek switches in the rtl8365mb family can access the PHY registers of
the internal PHYs via the switch registers. This method is called
indirect access. At a high level, the indirect PHY register access
method involves reading and writing some special switch registers in a
particular sequence. This works for both SMI and MDIO connected
switches.
Currently the rtl8365mb driver does not take any care to serialize the
aforementioned access to the switch registers. In particular, it is
permitted for other driver code to access other switch registers while
the indirect PHY register access is ongoing. Locking is only done at the
regmap level. This, however, is a bug: concurrent register access, even
to unrelated switch registers, risks corrupting the PHY register value
read back via the indirect access method described above.
Arınç reported that the switch sometimes returns nonsense data when
reading the PHY registers. In particular, a value of 0 causes the
kernel's PHY subsystem to think that the link is down, but since most
reads return correct data, the link then flip-flops between up and down
over a period of time.
The aforementioned bug can be readily observed by:
1. Enabling ftrace events for regmap and mdio
2. Polling BSMR PHY register for a connected port;
it should always read the same (e.g. 0x79ed)
3. Wait for step 2 to give a different value
Example command for step 2:
while true; do phytool read swp2/2/0x01; done
On my i.MX8MM, the above steps will yield a bogus value for the BSMR PHY
register within a matter of seconds. The interleaved register access it
then evident in the trace log:
kworker/3:4-70 [003] ....... 1927.139849: regmap_reg_write: ethernet-switch reg=1004 val=bd
phytool-16816 [002] ....... 1927.139979: regmap_reg_read: ethernet-switch reg=1f01 val=0
kworker/3:4-70 [003] ....... 1927.140381: regmap_reg_read: ethernet-switch reg=1005 val=0
phytool-16816 [002] ....... 1927.140468: regmap_reg_read: ethernet-switch reg=1d15 val=a69
kworker/3:4-70 [003] ....... 1927.140864: regmap_reg_read: ethernet-switch reg=1003 val=0
phytool-16816 [002] ....... 1927.140955: regmap_reg_write: ethernet-switch reg=1f02 val=2041
kworker/3:4-70 [003] ....... 1927.141390: regmap_reg_read: ethernet-switch reg=1002 val=0
phytool-16816 [002] ....... 1927.141479: regmap_reg_write: ethernet-switch reg=1f00 val=1
kworker/3:4-70 [003] ....... 1927.142311: regmap_reg_write: ethernet-switch reg=1004 val=be
phytool-16816 [002] ....... 1927.142410: regmap_reg_read: ethernet-switch reg=1f01 val=0
kworker/3:4-70 [003] ....... 1927.142534: regmap_reg_read: ethernet-switch reg=1005 val=0
phytool-16816 [002] ....... 1927.142618: regmap_reg_read: ethernet-switch reg=1f04 val=0
phytool-16816 [002] ....... 1927.142641: mdio_access: SMI-0 read phy:0x02 reg:0x01 val:0x0000 <- ?!
kworker/3:4-70 [003] ....... 1927.143037: regmap_reg_read: ethernet-switch reg=1001 val=0
kworker/3:4-70 [003] ....... 1927.143133: regmap_reg_read: ethernet-switch reg=1000 val=2d89
kworker/3:4-70 [003] ....... 1927.143213: regmap_reg_write: ethernet-switch reg=1004 val=be
kworker/3:4-70 [003] ....... 1927.143291: regmap_reg_read: ethernet-switch reg=1005 val=0
kworker/3:4-70 [003] ....... 1927.143368: regmap_reg_read: ethernet-switch reg=1003 val=0
kworker/3:4-70 [003] ....... 1927.143443: regmap_reg_read: ethernet-switch reg=1002 val=6
The kworker here is polling MIB counters for stats, as evidenced by the
register 0x1004 that we are writing to (RTL8365MB_MIB_ADDRESS_REG). This
polling is performed every 3 seconds, but is just one example of such
unsynchronized access. In Arınç's case, the driver was not using the
switch IRQ, so the PHY subsystem was itself doing polling analogous to
phytool in the above example.
A test module was created [see second Link] to simulate such spurious
switch register accesses while performing indirect PHY register reads
and writes. Realtek was also consulted to confirm whether this is a
known issue or not. The conclusion of these lines of inquiry is as
follows:
1. Reading of PHY registers via indirect access will be aborted if,
after executing the read operation (via a write to the
INDIRECT_ACCESS_CTRL_REG), any register is accessed, other than
INDIRECT_ACCESS_STATUS_REG.
2. The PHY register indirect read is only complete when
INDIRECT_ACCESS_STATUS_REG reads zero.
3. The INDIRECT_ACCESS_DATA_REG, which is read to get the result of the
PHY read, will contain the result of the last successful read
operation. If there was spurious register access and the indirect
read was aborted, then this register is not guaranteed to hold
anything meaningful and the PHY read will silently fail.
4. PHY writes do not appear to be affected by this mechanism.
5. Other similar access routines, such as for MIB counters, although
similar to the PHY indirect access method, are actually table access.
Table access is not affected by spurious reads or writes of other
registers. However, concurrent table access is not allowed. Currently
this is protected via mib_lock, so there is nothing to fix.
The above statements are corroborated both via the test module and
through consultation with Realtek. In particular, Realtek states that
this is simply a property of the hardware design and is not a hardware
bug.
To fix this problem, one must guard against regmap access while the
PHY indirect register read is executing. Fix this by using the newly
introduced "nolock" regmap in all PHY-related functions, and by aquiring
the regmap mutex at the top level of the PHY register access callbacks.
Although no issue has been observed with PHY register _writes_, this
change also serializes the indirect access method there. This is done
purely as a matter of convenience and for reasons of symmetry.
Fixes:
4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Link: https://lore.kernel.org/netdev/CAJq09z5FCgG-+jVT7uxh1a-0CiiFsoKoHYsAWJtiKwv7LXKofQ@mail.gmail.com/
Link: https://lore.kernel.org/netdev/871qzwjmtv.fsf@bang-olufsen.dk/
Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Reported-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alvin Šipraga [Mon, 21 Feb 2022 18:46:30 +0000 (19:46 +0100)]
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean [Mon, 21 Feb 2022 12:01:30 +0000 (14:01 +0200)]
net: switchdev: avoid infinite recursion from LAG to bridge with port object handler
The logic from switchdev_handle_port_obj_add_foreign() is directly
adapted from switchdev_handle_fdb_event_to_device(), which already
detects events on foreign interfaces and reoffloads them towards the
switchdev neighbors.
However, when we have a simple br0 <-> bond0 <-> swp0 topology and the
switchdev_handle_port_obj_add_foreign() gets called on bond0, we get
stuck into an infinite recursion:
1. bond0 does not pass check_cb(), so we attempt to find switchdev
neighbor interfaces. For that, we recursively call
__switchdev_handle_port_obj_add() for bond0's bridge, br0.
2. __switchdev_handle_port_obj_add() recurses through br0's lowers,
essentially calling __switchdev_handle_port_obj_add() for bond0
3. Go to step 1.
This happens because switchdev_handle_fdb_event_to_device() and
switchdev_handle_port_obj_add_foreign() are not exactly the same.
The FDB event helper special-cases LAG interfaces with its lag_mod_cb(),
so this is why we don't end up in an infinite loop - because it doesn't
attempt to treat LAG interfaces as potentially foreign bridge ports.
The problem is solved by looking ahead through the bridge's lowers to
see whether there is any switchdev interface that is foreign to the @dev
we are currently processing. This stops the recursion described above at
step 1: __switchdev_handle_port_obj_add(bond0) will not create another
call to __switchdev_handle_port_obj_add(br0). Going one step upper
should only happen when we're starting from a bridge port that has been
determined to be "foreign" to the switchdev driver that passes the
foreign_dev_check_cb().
Fixes:
c4076cdd21f8 ("net: switchdev: introduce switchdev_handle_port_obj_{add,del} for foreign interfaces")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shannon Nelson [Wed, 23 Feb 2022 01:57:31 +0000 (17:57 -0800)]
ionic: use vmalloc include
The ever-vigilant Linux kernel test robot reminded us that
we need to use the correct include files to be sure that
all the build variations will work correctly. Adding the
vmalloc.h include takes care of declaring our use of vzalloc()
and vfree().
drivers/net/ethernet/pensando/ionic/ionic_lif.c:396:17: error: implicit
declaration of function 'vfree'; did you mean 'kvfree'?
drivers/net/ethernet/pensando/ionic/ionic_lif.c:531:21: warning:
assignment to 'struct ionic_desc_info *' from 'int' makes pointer from
integer without a cast
Fixes:
116dce0ff047 ("ionic: Use vzalloc for large per-queue related buffers")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Link: https://lore.kernel.org/r/20220223015731.22025-1-snelson@pensando.io
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Wed, 23 Feb 2022 03:44:06 +0000 (19:44 -0800)]
Merge branch 'tcp-take-care-of-another-syzbot-issue'
Eric Dumazet says:
====================
tcp: take care of another syzbot issue
This is a minor issue: It took months for syzbot to find a C repro,
and even with it, I had to spend a lot of time to understand KFENCE
was a prereq. With the default kfence 500ms interval, I had to be
very patient to trigger the kernel warning and perform my analysis.
This series targets net-next tree, because I added a new generic helper
in the first patch, then fixed the issue in the second one.
They can be backported once proven solid.
====================
Link: https://lore.kernel.org/r/20220222032113.4005821-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Tue, 22 Feb 2022 03:21:13 +0000 (19:21 -0800)]
net: preserve skb_end_offset() in skb_unclone_keeptruesize()
syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len)
in skb_try_coalesce() [1]
I was able to root cause the issue to kfence.
When kfence is in action, the following assertion is no longer true:
int size = xxxx;
void *ptr1 = kmalloc(size, gfp);
void *ptr2 = kmalloc(size, gfp);
if (ptr1 && ptr2)
ASSERT(ksize(ptr1) == ksize(ptr2));
We attempted to fix these issues in the blamed commits, but forgot
that TCP was possibly shifting data after skb_unclone_keeptruesize()
has been used, notably from tcp_retrans_try_collapse().
So we not only need to keep same skb->truesize value,
we also need to make sure TCP wont fill new tailroom
that pskb_expand_head() was able to get from a
addr = kmalloc(...) followed by ksize(addr)
Split skb_unclone_keeptruesize() into two parts:
1) Inline skb_unclone_keeptruesize() for the common case,
when skb is not cloned.
2) Out of line __skb_unclone_keeptruesize() for the 'slow path'.
WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295
Modules linked in:
CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295
Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa
RSP: 0018:
ffffc900063af268 EFLAGS:
00010293
RAX:
0000000000000000 RBX:
00000000ffffffd5 RCX:
0000000000000000
RDX:
ffff88806fc05700 RSI:
ffffffff872abd55 RDI:
0000000000000003
RBP:
ffff88806e675500 R08:
00000000ffffffd5 R09:
0000000000000000
R10:
ffffffff872ab659 R11:
0000000000000000 R12:
ffff88806dd554e8
R13:
ffff88806dd9bac0 R14:
ffff88806dd9a2c0 R15:
0000000000000155
FS:
00007f18014f9700(0000) GS:
ffff8880b9c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000020002000 CR3:
000000006be7a000 CR4:
00000000003506f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
<TASK>
tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline]
tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630
tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914
tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025
tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947
tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719
sk_backlog_rcv include/net/sock.h:1037 [inline]
__release_sock+0x134/0x3b0 net/core/sock.c:2779
release_sock+0x54/0x1b0 net/core/sock.c:3311
sk_wait_data+0x177/0x450 net/core/sock.c:2821
tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457
tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572
inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850
sock_recvmsg_nosec net/socket.c:948 [inline]
sock_recvmsg net/socket.c:966 [inline]
sock_recvmsg net/socket.c:962 [inline]
____sys_recvmsg+0x2c4/0x600 net/socket.c:2632
___sys_recvmsg+0x127/0x200 net/socket.c:2674
__sys_recvmsg+0xe2/0x1a0 net/socket.c:2704
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes:
c4777efa751d ("net: add and use skb_unclone_keeptruesize() helper")
Fixes:
097b9146c0e2 ("net: fix up truesize of cloned skb in skb_prepare_for_shift()")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Marco Elver <elver@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Tue, 22 Feb 2022 03:21:12 +0000 (19:21 -0800)]
net: add skb_set_end_offset() helper
We have multiple places where this helper is convenient,
and plan using it in the following patch.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Tue, 22 Feb 2022 03:11:15 +0000 (19:11 -0800)]
ipv6: tcp: consistently use MAX_TCP_HEADER
All other skbs allocated for TCP tx are using MAX_TCP_HEADER already.
MAX_HEADER can be too small for some cases (like eBPF based encapsulation),
so this can avoid extra pskb_expand_head() in lower stacks.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20220222031115.4005060-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Maciek Machnikowski [Mon, 21 Feb 2022 20:06:37 +0000 (21:06 +0100)]
testptp: add option to shift clock by nanoseconds
Add option to shift the clock by a specified number of nanoseconds.
The new argument -n will specify the number of nanoseconds to add to the
ptp clock. Since the API doesn't support negative shifts those needs to
be calculated by subtracting full seconds and adding a nanosecond offset.
Signed-off-by: Maciek Machnikowski <maciek@machnikowski.net>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Link: https://lore.kernel.org/r/20220221200637.125595-1-maciek@machnikowski.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Gustavo A. R. Silva [Mon, 21 Feb 2022 17:34:15 +0000 (11:34 -0600)]
usbnet: gl620a: Replace one-element array with flexible-array member
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
This issue was found with the help of Coccinelle and audited and fixed,
manually.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/79
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20220221173415.GA1149599@embeddedor
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Mon, 21 Feb 2022 17:10:52 +0000 (17:10 +0000)]
net: phy: phylink: fix DSA mac_select_pcs() introduction
Vladimir Oltean reports that probing on DSA drivers that aren't yet
populating supported_interfaces now fails. Fix this by allowing
phylink to detect whether DSA actually provides an underlying
mac_select_pcs() implementation.
Reported-by: Vladimir Oltean <olteanv@gmail.com>
Fixes:
bde018222c6b ("net: dsa: add support for phylink mac_select_pcs()")
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/E1nMCD6-00A0wC-FG@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Oleksij Rempel [Mon, 21 Feb 2022 08:41:29 +0000 (09:41 +0100)]
net: dsa: microchip: ksz9477: reduce polling interval for statistics
30 seconds is too long interval especially if it used with ip -s l.
Reduce polling interval to 5 sec.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20220221084129.3660124-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Wed, 23 Feb 2022 00:09:16 +0000 (16:09 -0800)]
Merge branch 's390-net-updates-2022-02-21'
Alexandra Winter says:
====================
s390/net: updates 2022-02-21
Just cleanup. No functional changes, as currently virt=phys in s390.
====================
Link: https://lore.kernel.org/r/20220221145633.3869621-1-wintera@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alexander Gordeev [Mon, 21 Feb 2022 14:56:33 +0000 (15:56 +0100)]
s390/net: sort out physical vs virtual pointers usage
Fix virtual vs physical address confusion (which currently are the same).
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alexander Gordeev [Mon, 21 Feb 2022 14:56:32 +0000 (15:56 +0100)]
s390/iucv: sort out physical vs virtual pointers usage
Fix virtual vs physical address confusion (which currently are the same).
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Sun, 20 Feb 2022 04:11:55 +0000 (20:11 -0800)]
gro_cells: avoid using synchronize_rcu() in gro_cells_destroy()
Another thing making netns dismantles potentially very slow is located
in gro_cells_destroy(),
whenever cleanup_net() has to remove a device using gro_cells framework.
RTNL is not held at this stage, so synchronize_net()
is calling synchronize_rcu():
netdev_run_todo()
ip_tunnel_dev_free()
gro_cells_destroy()
synchronize_net()
synchronize_rcu() // Ouch.
This patch uses call_rcu(), and gave me a 25x performance improvement
in my tests.
cleanup_net() is no longer blocked ~10 ms per synchronize_rcu()
call.
In the case we could not allocate the memory needed to queue the
deferred free, use synchronize_rcu_expedited()
v2: made percpu_free_defer_callback() static
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Link: https://lore.kernel.org/r/20220220041155.607637-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David S. Miller [Tue, 22 Feb 2022 11:03:02 +0000 (11:03 +0000)]
Merge branch 'net-dsa-b53-non-legacy'
Russell King says:
====================
net: dsa: b53: convert to phylink_generic_validate() and mark as non-legacy
This series converts b53 to use phylink_generic_validate() and also
marks this driver as non-legacy.
Patch 1 cleans up an if() condition to be more readable before we
proceed with the conversion.
Patch 2 populates the supported_interfaces and mac_capabilities members
of phylink_config.
Patch 3 drops the use of phylink_helper_basex_speed() which is now not
necessary.
Patch 4 switches the driver to use phylink_generic_validate()
Patch 5 marks the driver as non-legacy.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Tue, 22 Feb 2022 10:16:18 +0000 (10:16 +0000)]
net: dsa: b53: mark as non-legacy
The B53 driver does not make use of the speed, duplex, pause or
advertisement in its phylink_mac_config() implementation, so it can be
marked as a non-legacy driver.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Tue, 22 Feb 2022 10:16:13 +0000 (10:16 +0000)]
net: dsa: b53: switch to using phylink_generic_validate()
Switch the Broadcom b53 driver to using the phylink_generic_validate()
implementation by removing its own .phylink_validate method and
associated code.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Tue, 22 Feb 2022 10:16:07 +0000 (10:16 +0000)]
net: dsa: b53: drop use of phylink_helper_basex_speed()
Now that we have a better method to select SFP interface modes, we
no longer need to use phylink_helper_basex_speed() in a driver's
validation function.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Tue, 22 Feb 2022 10:16:02 +0000 (10:16 +0000)]
net: dsa: b53: populate supported_interfaces and mac_capabilities
Populate the supported interfaces and MAC capabilities for the Broadcom
B53 DSA switches in preparation to using these for the generic
validation functionality.
The interface modes are derived from:
- b53_serdes_phylink_validate()
- SRAB mux configuration
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Tue, 22 Feb 2022 10:15:57 +0000 (10:15 +0000)]
net: dsa: b53: clean up if() condition to be more readable
I've stared at this if() statement for a while trying to work out if
it really does correspond with the comment above, and it does seem to.
However, let's make it more readable and phrase it in the same way as
the comment.
Also add a FIXME into the comment - we appear to deny Gigabit modes for
802.3z interface modes, but 802.3z interface modes only operate at
gigabit and above.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Mon, 21 Feb 2022 10:54:40 +0000 (13:54 +0300)]
net: dm9051: Fix use after free in dm9051_loop_tx()
This code dereferences "skb" after calling dev_kfree_skb().
Fixes:
2dc95a4d30ed ("net: Add dm9051 driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20220221105440.GA10045@kili
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Juhee Kang [Sun, 20 Feb 2022 15:32:50 +0000 (15:32 +0000)]
net: hsr: fix hsr build error when lockdep is not enabled
In hsr, lockdep_is_held() is needed for rcu_dereference_bh_check().
But if lockdep is not enabled, lockdep_is_held() causes a build error:
ERROR: modpost: "lockdep_is_held" [net/hsr/hsr.ko] undefined!
Thus, this patch solved by adding lockdep_hsr_is_held(). This helper
function calls the lockdep_is_held() when lockdep is enabled, and returns 1
if not defined.
Fixes:
e7f27420681f ("net: hsr: fix suspicious RCU usage warning in hsr_node_get_first()")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Link: https://lore.kernel.org/r/20220220153250.5285-1-claudiajkang@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David S. Miller [Mon, 21 Feb 2022 13:07:48 +0000 (13:07 +0000)]
Merge branch 'octeontx2-ptp-updates'
Rakesh Babu Saladi says:
====================
RVU AF and NETDEV drivers' PTP updates.
Patch 1: Add suppot such that RVU drivers support new timestamp format.
Patch 2: This patch adds workaround for PTP errata.
Changes made from v1 to v2
1. CC'd Richard Cochran to review PTP related patches.
2. Removed a patch from the old patch series. Will submit the removed patch
separately.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Naveen Mamindlapalli [Mon, 21 Feb 2022 06:45:08 +0000 (12:15 +0530)]
octeontx2-af: cn10k: add workaround for ptp errata
This patch adds workaround for PTP errata given below.
1. At the time of 1 sec rollover of nano-second counter,
the nano-second counter is set to 0. However, it should
be set to (existing counter_value - 10^9). This leads to
an accumulating error in the timestamp value with each sec
rollover.
2. Additionally, the nano-second counter currently is rolling
over at 'h3B9A_C9FF. It should roll over at 'h3B9A_CA00.
The workaround for issue #1 is to speed up the ptp clock by
adjusting PTP_CLOCK_COMP register to the desired value to
compensate for the nanoseconds lost per each second.
The workaround for issue #2 is to slow down the ptp clock
such that the rollover occurs at ~1sec.
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Naveen Mamindlapalli [Mon, 21 Feb 2022 06:45:07 +0000 (12:15 +0530)]
octeontx2-pf: cn10k: add support for new ptp timestamp format
The cn10k hardware ptp timestamp format has been modified primarily
to support 1-step ptp clock. The 64-bit timestamp used by hardware is
split into two 32-bit fields, the upper one holds seconds, the lower
one nanoseconds. A new register (PTP_CLOCK_SEC) has been added that
returns the current seconds value. The nanoseconds register PTP_CLOCK_HI
resets after every second. The cn10k RPM block provides Rx/Tx timestamps
to the NIX block using the new timestamp format. The software can read
the current timestamp in nanoseconds by reading both PTP_CLOCK_SEC &
PTP_CLOCK_HI registers.
This patch provides support for new timestamp format.
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 21 Feb 2022 12:13:45 +0000 (12:13 +0000)]
Merge branch 'bonding-ipv6-NA-NS-monitor'
Hangbin Liu says:
====================
bonding: add IPv6 NS/NA monitor support
This patch add bond IPv6 NS/NA monitor support. A new option
ns_ip6_target is added, which is similar with arp_ip_target.
The IPv6 NS/NA monitor will take effect when there is a valid IPv6
address. Both ARP monitor and NS monitor will working at the same time.
A new extra storage field is added to struct bond_opt_value for IPv6 support.
Function bond_handle_vlan() is split from bond_arp_send() for both
IPv4/IPv6 usage.
To alloc NS message and send out. ndisc_ns_create() and ndisc_send_skb()
are exported.
v1 -> v2:
1. remove sysfs entry[1] and only keep netlink support.
RFC -> v1:
1. define BOND_MAX_ND_TARGETS as BOND_MAX_ARP_TARGETS
2. adjust for reverse xmas tree ordering of local variables
3. remove bond_do_ns_validate()
4. add extra field for bond_opt_value
5. set IS_ENABLED(CONFIG_IPV6) for IPv6 codes
[1] https://lore.kernel.org/netdev/8863.
1645071997@famine
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu [Mon, 21 Feb 2022 05:54:57 +0000 (13:54 +0800)]
bonding: add new option ns_ip6_target
This patch add a new bonding option ns_ip6_target, which correspond
to the arp_ip_target. With this we set IPv6 targets and send IPv6 NS
request to determine the health of the link.
For other related options like the validation, we still use
arp_validate, and will change to ns_validate later.
Note: the sysfs configuration support was removed based on
https://lore.kernel.org/netdev/8863.
1645071997@famine
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu [Mon, 21 Feb 2022 05:54:56 +0000 (13:54 +0800)]
bonding: add new parameter ns_targets
Add a new bonding parameter ns_targets to store IPv6 address.
Add required bond_ns_send/rcv functions first before adding
IPv6 address option setting.
Add two functions bond_send/rcv_validate so we can send/recv
ARP and NS at the same time.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu [Mon, 21 Feb 2022 05:54:55 +0000 (13:54 +0800)]
bonding: add extra field for bond_opt_value
Adding an extra storage field for bond_opt_value so we can set large
bytes of data for bonding options in future, e.g. IPv6 address.
Define a new call bond_opt_initextra(). Also change the checking order of
__bond_opt_init() and check values first.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu [Mon, 21 Feb 2022 05:54:54 +0000 (13:54 +0800)]
Bonding: split bond_handle_vlan from bond_arp_send
Function bond_handle_vlan() is split from bond_arp_send() for later
IPv6 usage.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu [Mon, 21 Feb 2022 05:54:53 +0000 (13:54 +0800)]
ipv6: separate ndisc_ns_create() from ndisc_send_ns()
This patch separate NS message allocation steps from ndisc_send_ns(),
so it could be used in other places, like bonding, to allocate and
send IPv6 NS message.
Also export ndisc_send_skb() and ndisc_ns_create() for later bonding usage.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christophe JAILLET [Sun, 20 Feb 2022 07:27:15 +0000 (08:27 +0100)]
ravb: Use GFP_KERNEL instead of GFP_ATOMIC when possible
'max_rx_len' can be up to GBETH_RX_BUFF_MAX (i.e. 8192) (see
'gbeth_hw_info').
The default value of 'num_rx_ring' can be BE_RX_RING_SIZE (i.e. 1024).
So this loop can allocate 8 Mo of memory.
Previous memory allocations in this function already use GFP_KERNEL, so
use __netdev_alloc_skb() and an explicit GFP_KERNEL instead of a
implicit GFP_ATOMIC.
This gives more opportunities of successful allocation.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christophe JAILLET [Sun, 20 Feb 2022 06:36:59 +0000 (07:36 +0100)]
net: qualcomm: rmnet: Use skb_put_zero() to simplify code
Use skb_put_zero() instead of hand-writing it. This saves a few lines of
code and is more readable.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 21 Feb 2022 11:44:30 +0000 (11:44 +0000)]
Merge branch 'ipv4-invalidate-broadcast-neigh-upon-address-addition'
Ido Schimmel says:
====================
ipv4: Invalidate neighbour for broadcast address upon address addition
Patch #1 solves a recently reported issue [1]. See detailed description
in the changelog.
Patch #2 adds a matching test case.
Targeting at net-next since as far as I can tell this use case never
worked.
There are no regressions in fib_tests.sh with this change:
# ./fib_tests.sh
...
Tests passed: 186
Tests failed: 0
[1] https://lore.kernel.org/netdev/
55a04a8f-56f3-f73c-2aea-
2195923f09d1@huawei.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Sat, 19 Feb 2022 15:45:20 +0000 (17:45 +0200)]
selftests: fib_test: Add a test case for IPv4 broadcast neighbours
Test that resolved neighbours for IPv4 broadcast addresses are
unaffected by the configuration of matching broadcast routes, whereas
unresolved neighbours are invalidated.
Without previous patch:
# ./fib_tests.sh -t ipv4_bcast_neigh
IPv4 broadcast neighbour tests
TEST: Resolved neighbour for broadcast address [ OK ]
TEST: Resolved neighbour for network broadcast address [ OK ]
TEST: Unresolved neighbour for broadcast address [FAIL]
TEST: Unresolved neighbour for network broadcast address [FAIL]
Tests passed: 2
Tests failed: 2
With previous patch:
# ./fib_tests.sh -t ipv4_bcast_neigh
IPv4 broadcast neighbour tests
TEST: Resolved neighbour for broadcast address [ OK ]
TEST: Resolved neighbour for network broadcast address [ OK ]
TEST: Unresolved neighbour for broadcast address [ OK ]
TEST: Unresolved neighbour for network broadcast address [ OK ]
Tests passed: 4
Tests failed: 0
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Sat, 19 Feb 2022 15:45:19 +0000 (17:45 +0200)]
ipv4: Invalidate neighbour for broadcast address upon address addition
In case user space sends a packet destined to a broadcast address when a
matching broadcast route is not configured, the kernel will create a
unicast neighbour entry that will never be resolved [1].
When the broadcast route is configured, the unicast neighbour entry will
not be invalidated and continue to linger, resulting in packets being
dropped.
Solve this by invalidating unresolved neighbour entries for broadcast
addresses after routes for these addresses are internally configured by
the kernel. This allows the kernel to create a broadcast neighbour entry
following the next route lookup.
Another possible solution that is more generic but also more complex is
to have the ARP code register a listener to the FIB notification chain
and invalidate matching neighbour entries upon the addition of broadcast
routes.
It is also possible to wave off the issue as a user space problem, but
it seems a bit excessive to expect user space to be that intimately
familiar with the inner workings of the FIB/neighbour kernel code.
[1] https://lore.kernel.org/netdev/
55a04a8f-56f3-f73c-2aea-
2195923f09d1@huawei.com/
Reported-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christophe Leroy [Fri, 18 Feb 2022 08:03:48 +0000 (09:03 +0100)]
net: core: Use csum_replace_by_diff() and csum_sub() instead of opencoding
Open coded calculation can be avoided and replaced by the
equivalent csum_replace_by_diff() and csum_sub().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sun, 20 Feb 2022 13:55:31 +0000 (13:55 +0000)]
Merge branch 'tcp_drop_reason'
Menglong Dong says:
====================
net: add skb drop reasons to TCP packet receive
In the commit
c504e5c2f964 ("net: skb: introduce kfree_skb_reason()"),
we added the support of reporting the reasons of skb drops to kfree_skb
tracepoint. And in this series patches, reasons for skb drops are added
to TCP layer (both TCPv4 and TCPv6 are considered).
Following functions are processed:
tcp_v4_rcv()
tcp_v6_rcv()
tcp_v4_inbound_md5_hash()
tcp_v6_inbound_md5_hash()
tcp_add_backlog()
tcp_v4_do_rcv()
tcp_v6_do_rcv()
tcp_rcv_established()
tcp_data_queue()
tcp_data_queue_ofo()
The functions we handled are mostly for packet ingress, as skb drops
hardly happens in the egress path of TCP layer. However, it's a little
complex for TCP state processing, as I find that it's hard to report skb
drop reasons to where it is freed. For example, when skb is dropped in
tcp_rcv_state_process(), the reason can be caused by the call of
tcp_v4_conn_request(), and it's hard to return a drop reason from
tcp_v4_conn_request(). So such cases are skipped for this moment.
Following new drop reasons are introduced (what they mean can be see
in the document for them):
/* SKB_DROP_REASON_TCP_MD5* corresponding to LINUX_MIB_TCPMD5* */
SKB_DROP_REASON_TCP_MD5NOTFOUND
SKB_DROP_REASON_TCP_MD5UNEXPECTED
SKB_DROP_REASON_TCP_MD5FAILURE
SKB_DROP_REASON_SOCKET_BACKLOG
SKB_DROP_REASON_TCP_FLAGS
SKB_DROP_REASON_TCP_ZEROWINDOW
SKB_DROP_REASON_TCP_OLD_DATA
SKB_DROP_REASON_TCP_OVERWINDOW
/* corresponding to LINUX_MIB_TCPOFOMERGE */
SKB_DROP_REASON_TCP_OFOMERGE
Here is a example to get TCP packet drop reasons from ftrace:
$ echo 1 > /sys/kernel/debug/tracing/events/skb/kfree_skb/enable
$ cat /sys/kernel/debug/tracing/trace
$ <idle>-0 [036] ..s1. 647.428165: kfree_skb: skbaddr=
000000004d037db6 protocol=2048 location=
0000000074cd1243 reason: NO_SOCKET
$ <idle>-0 [020] ..s2. 639.676674: kfree_skb: skbaddr=
00000000bcbfa42d protocol=2048 location=
00000000bfe89d35 reason: PROTO_MEM
From the reason 'PROTO_MEM' we can know that the skb is dropped because
the memory configured in net.ipv4.tcp_mem is up to the limition.
Changes since v2:
- remove the 'inline' of tcp_drop() in the 1th patch, as Jakub
suggested
Changes since v1:
- enrich the document for this series patches in the cover letter,
as Eric suggested
- fix compile warning report by Jakub in the 6th patch
- let NO_SOCKET trump the XFRM failure in the 2th and 3th patches
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:37 +0000 (15:06 +0800)]
net: tcp: use tcp_drop_reason() for tcp_data_queue_ofo()
Replace tcp_drop() used in tcp_data_queue_ofo with tcp_drop_reason().
Following drop reasons are introduced:
SKB_DROP_REASON_TCP_OFOMERGE
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:36 +0000 (15:06 +0800)]
net: tcp: use tcp_drop_reason() for tcp_data_queue()
Replace tcp_drop() used in tcp_data_queue() with tcp_drop_reason().
Following drop reasons are introduced:
SKB_DROP_REASON_TCP_ZEROWINDOW
SKB_DROP_REASON_TCP_OLD_DATA
SKB_DROP_REASON_TCP_OVERWINDOW
SKB_DROP_REASON_TCP_OLD_DATA is used for the case that end_seq of skb
less than the left edges of receive window. (Maybe there is a better
name?)
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:35 +0000 (15:06 +0800)]
net: tcp: use tcp_drop_reason() for tcp_rcv_established()
Replace tcp_drop() used in tcp_rcv_established() with tcp_drop_reason().
Following drop reasons are added:
SKB_DROP_REASON_TCP_FLAGS
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:34 +0000 (15:06 +0800)]
net: tcp: use kfree_skb_reason() for tcp_v{4,6}_do_rcv()
Replace kfree_skb() used in tcp_v4_do_rcv() and tcp_v6_do_rcv() with
kfree_skb_reason().
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:33 +0000 (15:06 +0800)]
net: tcp: add skb drop reasons to tcp_add_backlog()
Pass the address of drop_reason to tcp_add_backlog() to store the
reasons for skb drops when fails. Following drop reasons are
introduced:
SKB_DROP_REASON_SOCKET_BACKLOG
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:32 +0000 (15:06 +0800)]
net: tcp: add skb drop reasons to tcp_v{4,6}_inbound_md5_hash()
Pass the address of drop reason to tcp_v4_inbound_md5_hash() and
tcp_v6_inbound_md5_hash() to store the reasons for skb drops when this
function fails. Therefore, the drop reason can be passed to
kfree_skb_reason() when the skb needs to be freed.
Following drop reasons are added:
SKB_DROP_REASON_TCP_MD5NOTFOUND
SKB_DROP_REASON_TCP_MD5UNEXPECTED
SKB_DROP_REASON_TCP_MD5FAILURE
SKB_DROP_REASON_TCP_MD5* above correspond to LINUX_MIB_TCPMD5*
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:31 +0000 (15:06 +0800)]
net: tcp: use kfree_skb_reason() for tcp_v6_rcv()
Replace kfree_skb() used in tcp_v6_rcv() with kfree_skb_reason().
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:30 +0000 (15:06 +0800)]
net: tcp: add skb drop reasons to tcp_v4_rcv()
Use kfree_skb_reason() for some path in tcp_v4_rcv() that missed before,
including:
SKB_DROP_REASON_SOCKET_FILTER
SKB_DROP_REASON_XFRM_POLICY
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Menglong Dong [Sun, 20 Feb 2022 07:06:29 +0000 (15:06 +0800)]
net: tcp: introduce tcp_drop_reason()
For TCP protocol, tcp_drop() is used to free the skb when it needs
to be dropped. To make use of kfree_skb_reason() and pass the drop
reason to it, introduce the function tcp_drop_reason(). Meanwhile,
make tcp_drop() an inline call to tcp_drop_reason().
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Reviewed-by: Hao Peng <flyingpeng@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Volodymyr Mytnyk [Fri, 18 Feb 2022 12:29:11 +0000 (14:29 +0200)]
net: prestera: acl: fix 'client_map' buff overflow
smatch warnings:
drivers/net/ethernet/marvell/prestera/prestera_acl.c:103
prestera_acl_chain_to_client() error: buffer overflow
'client_map' 3 <= 3
prestera_acl_chain_to_client(u32 chain_index, ...)
...
u32 client_map[] = {
PRESTERA_HW_COUNTER_CLIENT_LOOKUP_0,
PRESTERA_HW_COUNTER_CLIENT_LOOKUP_1,
PRESTERA_HW_COUNTER_CLIENT_LOOKUP_2
};
if (chain_index > ARRAY_SIZE(client_map))
...
Fixes:
fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ahmad Fatoum [Fri, 18 Feb 2022 13:15:40 +0000 (14:15 +0100)]
net: dsa: microchip: add ksz8563 to ksz9477 I2C driver
The KSZ9477 SPI driver already has support for the KSZ8563. The same switch
chip can also be managed via i2c and we have an KSZ9477 I2C driver, but
that one lacks the relevant compatible entry. Add it.
DT bindings already describe this compatible.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Fri, 18 Feb 2022 15:32:59 +0000 (18:32 +0300)]
net/smc: unlock on error paths in __smc_setsockopt()
These two error paths need to release_sock(sk) before returning.
Fixes:
a6a6fe27bab4 ("net/smc: Dynamic control handshake limitation by socket options")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Oleksij Rempel [Sat, 19 Feb 2022 08:26:30 +0000 (09:26 +0100)]
net: dsa: microchip: ksz9477: export HW stats over stats64 interface
Provide access to HW offloaded packets over stats64 interface.
The rx/tx_bytes values needed some fixing since HW is accounting size of
the Ethernet frame together with FCS.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 19 Feb 2022 16:41:50 +0000 (16:41 +0000)]
Merge branch 'phylink-remove-pcs_poll'
Russell King says:
====================
net: phylink: remove pcs_poll
This small series removes the now unused pcs_poll members from DSA and
phylink. "git grep pcs_poll drivers/net/ net/" on net-next confirms that
the only places that reference this are in DSA core code and phylink
code:
drivers/net/phy/phylink.c: if (pl->config->pcs_poll || pcs->poll)
drivers/net/phy/phylink.c: poll |= pl->config->pcs_poll;
net/dsa/port.c: dp->pl_config.pcs_poll = ds->pcs_poll;
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Sat, 19 Feb 2022 11:47:22 +0000 (11:47 +0000)]
net: phylink: remove phylink_config's pcs_poll
phylink_config's pcs_poll is no longer used, let's get rid of it.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Sat, 19 Feb 2022 11:47:17 +0000 (11:47 +0000)]
net: dsa: remove pcs_poll
With drivers converted over to using phylink PCS, there is no need for
the struct dsa_switch member "pcs_poll" to exist anymore - there is a
flag in the struct phylink_pcs which indicates whether this PCS needs
to be polled which supersedes this.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Juhee Kang [Sat, 19 Feb 2022 15:29:59 +0000 (15:29 +0000)]
net: hsr: fix suspicious RCU usage warning in hsr_node_get_first()
When hsr_create_self_node() calls hsr_node_get_first(), the suspicious
RCU usage warning is occurred. The reason why this warning is raised is
the callers of hsr_node_get_first() use rcu_read_lock_bh() and
other different synchronization mechanisms. Thus, this patch solved by
replacing rcu_dereference() with rcu_dereference_bh_check().
The kernel test robot reports:
[ 50.083470][ T3596] =============================
[ 50.088648][ T3596] WARNING: suspicious RCU usage
[ 50.093785][ T3596] 5.17.0-rc3-next-
20220208-syzkaller #0 Not tainted
[ 50.100669][ T3596] -----------------------------
[ 50.105513][ T3596] net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage!
[ 50.113799][ T3596]
[ 50.113799][ T3596] other info that might help us debug this:
[ 50.113799][ T3596]
[ 50.124257][ T3596]
[ 50.124257][ T3596] rcu_scheduler_active = 2, debug_locks = 1
[ 50.132368][ T3596] 2 locks held by syz-executor.0/3596:
[ 50.137863][ T3596] #0:
ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x3be/0xb80
[ 50.147470][ T3596] #1:
ffff88807ec9d5f0 (&hsr->list_lock){+...}-{2:2}, at: hsr_create_self_node+0x225/0x650
[ 50.157623][ T3596]
[ 50.157623][ T3596] stack backtrace:
[ 50.163510][ T3596] CPU: 1 PID: 3596 Comm: syz-executor.0 Not tainted 5.17.0-rc3-next-
20220208-syzkaller #0
[ 50.173381][ T3596] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 50.183623][ T3596] Call Trace:
[ 50.186904][ T3596] <TASK>
[ 50.189844][ T3596] dump_stack_lvl+0xcd/0x134
[ 50.194640][ T3596] hsr_node_get_first+0x9b/0xb0
[ 50.199499][ T3596] hsr_create_self_node+0x22d/0x650
[ 50.204688][ T3596] hsr_dev_finalize+0x2c1/0x7d0
[ 50.209669][ T3596] hsr_newlink+0x315/0x730
[ 50.214113][ T3596] ? hsr_dellink+0x130/0x130
[ 50.218789][ T3596] ? rtnl_create_link+0x7e8/0xc00
[ 50.223803][ T3596] ? hsr_dellink+0x130/0x130
[ 50.228397][ T3596] __rtnl_newlink+0x107c/0x1760
[ 50.233249][ T3596] ? rtnl_setlink+0x3c0/0x3c0
[ 50.238043][ T3596] ? is_bpf_text_address+0x77/0x170
[ 50.243362][ T3596] ? lock_downgrade+0x6e0/0x6e0
[ 50.248219][ T3596] ? unwind_next_frame+0xee1/0x1ce0
[ 50.253605][ T3596] ? entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 50.259669][ T3596] ? __sanitizer_cov_trace_cmp4+0x1c/0x70
[ 50.265423][ T3596] ? is_bpf_text_address+0x99/0x170
[ 50.270819][ T3596] ? kernel_text_address+0x39/0x80
[ 50.275950][ T3596] ? __kernel_text_address+0x9/0x30
[ 50.281336][ T3596] ? unwind_get_return_address+0x51/0x90
[ 50.286975][ T3596] ? create_prof_cpu_mask+0x20/0x20
[ 50.292178][ T3596] ? arch_stack_walk+0x93/0xe0
[ 50.297172][ T3596] ? kmem_cache_alloc_trace+0x42/0x2c0
[ 50.302637][ T3596] ? rcu_read_lock_sched_held+0x3a/0x70
[ 50.308194][ T3596] rtnl_newlink+0x64/0xa0
[ 50.312524][ T3596] ? __rtnl_newlink+0x1760/0x1760
[ 50.317545][ T3596] rtnetlink_rcv_msg+0x413/0xb80
[ 50.322631][ T3596] ? rtnl_newlink+0xa0/0xa0
[ 50.327159][ T3596] netlink_rcv_skb+0x153/0x420
[ 50.331931][ T3596] ? rtnl_newlink+0xa0/0xa0
[ 50.336436][ T3596] ? netlink_ack+0xa80/0xa80
[ 50.341095][ T3596] ? netlink_deliver_tap+0x1a2/0xc40
[ 50.346532][ T3596] ? netlink_deliver_tap+0x1b1/0xc40
[ 50.351839][ T3596] netlink_unicast+0x539/0x7e0
[ 50.356633][ T3596] ? netlink_attachskb+0x880/0x880
[ 50.361750][ T3596] ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
[ 50.368003][ T3596] ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
[ 50.374707][ T3596] ? __phys_addr_symbol+0x2c/0x70
[ 50.379753][ T3596] ? __sanitizer_cov_trace_cmp8+0x1d/0x70
[ 50.385568][ T3596] ? __check_object_size+0x16c/0x4f0
[ 50.390859][ T3596] netlink_sendmsg+0x904/0xe00
[ 50.395715][ T3596] ? netlink_unicast+0x7e0/0x7e0
[ 50.400722][ T3596] ? __sanitizer_cov_trace_const_cmp4+0x1c/0x70
[ 50.407003][ T3596] ? netlink_unicast+0x7e0/0x7e0
[ 50.412119][ T3596] sock_sendmsg+0xcf/0x120
[ 50.416548][ T3596] __sys_sendto+0x21c/0x320
[ 50.421052][ T3596] ? __ia32_sys_getpeername+0xb0/0xb0
[ 50.426427][ T3596] ? lockdep_hardirqs_on_prepare+0x400/0x400
[ 50.432721][ T3596] ? __context_tracking_exit+0xb8/0xe0
[ 50.438188][ T3596] ? lock_downgrade+0x6e0/0x6e0
[ 50.443041][ T3596] ? lock_downgrade+0x6e0/0x6e0
[ 50.447902][ T3596] __x64_sys_sendto+0xdd/0x1b0
[ 50.452759][ T3596] ? lockdep_hardirqs_on+0x79/0x100
[ 50.457964][ T3596] ? syscall_enter_from_user_mode+0x21/0x70
[ 50.464150][ T3596] do_syscall_64+0x35/0xb0
[ 50.468565][ T3596] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 50.474452][ T3596] RIP: 0033:0x7f3148504e1c
[ 50.479052][ T3596] Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b
[ 50.498926][ T3596] RSP: 002b:
00007ffeab5f2ab0 EFLAGS:
00000293 ORIG_RAX:
000000000000002c
[ 50.507342][ T3596] RAX:
ffffffffffffffda RBX:
00007f314959d320 RCX:
00007f3148504e1c
[ 50.515393][ T3596] RDX:
0000000000000048 RSI:
00007f314959d370 RDI:
0000000000000003
[ 50.523444][ T3596] RBP:
0000000000000000 R08:
00007ffeab5f2b04 R09:
000000000000000c
[ 50.531492][ T3596] R10:
0000000000000000 R11:
0000000000000293 R12:
0000000000000000
[ 50.539455][ T3596] R13:
00007f314959d370 R14:
0000000000000003 R15:
0000000000000000
Fixes:
4acc45db7115 ("net: hsr: use hlist_head instead of list_head for mac addresses")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-and-tested-by: syzbot+f0eb4f3876de066b128c@syzkaller.appspotmail.com
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christophe JAILLET [Fri, 18 Feb 2022 17:46:51 +0000 (18:46 +0100)]
atm: nicstar: Use kcalloc() to simplify code
Use kcalloc() instead of kmalloc_array() and a loop to set all the values
of the array to NULL.
While at it, remove a duplicated assignment to 'scq->num_entries'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 19 Feb 2022 16:27:17 +0000 (16:27 +0000)]
Merge branch 'dpaa2-eth-one-step-register'
Radu Bulie says:
====================
Provide direct access to 1588 one step register
DPAA2 MAC supports 1588 one step timestamping.
If this option is enabled then for each transmitted PTP event packet,
the 1588 SINGLE_STEP register is accessed to modify the following fields:
-offset of the correction field inside the PTP packet
-UDP checksum update bit, in case the PTP event packet has
UDP encapsulation
These values can change any time, because there may be multiple
PTP clients connected, that receive various 1588 frame types:
- L2 only frame
- UDP / Ipv4
- UDP / Ipv6
- other
The current implementation uses dpni_set_single_step_cfg to update the
SINLGE_STEP register.
Using an MC command on the Tx datapath for each transmitted 1588 message
introduces high delays, leading to low throughput and consequently to a
small number of supported PTP clients. Besides these, the nanosecond
correction field from the PTP packet will contain the high delay from the
driver which together with the originTimestamp will render timestamp
values that are unacceptable in a GM clock implementation.
This patch series replaces the dpni_set_single_step_cfg function call from
the Tx datapath for 1588 messages (when one step timestamping is enabled)
with a callback that either implements direct access to the SINGLE_STEP
register, eliminating the overhead caused by the MC command that will need
to be dispatched by the MC firmware through the MC command portal
interface or falls back to the dpni_set_single_step_cfg in case the MC
version does not have support for returning the single step register
base address.
In other words all the delay introduced by dpni_set_single_step_cfg
function will be eliminated (if MC version has support for returning the
base address of the single step register), improving the egress driver
performance for PTP packets when single step timestamping is enabled.
The first patch adds a new attribute that contains the base address of
the SINGLE_STEP register. It will be used to directly update the register
on the Tx datapath.
The second patch updates the driver such that the SINGLE_STEP
register is either accessed directly if MC version >= 10.32 or is
accessed through dpni_set_single_step_cfg command when 1588 messages
are transmitted.
Changes in v2:
- move global function pointer into the driver's private structure in 2/2
- move repetitive code outside the body of the callback functions in 2/2
- update function dpaa2_ptp_onestep_reg_update_method and remove goto
statement from non error path in 2/2
Changes in v3:
- remove static storage class specifier from within the structure in 2/2
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Radu Bulie [Fri, 18 Feb 2022 20:22:01 +0000 (22:22 +0200)]
dpaa2-eth: Update SINGLE_STEP register access
DPAA2 MAC supports 1588 one step timestamping.
If this option is enabled then for each transmitted PTP event packet,
the 1588 SINGLE_STEP register is accessed to modify the following fields:
-offset of the correction field inside the PTP packet
-UDP checksum update bit, in case the PTP event packet has
UDP encapsulation
These values can change any time, because there may be multiple
PTP clients connected, that receive various 1588 frame types:
- L2 only frame
- UDP / Ipv4
- UDP / Ipv6
- other
The current implementation uses dpni_set_single_step_cfg to update the
SINLGE_STEP register.
Using an MC command on the Tx datapath for each transmitted 1588 message
introduces high delays, leading to low throughput and consequently to a
small number of supported PTP clients. Besides these, the nanosecond
correction field from the PTP packet will contain the high delay from the
driver which together with the originTimestamp will render timestamp
values that are unacceptable in a GM clock implementation.
This patch updates the Tx datapath for 1588 messages when single step
timestamp is enabled and provides direct access to SINGLE_STEP register,
eliminating the overhead caused by the dpni_set_single_step_cfg
MC command. MC version >= 10.32 implements this functionality.
If the MC version does not have support for returning the
single step register base address, the driver will use
dpni_set_single_step_cfg command for updates operations.
All the delay introduced by dpni_set_single_step_cfg
function will be eliminated (if MC version has support for returning the
base address of the single step register), improving the egress driver
performance for PTP packets when single step timestamping is enabled.
Before these changes the maximum throughput for 1588 messages with
single step hardware timestamp enabled was around 2000pps.
After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps.
Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Radu Bulie [Fri, 18 Feb 2022 20:22:00 +0000 (22:22 +0200)]
dpaa2-eth: Update dpni_get_single_step_cfg command
dpni_get_single_step_cfg is an MC firmware command used for
retrieving the contents of SINGLE_STEP 1588 register available
in a DPMAC.
This patch adds a new version of this command that returns as an extra
argument the physical base address of the aforementioned register.
The address will be used to directly modify the contents of the
SINGLE_STEP register instead of invoking the MC command
dpni_set_single_step_cgf. The former approach introduced huge delays on
the TX datapath when one step PTP events were transmitted. This led to low
throughput and high latencies observed in the PTP correction field.
Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 18 Feb 2022 17:58:56 +0000 (09:58 -0800)]
net: get rid of rtnl_lock_unregistering()
After recent patches, and in particular commits
faab39f63c1f ("net: allow out-of-order netdev unregistration") and
e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev")
we no longer need the barrier implemented in rtnl_lock_unregistering().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Volodymyr Mytnyk [Fri, 18 Feb 2022 09:39:49 +0000 (11:39 +0200)]
net: prestera: flower: fix destroy tmpl in chain
Fix flower destroy template callback to release template
only for specific tc chain instead of all chain tempaltes.
The issue was intruduced by previous commit that introduced
multi-chain support.
Fixes:
fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload")
Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 18 Feb 2022 07:01:50 +0000 (23:01 -0800)]
bridge: switch br_net_exit to batch mode
cleanup_net() is competing with other rtnl users.
Instead of calling br_net_exit() for each netns,
call br_net_exit_batch() once.
This gives cleanup_net() ability to group more devices
and call unregister_netdevice_many() only once for all bridge devices.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Roopa Prabhu <roopa@nvidia.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 19 Feb 2022 16:18:50 +0000 (16:18 +0000)]
Merge branch 'mctp-i2c'
Matt Johnston says:
====================
MCTP I2C driver
This patch series adds a netdev driver providing MCTP transport over
I2C.
I think I've addressed all the points raised in v5. It now has
mctp_i2c_unregister() to run things in the correct order, waiting for
the worker thread and I2C rx to complete.
Cheers,
Matt
--
v6:
- Changed netdev register/unregister/free to avoid races. Ensure that
netif functions are not used by irq handler/threads after unregister.
- Fix incoming I2C hwaddr that was previously incorrect (left
shifted 1 bit)
- Add a check that byte_count wire header matches the length received
- Renamed I2C driver to mctp-i2c-interface
- Removed __func__ from print messages, added missing newlines
- Removed sysfs mctp_current_mux file which was used for debug
- Renamed curr_lock to sel_lock
- Tidied comment formatting
- Fix newline in Kconfig
v5:
- Fix incorrect format string
v4:
- Switch to __i2c_transfer() rather than __i2c_smbus_xfer(), drop 255 byte
smbus patches
- Use wait_event_idle() for the sleeping TX thread
- Use dev_addr_set()
v3:
- Added Reviewed-bys for npcm7xx
- Resend with net-next open
v2:
- Simpler Kconfig condition for i2c-mux dependency, from Randy Dunlap
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Matt Johnston [Fri, 18 Feb 2022 05:51:06 +0000 (13:51 +0800)]
mctp i2c: MCTP I2C binding driver
Provides MCTP network transport over an I2C bus, as specified in
DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes.
Each I2C bus to be used for MCTP is flagged in devicetree by a
'mctp-controller' property on the bus node. Each flagged bus gets a
mctpi2cX net device created based on the bus number. A
'mctp-i2c-controller' I2C client needs to be added under the adapter. In
an I2C mux situation the mctp-i2c-controller node must be attached only
to the root I2C bus. The I2C client will handle incoming I2C slave block
write data for subordinate busses as well as its own bus.
In configurations without devicetree a driver instance can be attached
to a bus using the I2C slave new_device mechanism.
The MCTP core will hold/release the MCTP I2C device while responses
are pending (a 6 second timeout or once a socket is closed, response
received etc). While held the MCTP I2C driver will lock the I2C bus so
that the correct I2C mux remains selected while responses are received.
(Ideally we would just lock the mux to keep the current bus selected for
the response rather than a full I2C bus lock, but that isn't exposed in
the I2C mux API)
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Wolfram Sang <wsa@kernel.org> # I2C transport parts
Signed-off-by: David S. Miller <davem@davemloft.net>
Matt Johnston [Fri, 18 Feb 2022 05:51:05 +0000 (13:51 +0800)]
dt-bindings: net: New binding mctp-i2c-controller
Used to define a local endpoint to communicate with MCTP peripherals
attached to an I2C bus. This I2C endpoint can communicate with remote
MCTP devices on the I2C bus.
In the example I2C topology below (matching the second yaml example) we
have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are
indicated by the 'mctp-controller' DT property on an I2C bus node.
A mctp-i2c-controller I2C client DT node is placed at the top of the
mux topology, since only the root I2C adapter will support I2C slave
functionality.
.-------.
|eeprom |
.------------. .------. /'-------'
| adapter | | mux --@0,i2c5------'
| i2c1 ----.*| --@1,i2c6--.--.
|............| \'------' \ \ .........
| mctp-i2c- | \ \ \ .mctpB .
| controller | \ \ '.0x30 .
| | \ ......... \ '.......'
| 0x50 | \ .mctpA . \ .........
'------------' '.0x1d . '.mctpC .
'.......' '.0x31 .
'.......'
(mctpX boxes above are remote MCTP devices not included in the DT at
present, they can be hotplugged/probed at runtime. A DT binding for
specific fixed MCTP devices could be added later if required)
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mobashshera Rasool [Thu, 17 Feb 2022 07:46:40 +0000 (07:46 +0000)]
net: ip6mr: add support for passing full packet on wrong mif
This patch adds support for MRT6MSG_WRMIFWHOLE which is used to pass
full packet and real vif id when the incoming interface is wrong.
While the RP and FHR are setting up state we need to be sending the
registers encapsulated with all the data inside otherwise we lose it.
The RP then decapsulates it and forwards it to the interested parties.
Currently with WRONGMIF we can only be sending empty register packets
and will lose that data.
This behaviour can be enabled by using MRT_PIM with
val == MRT6MSG_WRMIFWHOLE. This doesn't prevent MRT6MSG_WRONGMIF from
happening, it happens in addition to it, also it is controlled by the same
throttling parameters as WRONGMIF (i.e. 1 packet per 3 seconds currently).
Both messages are generated to keep backwards compatibily and avoid
breaking someone who was enabling MRT_PIM with val == 4, since any
positive val is accepted and treated the same.
Signed-off-by: Mobashshera Rasool <mobash.rasool.linux@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Lobakin [Fri, 18 Feb 2022 21:50:33 +0000 (13:50 -0800)]
i40e: remove dead stores on XSK hotpath
The 'if (ntu == rx_ring->count)' block in i40e_alloc_rx_buffers_zc()
was previously residing in the loop, but after introducing the
batched interface it is used only to wrap-around the NTU descriptor,
thus no more need to assign 'xdp'.
'cleaned_count' in i40e_clean_rx_irq_zc() was previously being
incremented in the loop, but after commit
f12738b6ec06
("i40e: remove unnecessary cleaned_count updates") it gets
assigned only once after it, so the initialization can be dropped.
Fixes:
6aab0bb0c5cd ("i40e: Use the xsk batched rx allocation interface")
Fixes:
f12738b6ec06 ("i40e: remove unnecessary cleaned_count updates")
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Sat, 19 Feb 2022 05:24:32 +0000 (21:24 -0800)]
Merge branch 'add-checks-for-incoming-packet-addresses'
Jeremy Kerr says:
====================
Add checks for incoming packet addresses
This series adds a couple of checks for valid addresses on incoming MCTP
packets. We introduce a couple of helpers in 1/2, and use them in the
ingress path in 2/2.
====================
Link: https://lore.kernel.org/r/20220218042554.564787-1-jk@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jeremy Kerr [Fri, 18 Feb 2022 04:25:54 +0000 (12:25 +0800)]
mctp: add address validity checking for packet receive
This change adds some basic sanity checks for the source and dest
headers of packets on initial receive.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jeremy Kerr [Fri, 18 Feb 2022 04:25:53 +0000 (12:25 +0800)]
mctp: replace mctp_address_ok with more fine-grained helpers
Currently, we have mctp_address_ok(), which checks if an EID is in the
"valid" range of 8-254 inclusive. However, 0 and 255 may also be valid
addresses, depending on context. 0 is the NULL EID, which may be set
when physical addressing is used. 255 is valid as a destination address
for broadcasts.
This change renames mctp_address_ok to mctp_address_unicast, and adds
similar helpers for broadcast and null EIDs, which will be used in an
upcoming commit.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jacques de Laval [Thu, 17 Feb 2022 15:02:02 +0000 (16:02 +0100)]
net: Add new protocol attribute to IP addresses
This patch adds a new protocol attribute to IPv4 and IPv6 addresses.
Inspiration was taken from the protocol attribute of routes. User space
applications like iproute2 can set/get the protocol with the Netlink API.
The attribute is stored as an 8-bit unsigned integer.
The protocol attribute is set by kernel for these categories:
- IPv4 and IPv6 loopback addresses
- IPv6 addresses generated from router announcements
- IPv6 link local addresses
User space may pass custom protocols, not defined by the kernel.
Grouping addresses on their origin is useful in scenarios where you want
to distinguish between addresses based on who added them, e.g. kernel
vs. user space.
Tagging addresses with a string label is an existing feature that could be
used as a solution. Unfortunately the max length of a label is
15 characters, and for compatibility reasons the label must be prefixed
with the name of the device followed by a colon. Since device names also
have a max length of 15 characters, only -1 characters is guaranteed to be
available for any origin tag, which is not that much.
A reference implementation of user space setting and getting protocols
is available for iproute2:
https://github.com/westermo/iproute2/commit/
9a6ea18bd79f47f293e5edc7780f315ea42ff540
Signed-off-by: Jacques de Laval <Jacques.De.Laval@westermo.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20220217150202.80802-1-Jacques.De.Laval@westermo.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sat, 19 Feb 2022 04:37:17 +0000 (20:37 -0800)]
Merge branch 'ionic-driver-updates'
Shannon Nelson says:
====================
ionic: driver updates
These are a couple of checkpatch cleanup patches, a bug fix,
and something to alleviate memory pressure in tight places.
====================
Link: https://lore.kernel.org/r/20220217220252.52293-1-snelson@pensando.io
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Shannon Nelson [Thu, 17 Feb 2022 22:02:52 +0000 (14:02 -0800)]
ionic: clean up comments and whitespace
Fix up some checkpatch complaints that have crept in:
doubled words words, mispellled words, doubled lines.
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Shannon Nelson [Thu, 17 Feb 2022 22:02:51 +0000 (14:02 -0800)]
ionic: prefer strscpy over strlcpy
Replace strlcpy with strscpy to clean up a checkpatch complaint.
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Brett Creeley [Thu, 17 Feb 2022 22:02:50 +0000 (14:02 -0800)]
ionic: Use vzalloc for large per-queue related buffers
Use vzalloc for per-queue info structs that don't need any
DMA mapping to help relieve memory pressure found when used
in our limited SOC environment.
Signed-off-by: Brett Creeley <brett@pensando.io>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Shannon Nelson [Thu, 17 Feb 2022 22:02:49 +0000 (14:02 -0800)]
ionic: catch transition back to RUNNING with fw_generation 0
In some graceful updates that get initially triggered by the
RESET event, especially with older firmware, the fw_generation
bits don't change but the fw_status is seen to go to 0 then back
to 1. However, the driver didn't perform the restart, remained
waiting for fw_generation to change, and got left in limbo.
This is because the clearing of idev->fw_status_ready to 0
didn't happen correctly as it was buried in the transition
trigger: since the transition down was triggered not here
but in the RESET event handler, the clear to 0 didn't happen,
so the transition back to 1 wasn't detected.
Fix this particular case by bringing the setting of
idev->fw_status_ready back out to where it was before.
Fixes:
398d1e37f960 ("ionic: add FW_STOPPING state")
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Fri, 18 Feb 2022 06:54:30 +0000 (22:54 -0800)]
net: avoid quadratic behavior in netdev_wait_allrefs_any()
If the list of devices has N elements, netdev_wait_allrefs_any()
is called N times, and linkwatch_forget_dev() is called N*(N-1)/2 times.
Fix this by calling linkwatch_forget_dev() only once per device.
Fixes:
faab39f63c1f ("net: allow out-of-order netdev unregistration")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20220218065430.2613262-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Thu, 17 Feb 2022 23:48:41 +0000 (15:48 -0800)]
ipv6: annotate some data-races around sk->sk_prot
IPv6 has this hack changing sk->sk_prot when an IPv6 socket
is 'converted' to an IPv4 one with IPV6_ADDRFORM option.
This operation is only performed for TCP and UDP, knowing
their 'struct proto' for the two network families are populated
in the same way, and can not disappear while a reader
might use and dereference sk->sk_prot.
If we think about it all reads of sk->sk_prot while
either socket lock or RTNL is not acquired should be using READ_ONCE().
Also note that other layers like MPTCP, XFRM, CHELSIO_TLS also
write over sk->sk_prot.
BUG: KCSAN: data-race in inet6_recvmsg / ipv6_setsockopt
write to 0xffff8881386f7aa8 of 8 bytes by task 26932 on cpu 0:
do_ipv6_setsockopt net/ipv6/ipv6_sockglue.c:492 [inline]
ipv6_setsockopt+0x3758/0x3910 net/ipv6/ipv6_sockglue.c:1019
udpv6_setsockopt+0x85/0x90 net/ipv6/udp.c:1649
sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3489
__sys_setsockopt+0x209/0x2a0 net/socket.c:2180
__do_sys_setsockopt net/socket.c:2191 [inline]
__se_sys_setsockopt net/socket.c:2188 [inline]
__x64_sys_setsockopt+0x62/0x70 net/socket.c:2188
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff8881386f7aa8 of 8 bytes by task 26911 on cpu 1:
inet6_recvmsg+0x7a/0x210 net/ipv6/af_inet6.c:659
____sys_recvmsg+0x16c/0x320
___sys_recvmsg net/socket.c:2674 [inline]
do_recvmmsg+0x3f5/0xae0 net/socket.c:2768
__sys_recvmmsg net/socket.c:2847 [inline]
__do_sys_recvmmsg net/socket.c:2870 [inline]
__se_sys_recvmmsg net/socket.c:2863 [inline]
__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2863
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffffffff85e0e980 -> 0xffffffff85e01580
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 26911 Comm: syz-executor.3 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cédric Le Goater [Fri, 18 Feb 2022 08:07:08 +0000 (09:07 +0100)]
net/ibmvnic: Cleanup workaround doing an EOI after partition migration
There were a fair amount of changes to workaround a firmware bug leaving
a pending interrupt after migration of the ibmvnic device :
commit
2df5c60e198c ("net/ibmvnic: Ignore H_FUNCTION return from H_EOI
to tolerate XIVE mode")
commit
284f87d2f387 ("Revert "net/ibmvnic: Fix EOI when running in
XIVE mode"")
commit
11d49ce9f794 ("net/ibmvnic: Fix EOI when running in XIVE mode.")
commit
f23e0643cd0b ("ibmvnic: Clear pending interrupt after device reset")
Here is the final one taking into account the XIVE interrupt mode.
Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Cc: Dany Madden <drt@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
jeffreyji [Thu, 17 Feb 2022 21:23:12 +0000 (21:23 +0000)]
teaming: deliver link-local packets with the link they arrive on
skb is ignored if team port is disabled. We want the skb to be delivered
if it's an link layer packet.
Issue is already fixed for bonding in
commit
b89f04c61efe ("bonding: deliver link-local packets with skb->dev set to link that packets arrived on")
changelog:
v2: change LLDP -> link layer in comments/commit descrip, comment format
Signed-off-by: jeffreyji <jeffreyji@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 18 Feb 2022 11:28:33 +0000 (11:28 +0000)]
Merge branch 'qca8k-phylink'
Russell King says:
====================
net: dsa: qca8k: convert to phylink_pcs and mark as non-legacy
This series adds support into DSA for the mac_select_pcs method, and
converts qca8k to make use of this, eventually marking qca8k as non-
legacy.
Patch 1 adds DSA support for mac_select_pcs.
Patch 2 and patch 3 moves code around in qca8k to make patch 4 more
readable.
Patch 4 does a simple conversion to phylink_pcs.
Patch 5 moves the serdes configuration to phylink_pcs.
Patch 6 marks qca8k as non-legacy.
v2: fix dsa_phylink_mac_select_pcs() formatting and double-blank line
in patch 5
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Thu, 17 Feb 2022 18:31:01 +0000 (18:31 +0000)]
net: dsa: qca8k: mark as non-legacy
The qca8k driver does not make use of the speed, duplex, pause or
advertisement in its phylink_mac_config() implementation, so it can be
marked as a non-legacy driver.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Thu, 17 Feb 2022 18:30:56 +0000 (18:30 +0000)]
net: dsa: qca8k: move pcs configuration
Move the PCS configuration to qca8k_pcs_config().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Thu, 17 Feb 2022 18:30:51 +0000 (18:30 +0000)]
net: dsa: qca8k: convert to use phylink_pcs
Convert the qca8k driver to use the phylink_pcs support to talk to the
SGMII PCS.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King (Oracle) [Thu, 17 Feb 2022 18:30:45 +0000 (18:30 +0000)]
net: dsa: qca8k: move qca8k_phylink_mac_link_state()
Move qca8k_phylink_mac_link_state() to separate the code movement from
code changes.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
projects / platform / kernel / linux-starfive.git / log