All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Avi Weiss" <thnkslprpt@gmail.com>
Cc: ntb@lists.linux.dev
Subject: Re: [PATCH v2 2/2] NTB: epf: propagate MW command errors while status is reliable
Date: Sun, 01 Nov 2026 14:12:46 +0000	[thread overview]
Message-ID: <sashiko-outbox-192437@kernel.org> (raw)
In-Reply-To: <62334fd3b8d69fdfdeed268d71f473df45f34556.1793540847.git.thnkslprpt@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] NTB: epf: ntb_epf_send_command_locked() masks MW timeouts and errors
- [Medium] ntb: epf: dead error handling for CMD_TEARDOWN_MW in ntb_epf_mw_clear_trans()
--

commit ac4b0e780171195c4ee0fe212bcbbbd97ae600ff
Author: Avi Weiss <thnkslprpt@gmail.com>

NTB: epf: propagate MW command errors while status is reliable

This commit propagates command errors from ntb_epf_mw_set_trans() and
ntb_epf_mw_clear_trans() while tracking command timeouts in
ndev->cmd_status_unreliable so that memory window operations continue to
return 0 once a timeout has occurred.

> diff --git a/drivers/ntb/hw/epf/ntb_hw_epf.c b/drivers/ntb/hw/epf/ntb_hw_epf.c
> index da7fbe1800656..455bcefc7c13e 100644
> --- a/drivers/ntb/hw/epf/ntb_hw_epf.c
> +++ b/drivers/ntb/hw/epf/ntb_hw_epf.c
> @@ -102,6 +102,7 @@ struct ntb_epf_dev {
>  	struct device *dev;
>  	/* Mutex to protect providing commands to NTB EPF */
>  	struct mutex cmd_lock;
> +	bool cmd_status_unreliable;
>  
>  	const enum pci_barno *barno_map;
>  
> @@ -148,6 +149,7 @@ static int ntb_epf_send_command_locked(struct ntb_epf_dev *ndev, u32 command,
>  			break;
>  
>  		if (WARN_ON(timedout)) {
> +			ndev->cmd_status_unreliable = true;
>  			ret = -ETIMEDOUT;
>  			break;
>  		}
> @@ -156,6 +158,13 @@ static int ntb_epf_send_command_locked(struct ntb_epf_dev *ndev, u32 command,
>  	}
>  
>  	writew(0, ndev->ctrl_reg + NTB_EPF_CMD_STATUS);
> +	/*
> +	 * After a timeout, a status may refer to an earlier command.
> +	 * MW callers may free buffers on error, so retain old semantics.
> +	 */
> +	if (ndev->cmd_status_unreliable &&
> +	    (command == CMD_CONFIGURE_MW || command == CMD_TEARDOWN_MW))
> +		ret = 0;
>  
>  	return ret;
>  }

[Severity: High]
When CMD_CONFIGURE_MW itself times out in ntb_epf_send_command_locked() in
drivers/ntb/hw/epf/ntb_hw_epf.c, setting ndev->cmd_status_unreliable = true
causes the check right after the loop to immediately overwrite ret =
-ETIMEDOUT with 0.

In ntb_epf_mw_set_trans(), doesn't returning 0 on a CMD_CONFIGURE_MW timeout
release ndev->cmd_lock while the timed-out command is still pending in
ndev->ctrl_reg, allowing multi-window setup loops such as
ntb_transport_link_work() -> ntb_set_mw() -> ntb_mw_set_trans() and
ntb_msi_setup_mws() -> ntb_mw_set_trans() to immediately advance to the next
memory window and overwrite NTB_EPF_LOWER_ADDR, NTB_EPF_UPPER_ADDR,
NTB_EPF_LOWER_SIZE, NTB_EPF_UPPER_SIZE, NTB_EPF_ARGUMENT, and
NTB_EPF_COMMAND?

Callers such as ntb_set_mw(), perf_setup_inbuf(), tool_setup_mw(), and
ntb_msi_setup_mws() also treat the 0 return value as a valid mapping and
bring up the NTB link with an unconfigured inbound BAR window. In addition,
because ndev->cmd_status_unreliable is never cleared once any command times
out (including CMD_LINK_UP or CMD_LINK_DOWN), won't all subsequent
ntb_epf_mw_set_trans() calls permanently mask explicit COMMAND_STATUS_ERROR
(-EINVAL) rejections from the endpoint as well?

> @@ -485,7 +494,7 @@ static int ntb_epf_mw_set_trans(struct ntb_dev *ntb, int pidx, int idx,
>  	struct ntb_epf_dev *ndev = ntb_ndev(ntb);
>  	struct device *dev = ndev->dev;
>  	resource_size_t mw_size;
> -	int bar;
> +	int bar, ret;
>  
>  	if (pidx != NTB_DEF_PEER_IDX) {
>  		dev_err(dev, "Unsupported Peer ID %d\n", pidx);
> @@ -509,19 +518,19 @@ static int ntb_epf_mw_set_trans(struct ntb_dev *ntb, int pidx, int idx,
>  	writel(upper_32_bits(addr), ndev->ctrl_reg + NTB_EPF_UPPER_ADDR);
>  	writel(lower_32_bits(size), ndev->ctrl_reg + NTB_EPF_LOWER_SIZE);
>  	writel(upper_32_bits(size), ndev->ctrl_reg + NTB_EPF_UPPER_SIZE);
> -	ntb_epf_send_command_locked(ndev, CMD_CONFIGURE_MW, idx);
> +	ret = ntb_epf_send_command_locked(ndev, CMD_CONFIGURE_MW, idx);
>  	mutex_unlock(&ndev->cmd_lock);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static int ntb_epf_mw_clear_trans(struct ntb_dev *ntb, int pidx, int idx)
>  {
>  	struct ntb_epf_dev *ndev = ntb_ndev(ntb);
>  	struct device *dev = ndev->dev;
> -	int ret = 0;
> +	int ret;
>  
> -	ntb_epf_send_command(ndev, CMD_TEARDOWN_MW, idx);
> +	ret = ntb_epf_send_command(ndev, CMD_TEARDOWN_MW, idx);
>  	if (ret)
>  		dev_err(dev, "Failed to teardown memory window\n");

[Severity: Medium]
Can this error path in ntb_epf_mw_clear_trans() ever be reached?

In both endpoint handlers (drivers/pci/endpoint/functions/pci-epf-ntb.c and
drivers/pci/endpoint/functions/pci-epf-vntb.c), epf_ntb_cmd_handler()
handles COMMAND_TEARDOWN_MW by unconditionally setting:

	case COMMAND_TEARDOWN_MW:
		epf_ntb_teardown_mw(ntb, ...);
		ctrl->command_status = COMMAND_STATUS_OK;
		break;

Because the endpoint never sets COMMAND_STATUS_ERROR for CMD_TEARDOWN_MW,
the only way CMD_TEARDOWN_MW can fail is via a timeout (which sets
ndev->cmd_status_unreliable = true) or by reading a late status after an
earlier command already timed out (when ndev->cmd_status_unreliable is
already true).

Since ntb_epf_send_command_locked() resets ret = 0 for CMD_TEARDOWN_MW
whenever ndev->cmd_status_unreliable is true, won't ntb_epf_send_command()
always return 0 here, leaving the dev_err() unreachable and silently masking
teardown timeouts when callers such as ntb_free_mw(), perf_free_inbuf(), and
tool_free_mw() are tearing down the window before freeing their DMA buffers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793540847.git.thnkslprpt@gmail.com?part=2

  reply	other threads:[~2026-11-01 14:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01 13:57 [PATCH v2 0/2] NTB: epf: serialize MW setup and report reliable errors Avi Weiss
2026-11-01 13:57 ` [PATCH v2 1/2] NTB: epf: serialize memory window parameter writes Avi Weiss
2026-11-01 15:53   ` Koichiro Den
2026-11-01 13:57 ` [PATCH v2 2/2] NTB: epf: propagate MW command errors while status is reliable Avi Weiss
2026-11-01 14:12   ` sashiko-bot [this message]
2026-11-01 15:56   ` Koichiro Den

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=sashiko-outbox-192437@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ntb@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=thnkslprpt@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 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.