From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>,
"henrik.bjoernlund@microchip.com"
<henrik.bjoernlund@microchip.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jiri@mellanox.com" <jiri@mellanox.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Roopa Prabhu <roopa@nvidia.com>,
"idosch@mellanox.com" <idosch@mellanox.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Cc: "horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Subject: Re: [net-next v2 01/11] net: bridge: extend the process of special frames
Date: Tue, 6 Oct 2020 14:13:15 +0000 [thread overview]
Message-ID: <9149db9d070102e20208d962aeb9101fd5fe2c4c.camel@nvidia.com> (raw)
In-Reply-To: <20201001103019.1342470-2-henrik.bjoernlund@microchip.com>
On Thu, 2020-10-01 at 10:30 +0000, Henrik Bjoernlund wrote:
> This patch extends the processing of frames in the bridge. Currently MRP
> frames needs special processing and the current implementation doesn't
> allow a nice way to process different frame types. Therefore try to
> improve this by adding a list that contains frame types that need
> special processing. This list is iterated for each input frame and if
> there is a match based on frame type then these functions will be called
> and decide what to do with the frame. It can process the frame then the
> bridge doesn't need to do anything or don't process so then the bridge
> will do normal forwarding.
>
> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
> Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com>
> ---
> net/bridge/br_device.c | 1 +
> net/bridge/br_input.c | 31 ++++++++++++++++++++++++++++++-
> net/bridge/br_mrp.c | 19 +++++++++++++++----
> net/bridge/br_private.h | 18 ++++++++++++------
> 4 files changed, 58 insertions(+), 11 deletions(-)
>
Hi,
Mostly looks good, one comment below.
> diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> index 9a2fb4aa1a10..206c4ba51cd2 100644
> --- a/net/bridge/br_device.c
> +++ b/net/bridge/br_device.c
> [snip]
> @@ -380,3 +395,17 @@ rx_handler_func_t *br_get_rx_handler(const struct net_device *dev)
>
> return br_handle_frame;
> }
> +
> +void br_add_frame(struct net_bridge *br, struct br_frame_type *ft)
> +{
> + hlist_add_head_rcu(&ft->list, &br->frame_type_list);
> +}
> +
> +void br_del_frame(struct net_bridge *br, struct br_frame_type *ft)
> +{
> + struct br_frame_type *tmp;
> +
> + hlist_for_each_entry(tmp, &br->frame_type_list, list)
> + if (ft == tmp)
> + hlist_del_rcu(&ft->list);
This hasn't crashed only because you're using hlist_del_rcu(), otherwise it's
wrong. You should use hlist_for_each_entry_safe() when deleting from the list
while walking it or you should end the walk after the delete since there can't
be two elements with the same address anyway.
Thanks,
Nik
next prev parent reply other threads:[~2020-10-06 14:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 10:30 [net-next v2 00/11] net: bridge: cfm: Add support for Connectivity Fault Management(CFM) Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 01/11] net: bridge: extend the process of special frames Henrik Bjoernlund
2020-10-01 16:31 ` kernel test robot
2020-10-01 18:02 ` kernel test robot
2020-10-01 18:36 ` kernel test robot
2020-10-06 14:13 ` Nikolay Aleksandrov [this message]
2020-10-01 10:30 ` [net-next v2 02/11] bridge: cfm: Add BRIDGE_CFM to Kconfig Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 03/11] bridge: uapi: cfm: Added EtherType used by the CFM protocol Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 04/11] bridge: cfm: Kernel space implementation of CFM Henrik Bjoernlund
2020-10-06 14:29 ` Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 05/11] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 06/11] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 07/11] bridge: cfm: Netlink Interface Henrik Bjoernlund
2020-10-06 14:44 ` Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 08/11] bridge: cfm: Netlink Notifications Henrik Bjoernlund
2020-10-06 14:49 ` Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 09/11] bridge: cfm: Bridge port remove Henrik Bjoernlund
2020-10-06 14:53 ` Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface implementation Henrik Bjoernlund
2020-10-01 12:49 ` Jiri Pirko
2020-10-05 13:07 ` Allan W. Nielsen
2020-10-06 9:02 ` Jiri Pirko
2020-10-06 10:50 ` Nikolay Aleksandrov
2020-10-06 10:53 ` allan.nielsen
2020-10-01 15:20 ` kernel test robot
2020-10-01 15:38 ` kernel test robot
2020-10-01 10:30 ` [net-next v2 11/11] bridge: cfm: Added CFM switchdev utilization Henrik Bjoernlund
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=9149db9d070102e20208d962aeb9101fd5fe2c4c.camel@nvidia.com \
--to=nikolay@nvidia.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=henrik.bjoernlund@microchip.com \
--cc=horatiu.vultur@microchip.com \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=roopa@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox