From: Niklas Cassel <cassel@kernel.org>
To: Koichiro Den <den@valinux.co.jp>
Cc: mani@kernel.org, kwilczynski@kernel.org, kishon@kernel.org,
bhelgaas@google.com, corbet@lwn.net, jingoohan1@gmail.com,
lpieralisi@kernel.org, robh@kernel.org, Frank.Li@nxp.com,
linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] PCI: endpoint: pci-epf-test: Use dedicated pci_epf_bar for subrange mapping
Date: Sat, 31 Jan 2026 18:35:13 +0100 [thread overview]
Message-ID: <aX49Ucwd1PalCcGr@fedora> (raw)
In-Reply-To: <20260131133655.218018-3-den@valinux.co.jp>
On Sat, Jan 31, 2026 at 10:36:54PM +0900, Koichiro Den wrote:
> The BAR subrange setup/clear paths in pci-epf-test used to update
> epf->bar[barno].submap in place and free/restore the submap around
> pci_epc_set_bar() calls.
>
> Some EPC drivers may keep a reference to the struct pci_epf_bar passed
> to pci_epc_set_bar(). Mutating or freeing the same bar descriptor after
> a successful set_bar() can therefore lead to unexpected behaviour.
>
> Use a dedicated pci_epf_bar instance for the subrange mapping test and
> only free the allocated submap after restoring the BAR mapping back to
> the default epf->bar[barno] descriptor.
>
> Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> Suggested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
> drivers/pci/endpoint/functions/pci-epf-test.c | 32 ++++++-------------
> 1 file changed, 10 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 6952ee418622..fd6452d1dcc7 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -86,6 +86,7 @@ struct pci_epf_test {
> bool dma_private;
> const struct pci_epc_features *epc_features;
> struct pci_epf_bar db_bar;
> + struct pci_epf_bar subrange_bar[PCI_STD_NUM_BARS];
If we compare your test:
pci_epf_test_bar_subrange_setup(), the host side decides which BAR you
want to configure.
For pci_epf_test_enable_doorbell(), the function itself uses
pci_epc_get_next_free_bar(), so the EP side decides which BAR to use.
This is a difference, but I think your way is fine.
Another difference is that you have:
struct pci_epf_bar subrange_bar[PCI_STD_NUM_BARS];
while the doorbell test case has:
struct pci_epf_bar db_bar;
Looking at the code, you allow multiple BARs to be configured in subrange
mapping mode (even though the selftest itself will only enable+disable it
for one BAR one by one, but I guess someone could theoretically write their
own test program that puts all the BARs in subrange mapping mode at the same
time).
This is another difference from enable_doorbell(), but again I think your
way is also fine.
Looking at the pci-epf-test code, I realize that, because:
struct pci_epf_bar db_bar;
is just a single struct, doing ioctl ENABLE_DOORBELL multiple times will
just overwrite the existing db_bar struct... Not very nice...
Since it is only one db_bar, pci-epf-test should return an error if
ENABLE_DOORBELL is called multiple times in a row, rather than just silently
overwrite pci_epf_bar db_bar, leaving the previous BAR still configured
while programming yet another BAR for a HW doorbell... This means that
calling DISABLE_DOORBELL will incorrectly just cleanup one BAR and not two...
This is not your bug however...
TL;DR: I think your code looks fine, even though it is different that
the doorbell test case in a few ways.
Also the doorbell test case is buggy, but that is not really your problem.
Kind regards,
Niklas
next prev parent reply other threads:[~2026-01-31 17:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-31 13:36 [PATCH 0/3] PCI: endpoint: Clarify pci_epc_set_bar() lifetime rules Koichiro Den
2026-01-31 13:36 ` [PATCH 1/3] PCI: dwc: ep: Return after clearing BAR-match inbound mapping Koichiro Den
2026-01-31 14:25 ` Niklas Cassel
2026-01-31 13:36 ` [PATCH 2/3] PCI: endpoint: pci-epf-test: Use dedicated pci_epf_bar for subrange mapping Koichiro Den
2026-01-31 17:35 ` Niklas Cassel [this message]
2026-01-31 13:36 ` [PATCH 3/3] PCI: endpoint: Document pci_epc_set_bar() caller ownership and lifetime rules Koichiro Den
2026-01-31 16:50 ` Niklas Cassel
2026-02-01 15:45 ` Koichiro Den
2026-02-01 21:37 ` Niklas Cassel
2026-02-01 21:59 ` Niklas Cassel
2026-02-02 5:59 ` Koichiro Den
2026-02-02 9:27 ` Niklas Cassel
2026-02-02 15:04 ` 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=aX49Ucwd1PalCcGr@fedora \
--to=cassel@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=den@valinux.co.jp \
--cc=jingoohan1@gmail.com \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
/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.