From: Xin Xie <xiexinet@gmail.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
fmaurer@redhat.com, luka.gejak@linux.dev,
kexinsun@smail.nju.edu.cn, arvid.brodin@alten.se,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: hsr: free learned nodes on device setup failure
Date: Tue, 11 Aug 2026 15:56:08 +0200 [thread overview]
Message-ID: <063eb98e-95d2-4d95-9720-08b351fb6e6e@gmail.com> (raw)
In-Reply-To: <ankqCHe8D9y09aN3@fedora>
On 10/08/2026 03:31, Hangbin Liu wrote:
> Should we use this fix tag? The proxy_node_db is added in
> 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)").
>
> Thanks
> Hangbin
Thanks for checking. I believe 81ba6afd6e64 is the right tag.
The demonstrated leak is node_db, and the window that creates it was
born in 81ba6afd6e64: that commit moved per-device RX handler
registration into hsr_dev_finalize(), ahead of steps that could still
fail (the second handler registration, self-node allocation,
register_netdevice()), while the failure unwind never released nodes
learned through the already-live handler. Before it, reception used
the module-global dev_add_pack() handler, which could not reach an
instance until register_hsr_master() at the successful end of
finalize, so there was nothing to leak.
proxy_node_db cannot hold entries on any current finalize error
exit: it is fed only by interlink-port RX, and the interlink add is
the last failable step in finalize. On this path, the second
hsr_del_nodes() call is a harmless no-op on an empty list, keeping
the unwind symmetric with hsr_dellink().
Using 5055cccfc2d1 would instead keep the fix away from older stable
trees, where the node_db leak does exist.
--
Xin
prev parent reply other threads:[~2026-08-11 13:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 11:08 [PATCH net] net: hsr: free learned nodes on device setup failure Xin Xie
2026-08-10 1:31 ` Hangbin Liu
2026-08-11 13:56 ` Xin Xie [this message]
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=063eb98e-95d2-4d95-9720-08b351fb6e6e@gmail.com \
--to=xiexinet@gmail.com \
--cc=arvid.brodin@alten.se \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fmaurer@redhat.com \
--cc=horms@kernel.org \
--cc=kexinsun@smail.nju.edu.cn \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=luka.gejak@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.