Skip to content

netdev CI testing #6666

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 708 commits into
base: bpf-next_base
Choose a base branch
from
Open

Conversation

kuba-moo
Copy link
Contributor

Reusable PR for hooking netdev CI to BPF testing.

@kernel-patches-daemon-bpf kernel-patches-daemon-bpf bot force-pushed the bpf-next_base branch 3 times, most recently from 4f22ee0 to 8a9a8e0 Compare March 28, 2024 04:46
@kuba-moo kuba-moo force-pushed the to-test branch 11 times, most recently from 64c403f to 8da1f58 Compare March 29, 2024 00:01
@kernel-patches-daemon-bpf kernel-patches-daemon-bpf bot force-pushed the bpf-next_base branch 3 times, most recently from 78ebb17 to 9325308 Compare March 29, 2024 02:14
@kuba-moo kuba-moo force-pushed the to-test branch 6 times, most recently from c8c7b2f to a71aae6 Compare March 29, 2024 18:01
@kuba-moo kuba-moo force-pushed the to-test branch 2 times, most recently from d8feb00 to b16a6b9 Compare March 30, 2024 00:01
@kuba-moo kuba-moo force-pushed the to-test branch 2 times, most recently from 4164329 to c5cecb3 Compare March 30, 2024 06:00
mina and others added 29 commits April 29, 2025 08:00
Later patches in the series adds TX net_iovs where there is no pp
associated, so we can't rely on niov->pp->mp_ops to tell what is the
type of the net_iov.

Add a type enum to the net_iov which tells us the net_iov type.

Signed-off-by: Mina Almasry <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Currently net_iovs support only pp ref counts, and do not support a
page ref equivalent.

This is fine for the RX path as net_iovs are used exclusively with the
pp and only pp refcounting is needed there. The TX path however does not
use pp ref counts, thus, support for get_page/put_page equivalent is
needed for netmem.

Support get_netmem/put_netmem. Check the type of the netmem before
passing it to page or net_iov specific code to obtain a page ref
equivalent.

For dmabuf net_iovs, we obtain a ref on the underlying binding. This
ensures the entire binding doesn't disappear until all the net_iovs have
been put_netmem'ed. We do not need to track the refcount of individual
dmabuf net_iovs as we don't allocate/free them from a pool similar to
what the buddy allocator does for pages.

This code is written to be extensible by other net_iov implementers.
get_netmem/put_netmem will check the type of the netmem and route it to
the correct helper:

pages -> [get|put]_page()
dmabuf net_iovs -> net_devmem_[get|put]_net_iov()
new net_iovs ->	new helpers

Signed-off-by: Mina Almasry <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Add bind-tx netlink call to attach dmabuf for TX; queue is not
required, only ifindex and dmabuf fd for attachment.

Signed-off-by: Stanislav Fomichev <[email protected]>
Signed-off-by: Mina Almasry <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Augment dmabuf binding to be able to handle TX. Additional to all the RX
binding, we also create tx_vec needed for the TX path.

Provide API for sendmsg to be able to send dmabufs bound to this device:

- Provide a new dmabuf_tx_cmsg which includes the dmabuf to send from.
- MSG_ZEROCOPY with SCM_DEVMEM_DMABUF cmsg indicates send from dma-buf.

Devmem is uncopyable, so piggyback off the existing MSG_ZEROCOPY
implementation, while disabling instances where MSG_ZEROCOPY falls back
to copying.

We additionally pipe the binding down to the new
zerocopy_fill_skb_from_devmem which fills a TX skb with net_iov netmems
instead of the traditional page netmems.

We also special case skb_frag_dma_map to return the dma-address of these
dmabuf net_iovs instead of attempting to map pages.

The TX path may release the dmabuf in a context where we cannot wait.
This happens when the user unbinds a TX dmabuf while there are still
references to its netmems in the TX path. In that case, the netmems will
be put_netmem'd from a context where we can't unmap the dmabuf, Resolve
this by making __net_devmem_dmabuf_binding_free schedule_work'd.

