From: Simon Horman <horms@kernel.org>
To: Jiawen Wu <jiawenwu@trustnetic.com>
Cc: netdev@vger.kernel.org,
"Mengyuan Lou" <mengyuanlou@net-swift.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Russell King" <linux@armlinux.org.uk>,
"Jacob Keller" <jacob.e.keller@intel.com>,
"Michal Swiatkowski" <michal.swiatkowski@linux.intel.com>,
"Kees Cook" <kees@kernel.org>,
"Larysa Zaremba" <larysa.zaremba@intel.com>,
"Joe Damato" <joe@dama.to>, "Breno Leitao" <leitao@debian.org>,
"Aleksandr Loktionov" <aleksandr.loktionov@intel.com>,
"Uwe Kleine-König (The Capable Hub)"
<u.kleine-koenig@baylibre.com>,
"Fabio Baltieri" <fabio.baltieri@gmail.com>,
"Thomas Gleixner" <tglx@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH net-next v6 4/5] net: wangxun: implement soft quiesce for PCIe error recovery
Date: Fri, 12 Jun 2026 16:49:29 +0100 [thread overview]
Message-ID: <20260612154929.GD671640@horms.kernel.org> (raw)
In-Reply-To: <20260610060917.23980-5-jiawenwu@trustnetic.com>
On Wed, Jun 10, 2026 at 02:09:16PM +0800, Jiawen Wu wrote:
> Function wx_soft_quiesce() provide a lightweight shutdown path during
> PCIe error recovery. It avoids MMIO-dependent operations in PCIe error
> status.
>
> Waiting for the service task to complete may unnecessarily delay PCIe
> error recovery, especially if the work item is already blocked by the
> hardware failure that triggered AER. So the service task is not
> explicitly cancelled in quiesce path. As a measure to block the service
> task, the checking of WX_STATE_DOWN and WX_STATE_RESETTING is added at
> the entry of every work item.
>
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
...
> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_ptp.c b/drivers/net/ethernet/wangxun/libwx/wx_ptp.c
> index 44f3e6505246..dcc8b3ae1445 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_ptp.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_ptp.c
> @@ -842,6 +842,27 @@ void wx_ptp_stop(struct wx *wx)
> }
> EXPORT_SYMBOL(wx_ptp_stop);
>
> +void wx_ptp_quiesce(struct wx *wx)
> +{
> + if (!test_and_clear_bit(WX_STATE_PTP_RUNNING, wx->state))
> + return;
> +
> + clear_bit(WX_FLAG_PTP_PPS_ENABLED, wx->flags);
> +
> + if (wx->ptp_tx_skb) {
> + dev_kfree_skb_any(wx->ptp_tx_skb);
> + wx->ptp_tx_skb = NULL;
> + }
AI-generated review of this patch on sashiko.dev flags a potential UAF here:
"Could freeing wx->ptp_tx_skb here cause a use-after-free or
double-free?
"Because ptp_clock_unregister() is called after this block, the PTP
kworker might still be running.
"If wx_ptp_tx_hwtstamp() reads wx->ptp_tx_skb just before this
free, it will pass the freed skb to skb_tstamp_tx() and call
dev_kfree_skb_any() on it again.
I'd appreciate it if you could look into that.
I believe that the other issues raised in that AI-generated review have
already been discussed in the context of earlier versions of this
patch-set.
> + clear_bit_unlock(WX_STATE_PTP_TX_IN_PROGRESS, wx->state);
> +
> + if (wx->ptp_clock) {
> + ptp_clock_unregister(wx->ptp_clock);
> + wx->ptp_clock = NULL;
> + dev_info(&wx->pdev->dev, "removed PHC on %s\n", wx->netdev->name);
> + }
> +}
...
next prev parent reply other threads:[~2026-06-12 15:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 6:09 [PATCH net-next v6 0/5] net: wangxun: timeout and error Jiawen Wu
2026-06-10 6:09 ` [PATCH net-next v6 1/5] net: ngbe: implement libwx reset ops Jiawen Wu
2026-06-10 6:09 ` [PATCH net-next v6 2/5] net: wangxun: add Tx timeout process Jiawen Wu
2026-06-10 6:09 ` [PATCH net-next v6 3/5] net: wangxun: add reinit parameter to wx->do_reset callback Jiawen Wu
2026-06-10 6:09 ` [PATCH net-next v6 4/5] net: wangxun: implement soft quiesce for PCIe error recovery Jiawen Wu
2026-06-12 15:49 ` Simon Horman [this message]
2026-06-10 6:09 ` [PATCH net-next v6 5/5] net: wangxun: add pcie error handler Jiawen Wu
2026-06-12 15:41 ` Simon Horman
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=20260612154929.GD671640@horms.kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fabio.baltieri@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jacob.e.keller@intel.com \
--cc=jiawenwu@trustnetic.com \
--cc=joe@dama.to \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=larysa.zaremba@intel.com \
--cc=leitao@debian.org \
--cc=linux@armlinux.org.uk \
--cc=mengyuanlou@net-swift.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=tglx@kernel.org \
--cc=u.kleine-koenig@baylibre.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.