The issue was discovered via smatch static analyzer:
make CHECK="smatch -p=kernel" C=2 drivers/net/phy/microchip_t1.o
CHECK scripts/mod/empty.c
DESCEND objtool
CHECK drivers/net/phy/microchip_t1.c
drivers/net/phy/microchip_t1.c:1295 lan887x_phy_init() warn: 'priv->clock' can also be NULL
mchp_rds_ptp_probe() returns NULL when CONFIG_MICROCHIP_PHY_RDS_PTP or
CONFIG_PTP_1588_CLOCK is disabled. However, lan887x_phy_init() only checks
for an error pointer before using the returned clock to configure the
periodic output pin, which can result in a NULL pointer dereference.
Handle the NULL return as PTP being unavailable and skip the event pin
configuration in that case. Smatch no longer reports the NULL dereference
warning after the change.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Reviewed-by: Divya Koppera <Divya.Koppera@microchip.com>
Signed-off-by: Henry Hu <huhai@kylinos.cn>
Link: https://patch.msgid.link/20260903113046.163630-1-15815827059@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-27-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Acked-by: Vivian Wang <wangruikang@iscas.ac.cn>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-26-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-25-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-24-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-23-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-22-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-21-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-20-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-19-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-18-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-17-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-16-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-15-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-14-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-13-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-12-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-11-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-10-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-9-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-8-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-7-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Acked-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-6-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-5-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-4-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-3-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-2-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Daniel Zahka says:
====================
psp: make tx key ops optional for drivers
This is the first of two series which together implement rekeying PSP
protected tcp connections. Here are both series together on github:
https://github.com/danieldzahka/linux/commits/psp-rekey-split/
This first series is mostly non-functional changes, except for the minor
difference that netdevsim driver implements tx key ops. Its tx key ops
were basically NOPs, and in the future PSP core can subsume the assoc
counting that it was doing.
The purpose of the refactors is to make code reusable from paths that
will be added to the code in the rekeying series.
Patch 1 exists to setup two paths for tx key deletion, one where keys
are deleted as they are now in psp_assoc_free() when the assoc refcount
drops to 0, and a different path in series two, where the keys will get
put onto a queue for deferred deletion.
Patch 2 exists to allow tx assoc state to be set either from the
connection setup path, or in series two, from a tx rekeying path.
Patch 3 makes implementing tx_key_add and tx_key_del optional for
drivers. These callbacks only make sense for devices that utilize a tx
SADB. This distinction is important once rekeying is involved, because
an SADB implies a race between in flight tx packets and key deletion,
that does not exist for non-SADB implementations.
Patch 4 removes the unnecessary tx key ops in netdevsim.
No new tests are added to this series. There is no real user visible
change of behavior.
====================
Link: https://patch.msgid.link/20260903-psp-prep-v1-0-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netdevsim has no SADB. The usage of psp_assoc_drv_data() was always
obsolete given psp_validate_xmit(), so we can remove nsim_assoc_add()
and nsim_assoc_del(). netdevsim::assoc_cnt can also be removed. PSP core
can track the balance of tx_key_add vs tx_key_del calls in a future
change.
Delete psp_assoc_drv_data() because there are no more callers left in
the tree. mlx5 accesses pas->drv_data directly.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-4-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drivers that don't use an SADB for tx key storage don't have a use
for psp_dev_ops::tx_key_add and psp_dev_ops::tx_key_del.
Allowing drivers to leave these as NULL gives PSP core a simple way to
determine whether a driver utilizes an SADB, which in turn could
affect how PSP core chooses to handle certain situations.
For example:
- deciding if tx key deletion needs to be delayed during a rekeying
event to avoid in-flight packets using old key handles.
- choosing whether or not to report device stats like SADB usage to
userspace, which only make sense if the driver uses on-device key
storage.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-3-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
No functional changes.
Lift code that needs to be called from both initial tx establishment
and tx rekeying into functions that can be reused in both paths.
The plaintext in recv queue checks and mss adjustment only run on
initial tx keying. The dummy psp_assoc machinery will be used in both
paths.
psp_dev_tx_key_add() absorbs the dummy assoc machinery, as its main
purpose is to populate the device specific psp_assoc:drv_data.
psp_assoc_set_tx() exists so that a future change can allow
psp_dev_tx_key_add() to be skipped entirely for devices that don't use
an SADB, while copying of the tx spi and key into the assoc needs to
happen regardless of SADB vs. no SADB.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-2-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
No functional changes.
Lift the list deletion and tx spi validation code into
callers. Deferred key deletion code paths will need similar checks
that a tx key needs removal from the underlying device, but will
diverge when it comes to list handling and when to call
psp_dev_ops::tx_key_del().
Also, move the predicate for tx key deletion into a helper for
readability and reuse in later patches.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-1-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dma_*() barriers are specifically for ordering writes to DMA
coherent memory that is accessible to both the CPU and DMA capable
devices.
The dma_wmb() barrier is lighter than wmb() on some architectures
because it only ensures ordering for DMA writes, not for all writes
including MMIO accesses.
In the MLX5 driver, completion queue (CQ) doorbell records are
allocated as DMA coherent memory via mlx5_dma_zalloc_coherent_node().
The CQ update pattern is:
1. Update CQ space (device reads via DMA)
2. Update doorbell record (device reads via DMA)
3. Memory barrier
4. Enable more CQEs
Since only DMA coherent memory accesses are involved (no MMIO accesses
follow), we can safely use dma_wmb() instead of wmb().
This change improves performance slightly on architectures where
dma_wmb() is lighter than wmb().
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260902023429.1717-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jinjie Ruan says:
====================
8021q: publish vlan_devices_arrays entries with acquire/release
This series fixes a speculative lockless data race in the 8021q
VLAN receive fast-path, and publish vlan_devices_arrays entries
with acquire/release for better performance.
====================
Link: https://patch.msgid.link/20260902073334.397685-1-ruanjinjie@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace the smp_wmb()/smp_rmb() barrier pair with
smp_store_release()/smp_load_acquire() on
vg->vlan_devices_arrays[pidx][vidx].
vlan_group_prealloc_vid() publishes the array pointer via release;
__vlan_group_get_device() acquires it before accessing the array,
ensuring the allocated entries are visible.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A plain C read and assignment of the net_device pointer
in the vlan_devices_arrays leaf entries lack proper atomicity
and ordering barriers. A concurrent lockless reader on the packet
receive fast-path could observe a torn or partially initialized
net_device pointer, leading to a potential out-of-bounds read or kernel
panic.
The data race occurs between the netlink/ioctl configuration paths
(holding the per-netns rtnl_nets_lock or RTNL lock) and the softirq
receive fast-path (holding rcu_read_lock()):
CPU 0 (Writer, rtnl_nets_lock/RTNL) CPU 1 (Reader, rcu_read_lock())
----------------------------------- -------------------------------
rtnetlink_rcv_msg()
// RTM_NEWLINK handler with RTNL_FLAG_DOIT_PERNET
rtnl_newlink()
ops->newlink() == vlan_newlink()
OR
vlan_ioctl_handler()
[ADD_VLAN_CMD] -> register_vlan_device()
register_vlan_dev()
vlan_group_set_device()
netif_receive_skb_core()
vlan_do_receive()
vlan_find_dev()
__vlan_group_get_device()
// Speculative / torn read
[Loads bad net_device *]
[Plain C store]
array[vlan_id] = dev;
// Dereferences bad pointer
// during device status check
vlan_dev->flags (PANIC!)
Fix this by using rcu_assign_pointer() in vlan_group_set_device()
and rcu_dereference_raw() in __vlan_group_get_device() to enforce
proper ordering and memory atomicity for the leaf entry traversal.
Link: https://sashiko.dev/#/patchset/20260825095422.3166067-1-ruanjinjie%40huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Chia-Yu Chang says:
====================
Explicit TSO segment count
This series replaces the existing min_tso_segs() congestion control
callback with a new tso_segs() callback that allows congestion control
algorithms to provide an explicit TSO segment count for each data burst.
To support BPF congestion controls, the series also exposes
tcp_tso_autosize() as a BPF kfunc, allowing BPF implementations to
reuse the kernel TSO autosizing logic while implementing custom
tso_segs() callbacks.
====================
Link: https://patch.msgid.link/20260831165230.2696893-1-chia-yu.chang@nokia-bell-labs.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Expose tcp_tso_autosize() as a BPF kfunc and register it in the TCP
congestion-control kfunc set. This allows BPF congestion controls to
reuse the kernel TSO autosizing logic while applying their own
minimum TSO segment policy.
To make the kfunc robust against BPF-provided inputs, min_tso_segs is
sanitized to at least 1 and mss_now == 0 returns the sanitized minimum
value instead of performing autosizing.
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch replaces the existing min_tso_segs() callback with a new
tso_segs() callback, allowing congestion control algorithms to provide
an explicit TSO segment count for each data burst and bypass
tcp_tso_autosize(). The resulting tso_segs value is clamped to
[1, sk->sk_gso_max_segs], preventing congestion-control implementations
from returning an invalid zero-segment value.
This change has the following impacts on BPF struct_ops users:
- The callback is renamed from min_tso_segs() to tso_segs()
- The signature gains an extra u32 mss_now argument
- The return value semantics is changed from "floor value passed into
tcp_tso_autosize()" to "final tso_segs value", bypassing autosizing
As a result, existing BPF programs must be updated, because returning a
small constant will now directly limit the final tso_segs value instead
of specifying the minimum value passed to tcp_tso_autosize().
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Signed-off-by: Ilpo Järvinen <ij@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netvsc_run_xdp() in drivers/net/hyperv/netvsc_bpf.c has handled
XDP_REDIRECT since commit 1cb9d3b618 ("hv_netvsc: Add support for
XDP_REDIRECT"), and netvsc_drv.c advertises NETDEV_XDP_ACT_REDIRECT
in xdp_features. Remove the stale note.
Link: https://patch.msgid.link/20260831200357.45390-1-chrismelnu@gmail.com
Signed-off-by: Christian Melendez <chrismelnu@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2026-09-01 (i40e)
Kohei Enju adds support for XDP metadata of Rx hash and VLAN tag.
Chris Packham reduces messaging when Rx filters are exhausted, and
promiscuous mode is enabled, to occur once when the mode is enabled
rather than repeated messaging for each filter.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
i40e: Avoid repeating RX filter warning
i40e: add support for bpf_xdp_metadata_rx_vlan_tag()
i40e: add support for bpf_xdp_metadata_rx_hash()
i40e: prepare for XDP metadata ops support
====================
Link: https://patch.msgid.link/20260901211752.1922993-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bind_wildcard picks an ephemeral port by binding fd[0] with port 0, reads
it back with getsockname(), and then reuses that exact port number for the
other addresses/families in fd[1..7]. This all happens in the default
network namespace, so unrelated processes on the same host are drawing from
the very same ephemeral port range (net.ipv4.ip_local_port_range) at the
same time.
Such a process can independently get assigned that exact port number on a
different, non-conflicting address in the short window between fd[0]'s
bind() and fd[1]'s, making fd[1]'s bind() fail with EADDRINUSE for reasons
that have nothing to do with the wildcard-bind behavior under test, e.g.:
# bind_wildcard.c:775:plain:Expected ret (-1) == 0 (0)
# plain: Test terminated by assertion
not ok N bind_wildcard.v6_local_v4_local.plain
Fix it the same way so_incoming_cpu.c, tcp_port_share.c and
reuseport_dualstack.c already do: unshare into a fresh network namespace
and bring lo up, so there is nobody else to race with for the port.
Signed-off-by: Ricardo B. Marlière (SUSE) <ricardo@marliere.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