Based on work by Stanislav Fomichev <[email protected]>. A lot of the meat
of the implementation came from devmem TCP RFC v1[1], which included the
TX path, but Stan did all the rebasing on top of netmem/net_iov.

Cc: Stanislav Fomichev <[email protected]>
Signed-off-by: Kaiyuan Zhang <[email protected]>
Signed-off-by: Mina Almasry <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Add documentation outlining the usage and details of the devmem TCP TX
API.

Signed-off-by: Mina Almasry <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Drivers need to make sure not to pass netmem dma-addrs to the
dma-mapping API in order to support netmem TX.

Add helpers and netmem_dma_*() helpers that enables special handling of
netmem dma-addrs that drivers can use.

Document in netmem.rst what drivers need to do to support netmem TX.

Signed-off-by: Mina Almasry <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Use netmem_dma_*() helpers in gve_tx_dqo.c DQO-RDA paths to
enable netmem TX support in that mode.

Declare support for netmem TX in GVE DQO-RDA mode.

Signed-off-by: Mina Almasry <[email protected]>
Acked-by: Harshitha Ramamurthy <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
We should not enable netmem TX for drivers that don't declare support.

Check for driver netmem TX support during devmem TX binding and fail if
the driver does not have the functionality.

Check for driver support in validate_xmit_skb as well.

Signed-off-by: Mina Almasry <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Add support for devmem TX in ncdevmem.

This is a combination of the ncdevmem from the devmem TCP series RFCv1
which included the TX path, and work by Stan to include the netlink API
and refactored on top of his generic memory_provider support.

Signed-off-by: Mina Almasry <[email protected]>
Signed-off-by: Stanislav Fomichev <[email protected]>
Acked-by: Stanislav Fomichev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Always map the `skb` to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Thangaraj Samynathan <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
After 52358dd ("net: phy: remove function stubs") there's a
problem if CONFIG_MDIO_BUS is set, but CONFIG_PHYLIB is not.
mdiobus_scan() uses phylib functions like get_phy_device().
Bringing back the stub wouldn't make much sense, because it would
allow to compile mdiobus_scan(), but the function would be unusable.
The stub returned NULL, and we have the following in mdiobus_scan():

phydev = get_phy_device(bus, addr, c45);
        if (IS_ERR(phydev))
                return phydev;

So calling mdiobus_scan() w/o CONFIG_PHYLIB would cause a crash later in
mdiobus_scan(). In general the PHYLIB functionality isn't optional here.
Consequently, MDIO bus providers depend on PHYLIB.
Therefore factor it out and build it together with the libphy core
modules. In addition make all MDIO bus providers under /drivers/net/mdio
depend on PHYLIB. Same applies to enetc MDIO bus provider. Note that
PHYLIB selects MDIO_DEVRES, therefore we can omit this here.

Fixes: 52358dd ("net: phy: remove function stubs")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Enabling of the temperature sensor was moved from mv88q2xxx_hwmon_probe to
mv88q222x_config_init with the consequence that the sensor is only
usable when the PHY is configured. Enable the sensor in
mv88q2xxx_hwmon_probe as well to fix this.

Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Dimitri Fedrau <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
On Adva boards, SMA sysfs store/get operations can call
__handle_signal_outputs() or __handle_signal_inputs() while the `irig`
and `dcf` pointers are uninitialized, leading to a NULL pointer
dereference in __handle_signal() and causing a kernel crash. Adva boards
don't use `irig` or `dcf` functionality, so add Adva-specific callbacks
`ptp_ocp_sma_adva_set_outputs()` and `ptp_ocp_sma_adva_set_inputs()` that
avoid invoking `irig` or `dcf` input/output routines.

Fixes: ef61f55 ("ptp: ocp: add Adva timecard support")
Signed-off-by: Sagi Maimon <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Activate TX hang workaround also in
fec_enet_txq_submit_skb() when TSO is not enabled.

Errata: ERR007885

