similar to: [Bridge] [PATCH net-next v2] netlink: provide an ability to set default extack message

From: Leon Romanovsky <leonro at nvidia.com> In netdev common pattern, xxtack pointer is forwarded to the drivers to be filled with error message. However, the caller can easily overwrite the filled message. Instead of adding multiple "if (!extack->_msg)" checks before any NL_SET_ERR_MSG() call, which appears after call to the driver, let's add this check to common code.

On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote: > From: Leon Romanovsky <leonro at nvidia.com> > > In netdev common pattern, xxtack pointer is forwarded to the drivers ~~~~~~ extack > to be filled with error message. However, the caller can easily > overwrite the filled message. > > Instead of

On Fri, 27 Jan 2023 00:32:13 +0200 Vladimir Oltean wrote: > On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro at nvidia.com> > > > > In netdev common pattern, xxtack pointer is forwarded to the drivers > ~~~~~~ > extack > > > to be filled with error

Hello, On Sun, 2023-01-29 at 18:51 +0200, Leon Romanovsky wrote: > In netdev common pattern, extack pointer is forwarded to the drivers > to be filled with error message. However, the caller can easily > overwrite the filled message. > > Instead of adding multiple "if (!extack->_msg)" checks before any > NL_SET_ERR_MSG() call, which appears after call to the

On Fri, Jan 27, 2023 at 12:32:13AM +0200, Vladimir Oltean wrote: > On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro at nvidia.com> > > > > In netdev common pattern, xxtack pointer is forwarded to the drivers > ~~~~~~ > extack > > > to be filled with

On Fri, 27 Jan 2023 07:26:13 +0200 Leon Romanovsky wrote: > > That'd be my preference too, FWIW. It's only the offload cases which > > need this sort of fallback. > > Of course not, almost any error unwind path which sets extack will need it. I guess we can come up with scenarios where the new behavior would be useful. But the fact is - your patch changes 4 places...

To be able to add dynamic FDB entries to drivers from userspace, the dynamic flag must be added when sending RTM_NEWNEIGH events down. Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> --- include/net/switchdev.h | 1 + net/bridge/br_switchdev.c | 1 + 2 files changed, 2 insertions(+) diff --git a/include/net/switchdev.h b/include/net/switchdev.h index

On Tue, Jan 17, 2023 at 07:57:10PM +0100, Hans J. Schultz wrote: > To be able to add dynamic FDB entries to drivers from userspace, the > dynamic flag must be added when sending RTM_NEWNEIGH events down. > > Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> > --- > include/net/switchdev.h | 1 + > net/bridge/br_switchdev.c | 1 + > 2 files changed, 2

On 2023-01-18 00:08, Vladimir Oltean wrote: > On Tue, Jan 17, 2023 at 07:57:10PM +0100, Hans J. Schultz wrote: >> To be able to add dynamic FDB entries to drivers from userspace, the >> dynamic flag must be added when sending RTM_NEWNEIGH events down. >> >> Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> >> --- >>

There is a structural problem in switchdev, where the flag bits in struct switchdev_notifier_fdb_info (added_by_user, is_local etc) only represent a simplified / denatured view of what's in struct net_bridge_fdb_entry :: flags (BR_FDB_ADDED_BY_USER, BR_FDB_LOCAL etc). Each time we want to pass more information about struct net_bridge_fdb_entry :: flags to struct switchdev_notifier_fdb_info

On Mon, Apr 10, 2023 at 11:49:51PM +0300, Vladimir Oltean wrote: > There is a structural problem in switchdev, where the flag bits in > struct switchdev_notifier_fdb_info (added_by_user, is_local etc) only > represent a simplified / denatured view of what's in struct > net_bridge_fdb_entry :: flags (BR_FDB_ADDED_BY_USER, BR_FDB_LOCAL etc). > Each time we want to pass more

Add MDB net device operations that will be invoked by rtnetlink code in response to received RTM_{NEW,DEL,GET}MDB messages. Subsequent patches will implement these operations in the bridge and VXLAN drivers. Signed-off-by: Ido Schimmel <idosch at nvidia.com> --- include/linux/netdevice.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/include/linux/netdevice.h

Adjust drivers that support the 'FLOW_DISSECTOR_KEY_META' key to reject filters that try to match on the newly added layer 2 miss option. Add an extack message to clearly communicate the failure reason to user space. Example: # tc filter add dev swp1 egress pref 1 proto all flower skip_sw l2_miss true action drop Error: mlxsw_spectrum: Can't match on "l2_miss". We have

On 12/07/2023 17:48, Ido Schimmel wrote: > On Tue, Jul 11, 2023 at 04:54:15PM -0700, Kuniyuki Iwashima wrote: >> When we create an L2 loop on a bridge in netns, we will see packets storm >> even if STP is enabled. >> >> # unshare -n >> # ip link add br0 type bridge >> # ip link add veth0 type veth peer name veth1 >> # ip link set veth0 master

From: Leon Romanovsky <leonro at nvidia.com> Changelog: v1: * Renamed _mlx5_rescan_driver to be mlx5_rescan_driver_locked like in other parts of the mlx5 driver. * Renamed MLX5_INTERFACE_PROTOCOL_VDPA to tbe MLX5_INTERFACE_PROTOCOL_VNET as a preparation to coming series from Eli C. * Some small naming renames in mlx5_vdpa. * Refactored adev index code to make Parav's SF series

In below example, before the fix, mtu attribute is supported by the parent mgmtdev, but the error message showing "All provided are not supported" is just misleading. $ vdpa mgmtdev show vdpasim_net: supported_classes net max_supported_vqs 3 dev_features MTU MAC CTRL_VQ CTRL_MAC_ADDR ANY_LAYOUT VERSION_1 ACCESS_PLATFORM $ vdpa dev add mgmtdev vdpasim_net name vdpasim0 mtu 5000

When we create an L2 loop on a bridge in netns, we will see packets storm even if STP is enabled. # unshare -n # ip link add br0 type bridge # ip link add veth0 type veth peer name veth1 # ip link set veth0 master br0 up # ip link set veth1 master br0 up # ip link set br0 type bridge stp_state 1 # ip link set br0 up # sleep 30 # ip -s link show br0 2: br0:

We don't support partial csumed packet since its metadata will be lost or incorrect during XDP processing. So fail the XDP set if guest_csum feature is negotiated. Fixes: f600b6905015 ("virtio_net: Add XDP support") Reported-by: Jesper Dangaard Brouer <brouer at redhat.com> Cc: Jesper Dangaard Brouer <brouer at redhat.com> Cc: Pavel Popa <pashinho1990 at gmail.com>

On 12/07/2023 02:54, Kuniyuki Iwashima wrote: > When we create an L2 loop on a bridge in netns, we will see packets storm > even if STP is enabled. > > # unshare -n > # ip link add br0 type bridge > # ip link add veth0 type veth peer name veth1 > # ip link set veth0 master br0 up > # ip link set veth1 master br0 up > # ip link set br0 type bridge stp_state 1

Thanks: Vladik Romanovsky, Ming Xie. --- v2v/output_glance.ml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/v2v/output_glance.ml b/v2v/output_glance.ml index e38b172..179448b 100644 --- a/v2v/output_glance.ml +++ b/v2v/output_glance.ml @@ -92,6 +92,10 @@ object | Virtio_net -> "virtio" | E1000 -> "e1000" | RTL8139 ->