From: Nikolay Aleksandrov <razor@blackwall.org>
To: Ren Wei <n05ec@lzu.edu.cn>,
bridge@lists.linux.dev, netdev@vger.kernel.org
Cc: idosch@nvidia.com, horatiu.vultur@microchip.com, kuba@kernel.org,
henrik.bjoernlund@microchip.com, yuantan098@gmail.com,
yifanwucs@gmail.com, tomapufckgml@gmail.com, bird@lzu.edu.cn,
ronbogo@outlook.com, zylzyl2333@gmail.com
Subject: Re: [PATCH net 1/1] net: bridge: cfm: use a per-bridge frame type
Date: Sun, 10 May 2026 13:05:24 +0300 [thread overview]
Message-ID: <e1f1b080-cfde-4ea4-b444-b64d43778b2f@blackwall.org> (raw)
In-Reply-To: <7198fe2845c30c60c6b3833dd78cead8c5966931.1778378864.git.zylzyl2333@gmail.com>
On 10/05/2026 12:15, Ren Wei wrote:
> From: Yilin Zhu <zylzyl2333@gmail.com>
>
> CFM registers a bridge frame handler when the first MEP is created and
> unregisters it when the last MEP is deleted. The registered object also
> contains the hlist_node used by the bridge-local frame_type_list.
>
> The CFM frame type is currently global, so enabling CFM on multiple
> bridges links the same hlist_node into multiple bridge-local lists. A
> later unregister on one bridge can then operate on list state belonging
> to another bridge.
>
> Move the CFM frame type into struct net_bridge and register/unregister
> the bridge-owned object. This keeps frame handler list membership local
> to the bridge while preserving the existing first-MEP/last-MEP lifetime.
>
> Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Co-developed-by: Peihan Liu <ronbogo@outlook.com>
> Signed-off-by: Peihan Liu <ronbogo@outlook.com>
> Signed-off-by: Yilin Zhu <zylzyl2333@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/bridge/br_cfm.c | 14 ++++++--------
> net/bridge/br_private.h | 18 +++++++++++-------
> 2 files changed, 17 insertions(+), 15 deletions(-)
>
I think MRP suffers from the same bug, but I also think we can contain the
fix within the packet type structure instead of making the already huge
struct net_bridge even bigger. Also, linking a struct within net_bridge
to a list within the same net_bridge looks weird.
IMO br_add_frame should take a type & a frame_handler, allocate a br_frame_type
dynamically and link it, then br_del_frame should take a type instead of a ptr
and remove that frame type and free it with kfree_rcu. That would require
br_add_frame return value to be checked in the respective cfm/mrp functions.
Warnings for already existing types on add or missing types on del should be
added.
Would you please take care of MRP as well?
Cheers,
Nik
> diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
> index 118c7ea48c35..547c7415c0ea 100644
> --- a/net/bridge/br_cfm.c
> +++ b/net/bridge/br_cfm.c
> @@ -489,11 +489,6 @@ static int br_cfm_frame_rx(struct net_bridge_port *port, struct sk_buff *skb)
> return 1;
> }
>
> -static struct br_frame_type cfm_frame_type __read_mostly = {
> - .type = cpu_to_be16(ETH_P_CFM),
> - .frame_handler = br_cfm_frame_rx,
> -};
> -
> int br_cfm_mep_create(struct net_bridge *br,
> const u32 instance,
> struct br_cfm_mep_create *const create,
> @@ -558,8 +553,11 @@ int br_cfm_mep_create(struct net_bridge *br,
> INIT_HLIST_HEAD(&mep->peer_mep_list);
> INIT_DELAYED_WORK(&mep->ccm_tx_dwork, ccm_tx_work_expired);
>
> - if (hlist_empty(&br->mep_list))
> - br_add_frame(br, &cfm_frame_type);
> + if (hlist_empty(&br->mep_list)) {
> + br->cfm_frame_type.type = cpu_to_be16(ETH_P_CFM);
> + br->cfm_frame_type.frame_handler = br_cfm_frame_rx;
> + br_add_frame(br, &br->cfm_frame_type);
> + }
>
> hlist_add_tail_rcu(&mep->head, &br->mep_list);
>
> @@ -588,7 +586,7 @@ static void mep_delete_implementation(struct net_bridge *br,
> kfree_rcu(mep, rcu);
>
> if (hlist_empty(&br->mep_list))
> - br_del_frame(br, &cfm_frame_type);
> + br_del_frame(br, &br->cfm_frame_type);
> }
>
> int br_cfm_mep_delete(struct net_bridge *br,
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index bed1b1d9b282..a3ed9ee826f5 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -61,6 +61,9 @@ typedef struct bridge_id bridge_id;
> typedef struct mac_addr mac_addr;
> typedef __u16 port_id;
>
> +struct net_bridge_port;
> +struct sk_buff;
> +
> struct bridge_id {
> unsigned char prio[2];
> unsigned char addr[ETH_ALEN];
> @@ -70,6 +73,13 @@ struct mac_addr {
> unsigned char addr[ETH_ALEN];
> };
>
> +struct br_frame_type {
> + __be16 type;
> + int (*frame_handler)(struct net_bridge_port *port,
> + struct sk_buff *skb);
> + struct hlist_node list;
> +};
> +
> #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
> /* our own querier */
> struct bridge_mcast_own_query {
> @@ -585,6 +595,7 @@ struct net_bridge {
> struct hlist_head mrp_list;
> #endif
> #if IS_ENABLED(CONFIG_BRIDGE_CFM)
> + struct br_frame_type cfm_frame_type;
> struct hlist_head mep_list;
> #endif
> };
> @@ -926,13 +937,6 @@ int nbp_backup_change(struct net_bridge_port *p, struct net_device *backup_dev);
> int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb);
> rx_handler_func_t *br_get_rx_handler(const struct net_device *dev);
>
> -struct br_frame_type {
> - __be16 type;
> - int (*frame_handler)(struct net_bridge_port *port,
> - struct sk_buff *skb);
> - struct hlist_node list;
> -};
> -
> void br_add_frame(struct net_bridge *br, struct br_frame_type *ft);
> void br_del_frame(struct net_bridge *br, struct br_frame_type *ft);
>
next prev parent reply other threads:[~2026-05-10 10:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1778378864.git.zylzyl2333@gmail.com>
2026-05-10 9:15 ` [PATCH net 1/1] net: bridge: cfm: use a per-bridge frame type Ren Wei
2026-05-10 10:05 ` Nikolay Aleksandrov [this message]
2026-05-10 11:40 ` Nikolay Aleksandrov
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=e1f1b080-cfde-4ea4-b444-b64d43778b2f@blackwall.org \
--to=razor@blackwall.org \
--cc=bird@lzu.edu.cn \
--cc=bridge@lists.linux.dev \
--cc=henrik.bjoernlund@microchip.com \
--cc=horatiu.vultur@microchip.com \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=n05ec@lzu.edu.cn \
--cc=netdev@vger.kernel.org \
--cc=ronbogo@outlook.com \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.com \
--cc=zylzyl2333@gmail.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