Symptoms: NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out

commit 37d6017 ("net: fec: Workaround for imx6sx enet tx hang when enable three queues")
There is a TDAR race condition for mutliQ when the software sets TDAR
and the UDMA clears TDAR simultaneously or in a small window (2-4 cycles).
This will cause the udma_tx and udma_tx_arbiter state machines to hang.

So, the Workaround is checking TDAR status four time, if TDAR cleared by
    hardware and then write TDAR, otherwise don't set TDAR.

Fixes: 53bb20d ("net: fec: add variable reg_desc_active to speed things up")
Signed-off-by: Mattias Barthel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
The RTL8211F supports multiple WOL modes. This patch adds support for
magic packets.

The PHY notifies the system via the INTB/PMEB pin when a WOL event
occurs.

Signed-off-by: Daniel Braunwarth <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
When the host loses heartbeat messages from the device,
the driver calls the device-specific ndo_stop function,
which frees the resources. If the driver is unloaded in
this scenario, it calls ndo_stop again, attempting to free
resources that have already been freed, leading to a host
hang issue. To resolve this, dev_close should be called
instead of the device-specific stop function.dev_close
internally calls ndo_stop to stop the network interface
and performs additional cleanup tasks. During the driver
unload process, if the device is already down, ndo_stop
is not called.

Fixes: 5cb96c2 ("octeon_ep: add heartbeat monitor")
Signed-off-by: Sathesh B Edara <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
…II delays

Device Tree and Ethernet MAC driver writers often misunderstand RGMII
delays. Add an Informative section to the end of the binding
describing in detail what the four RGMII delays mean.

Additionally, when the MAC or PHY needs to add a delay, which is
software configuration, describe how Linux does this, in the hope of
reducing errors. Make it clear other users of device tree binding may
implement the software configuration in other ways while still
conforming to the binding.

Fixes: 9d3de3c ("dt-bindings: net: Add YAML schemas for the generic Ethernet options")
Signed-off-by: Andrew Lunn <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
…al LWT setup

Recent updates to the locking mechanism that protects IPv6 routing tables
[1] have affected the SRv6 networking subsystem. Such changes cause
problems with some SRv6 Endpoints behaviors, like End.B6.Encaps and also
impact SRv6 counters.

