linux/drivers/net/netdevsim, branch v5.11

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-12-12T06:29:38Z

xdp_return_frame_bulk() needs to pass a xdp_buff to __xdp_return(). strlcpy got converted to strscpy but here it makes no functional difference, so just keep the right code. Conflicts: net/netfilter/nf_tables_api.c Signed-off-by: Jakub Kicinski

netdevsim: Add debugfs toggle to reject BPF programs in verifier

2020-12-09T15:27:42Z

This adds a new debugfs toggle ('bpf_bind_verifier_accept') that can be used to make netdevsim reject BPF programs from being accepted by the verifier. If this toggle (which defaults to true) is set to false, nsim_bpf_verify_insn() will return EOPNOTSUPP on the last instruction (after outputting the 'Hello from netdevsim' verifier message). This makes it possible to check the verification callback in the driver from test_offload.py in selftests, since the verifier now clears the verifier log on a successful load, hiding the message from the driver. Fixes: 6f8a57ccf851 ("bpf: Make verifier log more relevant by default") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/160752225964.110217.12584017165318065332.stgit@toke.dk

xdp: Remove the xdp_attachment_flags_ok() callback

2020-12-09T15:27:42Z

Since commit 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device"), the XDP program attachment info is now maintained in the core code. This interacts badly with the xdp_attachment_flags_ok() check that prevents unloading an XDP program with different load flags than it was loaded with. In practice, two kinds of failures are seen: - An XDP program loaded without specifying a mode (and which then ends up in driver mode) cannot be unloaded if the program mode is specified on unload. - The dev_xdp_uninstall() hook always calls the driver callback with the mode set to the type of the program but an empty flags argument, which means the flags_ok() check prevents the program from being removed, leading to bpf prog reference leaks. The original reason this check was added was to avoid ambiguity when multiple programs were loaded. With the way the checks are done in the core now, this is quite simple to enforce in the core code, so let's add a check there and get rid of the xdp_attachment_flags_ok() callback entirely. Fixes: 7f0a838254bd ("bpf, xdp: Maintain info on attached XDP BPF programs in net_device") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/160752225751.110217.10267659521308669050.stgit@toke.dk

netdevsim: support ethtool ring and coalesce settings

2020-11-20T20:51:54Z

Add ethtool ring and coalesce settings support for testing. Signed-off-by: Antonio Cardace Reviewed-by: Michal Kubecek Signed-off-by: Jakub Kicinski

netdevsim: move ethtool pause params in separate struct

2020-11-20T20:51:54Z

This will help the refactoring in the next commit when coalesce and ring settings are added. Signed-off-by: Antonio Cardace Reviewed-by: Michal Kubecek Signed-off-by: Jakub Kicinski

devlink: move flash end and begin to core devlink

2020-11-20T05:41:02Z

When performing a flash update via devlink, device drivers may inform user space of status updates via devlink_flash_update_(begin|end|timeout|status)_notify functions. It is expected that drivers do not send any status notifications unless they send a begin and end message. If a driver sends a status notification without sending the appropriate end notification upon finishing (regardless of success or failure), the current implementation of the devlink userspace program can get stuck endlessly waiting for the end notification that will never come. The current ice driver implementation may send such a status message without the appropriate end notification in rare cases. Fixing the ice driver is relatively simple: we just need to send the begin_notify at the start of the function and always send an end_notify no matter how the function exits. Rather than assuming driver authors will always get this right in the future, lets just fix the API so that it is not possible to get wrong. Make devlink_flash_update_begin_notify and devlink_flash_update_end_notify static, and call them in devlink.c core code. Always send the begin_notify just before calling the driver's flash_update routine. Always send the end_notify just after the routine returns regardless of success or failure. Doing this makes the status notification easier to use from the driver, as it no longer needs to worry about catching failures and cleaning up by calling devlink_flash_update_end_notify. It is now no longer possible to do the wrong thing in this regard. We also save a couple of lines of code in each driver. Signed-off-by: Jacob Keller Acked-by: Vasundhara Volam Reviewed-by: Jiri Pirko Signed-off-by: Jakub Kicinski

Merge https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-11-20T03:08:46Z

Signed-off-by: Jakub Kicinski

netdevsim: set .owner to THIS_MODULE

2020-11-17T22:08:59Z

If THIS_MODULE is not set, the module would be removed while debugfs is being used. It eventually makes kernel panic. Fixes: 82c93a87bf8b ("netdevsim: implement couple of testing devlink health reporters") Fixes: 424be63ad831 ("netdevsim: add UDP tunnel port offload support") Fixes: 4418f862d675 ("netdevsim: implement support for devlink region and snapshots") Fixes: d3cbb907ae57 ("netdevsim: add ACL trap reporting cookie as a metadata") Signed-off-by: Taehee Yoo Link: https://lore.kernel.org/r/20201115103041.30701-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski

netdevsim: Allow programming routes with nexthop objects

2020-11-06T19:28:50Z

Previous patches added the ability to program nexthop objects. Therefore, no longer forbid the programming of routes that point to such objects. Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski

netdevsim: Add dummy implementation for nexthop offload

2020-11-06T19:28:50Z

Implement dummy nexthop "offload" in the driver by storing currently "programmed" nexthops in a hash table. Each nexthop in the hash table is marked with "trap" indication and increments the nexthops resource occupancy. This will later allow us to test the nexthop offload API on top of netdevsim. Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski