From: Jakub Kicinski <kuba@kernel.org>
To: ernis@linux.microsoft.com
Cc: Jakub Kicinski <kuba@kernel.org>,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
kotaranov@microsoft.com, horms@kernel.org,
shradhagupta@linux.microsoft.com, dipayanroy@linux.microsoft.com,
shirazsaleem@microsoft.com, yury.norov@gmail.com,
kees@kernel.org, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next v8] net: mana: Expose hardware diagnostic info via debugfs
Date: Fri, 8 May 2026 15:01:14 -0700 [thread overview]
Message-ID: <20260508220114.3342627-1-kuba@kernel.org> (raw)
In-Reply-To: <20260506055128.291494-1-ernis@linux.microsoft.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: mana: Expose hardware diagnostic info via debugfs
Add debugfs entries to expose hardware configuration and diagnostic
information that aids in debugging driver initialization and runtime
operations without adding noise to dmesg.
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
[ ... ]
> @@ -2231,13 +2239,18 @@ int mana_gd_resume(struct pci_dev *pdev)
>
> err = mana_probe(&gc->mana, true);
> if (err)
> - return err;
> + goto cleanup_gd;
>
> err = mana_rdma_probe(&gc->mana_ib);
> if (err)
> - return err;
> + goto cleanup_mana;
>
> return 0;
> +cleanup_mana:
> + mana_remove(&gc->mana, true);
> +cleanup_gd:
> + mana_gd_cleanup_device(pdev);
> + return err;
> }
Since mana_remove() called with true for suspending skips
unregister_netdevice(), the network devices remain registered in the system.
If mana_gd_cleanup_device() is then called, which destroys the hardware
channel and clears gc->hwc.driver_data, could this lead to a NULL pointer
dereference if userspace later interacts with the still-registered devices?
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
[ ... ]
> @@ -3161,6 +3169,23 @@ static int mana_init_port(struct net_device *ndev)
> eth_hw_addr_set(ndev, apc->mac_addr);
> sprintf(vport, "vport%d", port_idx);
> apc->mana_port_debugfs = debugfs_create_dir(vport, gc->mana_pci_debugfs);
> +
> + debugfs_create_u64("port_handle", 0400, apc->mana_port_debugfs,
> + &apc->port_handle);
When the device suspends, mana_gd_suspend() calls mana_gd_cleanup_device(),
which recursively removes the entire debugfs directory tree.
During resume, the parent debugfs directory is recreated, but mana_probe()
skips calling mana_init_port() for existing ports.
Does this mean the per-vPort debugfs entries are permanently lost after a
suspend and resume cycle?
[ ... ]
> @@ -3800,6 +3830,9 @@ void mana_remove(struct gdma_dev *gd, bool suspending)
>
> mana_gd_deregister_device(gd);
>
> + debugfs_lookup_and_remove("bm_hostmode", gc->mana_pci_debugfs);
> + debugfs_lookup_and_remove("num_vports", gc->mana_pci_debugfs);
> +
> if (suspending)
> return;
Earlier in mana_remove(), free_netdev() is called, which frees the port
context structure (apc) allocated via netdev_priv(ndev).
Since the per-vPort debugfs files created in mana_init_port() directly
reference memory within apc, and apc->mana_port_debugfs is not explicitly
removed here, does this leave the debugfs files accessible but pointing to
freed memory until the parent directory is finally removed in
mana_gd_cleanup_device()?
prev parent reply other threads:[~2026-05-08 22:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 5:51 [PATCH net-next v8] net: mana: Expose hardware diagnostic info via debugfs Erni Sri Satya Vennela
2026-05-08 22:01 ` Jakub Kicinski [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=20260508220114.3342627-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=dipayanroy@linux.microsoft.com \
--cc=edumazet@google.com \
--cc=ernis@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=horms@kernel.org \
--cc=kees@kernel.org \
--cc=kotaranov@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shirazsaleem@microsoft.com \
--cc=shradhagupta@linux.microsoft.com \
--cc=wei.liu@kernel.org \
--cc=yury.norov@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