Starting from commit 169fd62 ("ipv6: Get rid of RTNL for SIOCADDRT and
RTM_NEWROUTE."), the inet6_rtm_newroute() function no longer needs to
acquire the RTNL lock for creating and configuring IPv6 routes and set up
lwtunnels.
The RTNL lock can be avoided because the ip6_route_add() function
finishes setting up a new route in a section protected by RCU.
This makes sure that no dev/nexthops can disappear during the operation.
Because of this, the steps for setting up lwtunnels - i.e., calling
lwtunnel_build_state() - are now done in a RCU lock section and not
under the RTNL lock anymore.

However, creating and configuring a lwtunnel instance in an
RCU-protected section can be problematic when that tunnel needs to
allocate memory using the GFP_KERNEL flag.
For example, the following trace shows what happens when an SRv6
End.B6.Encaps behavior is instantiated after commit 169fd62 ("ipv6:
Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE."):

[ 3061.219696] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321
[ 3061.226136] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 445, name: ip
[ 3061.232101] preempt_count: 0, expected: 0
[ 3061.235414] RCU nest depth: 1, expected: 0
[ 3061.238622] 1 lock held by ip/445:
[ 3061.241458]  #0: ffffffff83ec64a0 (rcu_read_lock){....}-{1:3}, at: ip6_route_add+0x41/0x1e0
[ 3061.248520] CPU: 1 UID: 0 PID: 445 Comm: ip Not tainted 6.15.0-rc3-micro-vm-dev-00590-ge527e891492d kernel-patches#2058 PREEMPT(full)
[ 3061.248532] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 3061.248549] Call Trace:
[ 3061.248620]  <TASK>
[ 3061.248633]  dump_stack_lvl+0xa9/0xc0
[ 3061.248846]  __might_resched+0x218/0x360
[ 3061.248871]  __kmalloc_node_track_caller_noprof+0x332/0x4e0
[ 3061.248889]  ? rcu_is_watching+0x3a/0x70
[ 3061.248902]  ? parse_nla_srh+0x56/0xa0
[ 3061.248938]  kmemdup_noprof+0x1c/0x40
[ 3061.248952]  parse_nla_srh+0x56/0xa0
[ 3061.248969]  seg6_local_build_state+0x2e0/0x580
[ 3061.248992]  ? __lock_acquire+0xaff/0x1cd0
[ 3061.249013]  ? do_raw_spin_lock+0x111/0x1d0
[ 3061.249027]  ? __pfx_seg6_local_build_state+0x10/0x10
[ 3061.249068]  ? lwtunnel_build_state+0xe1/0x3a0
[ 3061.249274]  lwtunnel_build_state+0x10d/0x3a0
[ 3061.249303]  fib_nh_common_init+0xce/0x1e0
[ 3061.249337]  ? __pfx_fib_nh_common_init+0x10/0x10
[ 3061.249352]  ? in6_dev_get+0xaf/0x1f0
[ 3061.249369]  ? __rcu_read_unlock+0x64/0x2e0
[ 3061.249392]  fib6_nh_init+0x290/0xc30
[ 3061.249422]  ? __pfx_fib6_nh_init+0x10/0x10
[ 3061.249447]  ? __lock_acquire+0xaff/0x1cd0
[ 3061.249459]  ? _raw_spin_unlock_irqrestore+0x22/0x70
[ 3061.249624]  ? ip6_route_info_create+0x423/0x520
[ 3061.249641]  ? rcu_is_watching+0x3a/0x70
[ 3061.249683]  ip6_route_info_create_nh+0x190/0x390
[ 3061.249715]  ip6_route_add+0x71/0x1e0
[ 3061.249730]  ? __pfx_inet6_rtm_newroute+0x10/0x10
[ 3061.249743]  inet6_rtm_newroute+0x426/0xc50
[ 3061.249764]  ? avc_has_perm_noaudit+0x13d/0x360
[ 3061.249853]  ? __pfx_inet6_rtm_newroute+0x10/0x10
[ 3061.249905]  ? __lock_acquire+0xaff/0x1cd0
[ 3061.249962]  ? rtnetlink_rcv_msg+0x52f/0x890
[ 3061.249996]  ? __pfx_inet6_rtm_newroute+0x10/0x10
[ 3061.250012]  rtnetlink_rcv_msg+0x551/0x890
[ 3061.250040]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[ 3061.250065]  ? __lock_acquire+0xaff/0x1cd0
[ 3061.250092]  netlink_rcv_skb+0xbd/0x1f0
[ 3061.250108]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[ 3061.250124]  ? __pfx_netlink_rcv_skb+0x10/0x10
[ 3061.250179]  ? netlink_deliver_tap+0x10b/0x700
[ 3061.250210]  netlink_unicast+0x2e7/0x410
[ 3061.250232]  ? __pfx_netlink_unicast+0x10/0x10
[ 3061.250241]  ? __lock_acquire+0xaff/0x1cd0
[ 3061.250280]  netlink_sendmsg+0x366/0x670
[ 3061.250306]  ? __pfx_netlink_sendmsg+0x10/0x10
[ 3061.250313]  ? find_held_lock+0x2d/0xa0
[ 3061.250344]  ? import_ubuf+0xbc/0xf0
[ 3061.250370]  ? __pfx_netlink_sendmsg+0x10/0x10
[ 3061.250381]  __sock_sendmsg+0x13e/0x150
[ 3061.250420]  ____sys_sendmsg+0x33d/0x450
[ 3061.250442]  ? __pfx_____sys_sendmsg+0x10/0x10
[ 3061.250453]  ? __pfx_copy_msghdr_from_user+0x10/0x10
[ 3061.250489]  ? __pfx_slab_free_after_rcu_debug+0x10/0x10
[ 3061.250514]  ___sys_sendmsg+0xe5/0x160
[ 3061.250530]  ? __pfx____sys_sendmsg+0x10/0x10
[ 3061.250568]  ? __lock_acquire+0xaff/0x1cd0
[ 3061.250617]  ? find_held_lock+0x2d/0xa0
[ 3061.250678]  ? __virt_addr_valid+0x199/0x340
[ 3061.250704]  ? preempt_count_sub+0xf/0xc0
[ 3061.250736]  __sys_sendmsg+0xca/0x140
[ 3061.250750]  ? __pfx___sys_sendmsg+0x10/0x10
[ 3061.250786]  ? syscall_exit_to_user_mode+0xa2/0x1e0
[ 3061.250825]  do_syscall_64+0x62/0x140
[ 3061.250844]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 3061.250855] RIP: 0033:0x7f0b042ef914
[ 3061.250868] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53
[ 3061.250876] RSP: 002b:00007ffc2d113ef8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 3061.250885] RAX: ffffffffffffffda RBX: 00000000680f93fa RCX: 00007f0b042ef914
[ 3061.250891] RDX: 0000000000000000 RSI: 00007ffc2d113f60 RDI: 0000000000000003
[ 3061.250897] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008
[ 3061.250902] R10: fffffffffffff26d R11: 0000000000000246 R12: 0000000000000001
[ 3061.250907] R13: 000055a961f8a520 R14: 000055a961f63eae R15: 00007ffc2d115270
[ 3061.250952]  </TASK>

