All of lore.kernel.org
 help / color / mirror / Atom feed
From: idosch at idosch.org (Ido Schimmel)
Subject: [PATCH net-next 01/18] net: skb_scrub_packet(): Scrub offload_fwd_mark
Date: Mon, 19 Nov 2018 22:06:25 +0200	[thread overview]
Message-ID: <20181119200625.GA24261@splinter> (raw)
In-Reply-To: <20181119.110745.12820215456503449.davem@davemloft.net>

On Mon, Nov 19, 2018 at 11:07:45AM -0800, David Miller wrote:
> From: Ido Schimmel <idosch at mellanox.com>
> Date: Mon, 19 Nov 2018 16:11:07 +0000
> 
> > From: Petr Machata <petrm at mellanox.com>
> > 
> > When a packet is trapped and the corresponding SKB marked as
> > already-forwarded, it retains this marking even after it is forwarded
> > across veth links into another bridge. There, since it ingresses the
> > bridge over veth, which doesn't have offload_fwd_mark, it triggers a
> > warning in nbp_switchdev_frame_mark().
> > 
> > Then nbp_switchdev_allowed_egress() decides not to allow egress from
> > this bridge through another veth, because the SKB is already marked, and
> > the mark (of 0) of course matches. Thus the packet is incorrectly
> > blocked.
> > 
> > Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
> > function is called from tunnels and also from veth, and thus catches the
> > cases where traffic is forwarded between bridges and transformed in a
> > way that invalidates the marking.
> > 
> > Signed-off-by: Petr Machata <petrm at mellanox.com>
> > Suggested-by: Ido Schimmel <idosch at mellanox.com>
> > Signed-off-by: Ido Schimmel <idosch at mellanox.com>
> 
> As a bug fix this seems relevant for 'net' instead of 'net-next'.

This seemed really obscure/specific to this selftest so I deemed it
unnecessary for 'net'.

Agree that by the book it is 'net' material, so we'll send it there.

Thanks for the feedback

WARNING: multiple messages have this Message-ID (diff)
From: idosch@idosch.org (Ido Schimmel)
Subject: [PATCH net-next 01/18] net: skb_scrub_packet(): Scrub offload_fwd_mark
Date: Mon, 19 Nov 2018 22:06:25 +0200	[thread overview]
Message-ID: <20181119200625.GA24261@splinter> (raw)
Message-ID: <20181119200625.WYoP3CWTIZLXii9-7-UF_qBP9NpAmQveb1yPp40VxB8@z> (raw)
In-Reply-To: <20181119.110745.12820215456503449.davem@davemloft.net>

On Mon, Nov 19, 2018@11:07:45AM -0800, David Miller wrote:
> From: Ido Schimmel <idosch at mellanox.com>
> Date: Mon, 19 Nov 2018 16:11:07 +0000
> 
> > From: Petr Machata <petrm at mellanox.com>
> > 
> > When a packet is trapped and the corresponding SKB marked as
> > already-forwarded, it retains this marking even after it is forwarded
> > across veth links into another bridge. There, since it ingresses the
> > bridge over veth, which doesn't have offload_fwd_mark, it triggers a
> > warning in nbp_switchdev_frame_mark().
> > 
> > Then nbp_switchdev_allowed_egress() decides not to allow egress from
> > this bridge through another veth, because the SKB is already marked, and
> > the mark (of 0) of course matches. Thus the packet is incorrectly
> > blocked.
> > 
> > Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
> > function is called from tunnels and also from veth, and thus catches the
> > cases where traffic is forwarded between bridges and transformed in a
> > way that invalidates the marking.
> > 
> > Signed-off-by: Petr Machata <petrm at mellanox.com>
> > Suggested-by: Ido Schimmel <idosch at mellanox.com>
> > Signed-off-by: Ido Schimmel <idosch at mellanox.com>
> 
> As a bug fix this seems relevant for 'net' instead of 'net-next'.

This seemed really obscure/specific to this selftest so I deemed it
unnecessary for 'net'.

Agree that by the book it is 'net' material, so we'll send it there.

Thanks for the feedback

WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@idosch.org>
To: David Miller <davem@davemloft.net>
Cc: idosch@mellanox.com, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org, shuah@kernel.org,
	jiri@mellanox.com, petrm@mellanox.com, roopa@cumulusnetworks.com,
	mlxsw@mellanox.com
Subject: Re: [PATCH net-next 01/18] net: skb_scrub_packet(): Scrub offload_fwd_mark
Date: Mon, 19 Nov 2018 22:06:25 +0200	[thread overview]
Message-ID: <20181119200625.GA24261@splinter> (raw)
In-Reply-To: <20181119.110745.12820215456503449.davem@davemloft.net>

On Mon, Nov 19, 2018 at 11:07:45AM -0800, David Miller wrote:
> From: Ido Schimmel <idosch@mellanox.com>
> Date: Mon, 19 Nov 2018 16:11:07 +0000
> 
> > From: Petr Machata <petrm@mellanox.com>
> > 
> > When a packet is trapped and the corresponding SKB marked as
> > already-forwarded, it retains this marking even after it is forwarded
> > across veth links into another bridge. There, since it ingresses the
> > bridge over veth, which doesn't have offload_fwd_mark, it triggers a
> > warning in nbp_switchdev_frame_mark().
> > 
> > Then nbp_switchdev_allowed_egress() decides not to allow egress from
> > this bridge through another veth, because the SKB is already marked, and
> > the mark (of 0) of course matches. Thus the packet is incorrectly
> > blocked.
> > 
> > Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That
> > function is called from tunnels and also from veth, and thus catches the
> > cases where traffic is forwarded between bridges and transformed in a
> > way that invalidates the marking.
> > 
> > Signed-off-by: Petr Machata <petrm@mellanox.com>
> > Suggested-by: Ido Schimmel <idosch@mellanox.com>
> > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> 
> As a bug fix this seems relevant for 'net' instead of 'net-next'.

This seemed really obscure/specific to this selftest so I deemed it
unnecessary for 'net'.

Agree that by the book it is 'net' material, so we'll send it there.

Thanks for the feedback

  reply	other threads:[~2018-11-19 20:06 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19 16:11 [PATCH net-next 00/18] selftests: Add tests for VXLAN at an 802.1d bridge idosch
2018-11-19 16:11 ` Ido Schimmel
2018-11-19 16:11 ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 01/18] net: skb_scrub_packet(): Scrub offload_fwd_mark idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 19:07   ` davem
2018-11-19 19:07     ` David Miller
2018-11-19 19:07     ` David Miller
2018-11-19 20:06     ` idosch [this message]
2018-11-19 20:06       ` Ido Schimmel
2018-11-19 20:06       ` Ido Schimmel
2018-11-19 22:41     ` petrm
2018-11-19 22:41       ` Petr Machata
2018-11-19 22:41       ` Petr Machata
2018-11-19 16:11 ` [PATCH net-next 02/18] selftests: forwarding: lib: Support NUM_NETIFS of 0 idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 03/18] selftests: forwarding: lib: Add in_ns() idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 04/18] selftests: forwarding: ping{6,}_test(): Add description argument idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 05/18] selftests: forwarding: ping{6,}_do(): Allow passing ping arguments idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 06/18] selftests: forwarding: lib: Add link_stats_rx_errors_get() idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 07/18] selftests: forwarding: Add a skeleton of vxlan_bridge_1d idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 08/18] selftests: forwarding: vxlan_bridge_1d: Add ping test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 09/18] selftests: forwarding: vxlan_bridge_1d: Add flood test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 10/18] selftests: forwarding: vxlan_bridge_1d: Add unicast test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 11/18] selftests: forwarding: vxlan_bridge_1d: Reconfigure & rerun tests idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 12/18] selftests: forwarding: vxlan_bridge_1d: Add a TTL test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 13/18] selftests: forwarding: vxlan_bridge_1d: Add a TOS test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 14/18] selftests: forwarding: vxlan_bridge_1d: Add an ECN encap test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 15/18] selftests: forwarding: vxlan_bridge_1d: Add an ECN decap test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 16/18] selftests: forwarding: vxlan_bridge_1d_port_8472: New test idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11 ` [PATCH net-next 17/18] selftests: mlxsw: Add a test for VxLAN configuration idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:21   ` petrm
2018-11-19 16:21     ` Petr Machata
2018-11-19 16:21     ` Petr Machata
2018-11-19 16:11 ` [PATCH net-next 18/18] selftests: mlxsw: Add a test for VxLAN flooding idosch
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:11   ` Ido Schimmel
2018-11-19 16:25   ` petrm
2018-11-19 16:25     ` Petr Machata
2018-11-19 16:25     ` Petr Machata
2018-11-20  2:00 ` [PATCH net-next 00/18] selftests: Add tests for VXLAN at an 802.1d bridge davem
2018-11-20  2:00   ` David Miller
2018-11-20  2:00   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181119200625.GA24261@splinter \
    --to=unknown@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.