From: Simon Horman <horms@kernel.org>
To: Lin Ma <linma@zju.edu.cn>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, mingo@kernel.org, tglx@linutronix.de,
pwn9uin@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v3] net: atm: Fix incorrect net_device lec check
Date: Mon, 7 Jul 2025 17:30:56 +0100 [thread overview]
Message-ID: <20250707163056.GO89747@horms.kernel.org> (raw)
In-Reply-To: <5c66d883.a83f.197d88a76c4.Coremail.linma@zju.edu.cn>
On Sat, Jul 05, 2025 at 11:04:02AM +0800, Lin Ma wrote:
> Hi Simon,
>
> > Can start_mpc() run on dev before this function is called?
> > If so, does the check above still work as expected?
>
> Great point. I found two locatinos that call start_mpc(). One
> is atm_mpoa_mpoad_attach() and the other is mpoa_event_listener().
>
> Since this patch covers these two functions, I believe start_mpc()
> run after the check.
>
> However, since start_mpc() indeed replaces the netdev_ops. It seems
> quite error-prone to perform type checking using that field. Moreover,
> this patch raises a linking error as shown in
> https://lore.kernel.org/oe-kbuild-all/202507050831.2GTrUnFN-lkp@intel.com/.
> Hence, I will prepare version 4 and try to think about other solutions.
Thanks. I was thinking along the same lines.
>
> >
> > 1) Is this code path reachable by non-lec devices?
> >
>
> Yes, though the mpoa_event_listener() is registered for the net/mpc module,
> the notifier_block calls every registered listener.
>
> /** ....
> * Calls each function in a notifier chain in turn. The functions
> * run in an undefined context.
> * All locking must be provided by the caller.
> * ...
> */
> int raw_notifier_call_chain(struct raw_notifier_head *nh,
> unsigned long val, void *v)
>
> In another word, every registered listener is reachable and is responsible
> for determining whether the event is relevant to them. And that is why we
> should add a type check here.
Understood, makes sense.
>
> > 2) Can the name of a lec device be changed?
> If so, does it cause a problem here?
>
> To my knowledge, the changing of a net_device name is handled in
> net/core/dev.c, which is a general functionality that an individual driver
> cannot intervene.
>
> int __dev_change_net_namespace(struct net_device *dev, struct net *net,
> const char *pat, int new_ifindex)
> {
> ...
> if (new_name[0]) /* Rename the netdev to prepared name */
> strscpy(dev->name, new_name, IFNAMSIZ);
> ...
> }
>
> Nice catch.
> If a user changes a lec device name to something else that is not
> prefixed with "lec", it causes functionality issues, as events
> like NETDEV_UP/DOWN cannot reach the inner logic.
>
> That will be another reason to adopt a fix.
Yes, that seems likely.
But perhaps such a fix is orthogonal from the one that started this thread.
next prev parent reply other threads:[~2025-07-07 16:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 5:24 Lin Ma
2025-07-04 19:01 ` Simon Horman
2025-07-05 3:04 ` Lin Ma
2025-07-07 16:30 ` Simon Horman [this message]
2025-07-05 1:19 ` kernel test robot
2025-07-05 2:13 ` Lin Ma
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=20250707163056.GO89747@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linma@zju.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pwn9uin@gmail.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®