To solve this issue, we replace the GFP_KERNEL flag with the GFP_ATOMIC
one in those SRv6 Endpoints that need to allocate memory during the
setup phase. This change makes sure that memory allocations are handled
in a way that works with RCU critical sections.

[1] - https://lore.kernel.org/all/[email protected]/

Fixes: 169fd62 ("ipv6: Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE.")
Signed-off-by: Andrea Mayer <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
The official Airoha EN7581 firmware requires adding max_packet filed in
ppe_mbox_data struct while the unofficial one used to develop the Airoha
EN7581 flowtable support does not require this field.
This patch does not introduce any real backwards compatible issue since
EN7581 fw is not publicly available in linux-firmware or other
repositories (e.g. OpenWrt) yet and the official fw version will use this
new layout. For this reason this change needs to be backported.
Moreover, add __packed attribute to ppe_mbox_data struct definition and
make the fw layout padding explicit in init_info struct.
At the same time use u32 instead of int for init_info and set_info
struct definitions in ppe_mbox_data struct.

Fixes: 23290c7 ("net: airoha: Introduce Airoha NPU support")
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Lorenzo Bianconi <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Commit 4bc1281 ("virtio-net: disable delayed refill when pausing rx")
fixed a deadlock between reconfig paths and refill work trying to disable
the same NAPI instance. The refill work can't run in parallel with reconfig
because trying to double-disable a NAPI instance causes a stall under the
instance lock, which the reconfig path needs to re-enable the NAPI and
therefore unblock the stalled thread.

There are two cases where we re-enable refill too early. One is in the
virtnet_set_queues() handler. We call it when installing XDP:

   virtnet_rx_pause_all(vi);
   ...
   virtnet_napi_tx_disable(..);
   ...
   virtnet_set_queues(..);
   ...
   virtnet_rx_resume_all(..);

We want the work to be disabled until we call virtnet_rx_resume_all(),
but virtnet_set_queues() kicks it before NAPIs were re-enabled.

The other case is a more trivial case of mis-ordering in
__virtnet_rx_resume() found by code inspection.

Fixes: 4bc1281 ("virtio-net: disable delayed refill when pausing rx")
Fixes: 413f027 ("net: protect NAPI enablement with netdev_lock()")
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
tc_actions.sh keeps hanging the forwarding tests.

sdf@: tdc & tdc-dbg started intermittenly failing around Sep 25th

Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.