linux-kernel - Re: [PATCH v3 1/1] PCI: endpoint: pci-epf-test: Call pci_epf_test_raise

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAEEuhpt_WnxOZeYsMxjwTGZm-FJKoj3at-qPgyAH6D76P9wOA@mail.gmail.com>
Date: Tue, 20 Aug 2024 10:43:56 +0200
From: Rick Wertenbroek <rick.wertenbroek@...il.com>
To: Damien Le Moal <dlemoal@...nel.org>
Cc: rick.wertenbroek@...g-vd.ch, alberto.dassatti@...g-vd.ch, 
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, Krzysztof Wilczyński <kw@...ux.com>, 
	Kishon Vijay Abraham I <kishon@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Niklas Cassel <cassel@...nel.org>, Frank Li <Frank.Li@....com>, 
	Lars-Peter Clausen <lars@...afoo.de>, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] PCI: endpoint: pci-epf-test: Call
 pci_epf_test_raise_irq() on failed DMA check

On Tue, Aug 20, 2024 at 10:18 AM Damien Le Moal <dlemoal@...nel.org> wrote:
>
> On 8/20/24 16:10, Rick Wertenbroek wrote:
> > The pci-epf-test PCI endpoint function /drivers/pci/endpoint/function/pci-epf_test.c
> > is meant to be used in a PCI endpoint device connected to a host computer
> > with the host side driver: /drivers/misc/pci_endpoint_test.c.
> >
> > The host side driver can request read/write/copy transactions from the
> > endpoint function and expects an IRQ from the endpoint function once
> > the read/write/copy transaction is finished. These can be issued with or
> > without DMA enabled. If the host side driver requests a read/write/copy
> > transaction with DMA enabled and the endpoint function does not support
> > DMA, the endpoint would only print an error message and wait for further
> > commands without sending an IRQ because pci_epf_test_raise_irq() is
> > skipped in pci_epf_test_cmd_handler(). This results in the host side
> > driver hanging indefinitely waiting for the IRQ.
> >
> > Call pci_epf_test_raise_irq() when a transfer with DMA is requested but
> > DMA is unsupported. The host side driver will no longer hang but report
> > an error on transfer (printing "NOT OKAY") thanks to the checksum because
> > no data was moved.
> >
> > Clarify the error message in the endpoint function as "Cannot ..." is
> > vague and does not state the reason why it cannot be done.
> >
> > Signed-off-by: Rick Wertenbroek <rick.wertenbroek@...il.com>
> > ---
> >  drivers/pci/endpoint/functions/pci-epf-test.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index 7c2ed6eae53a..b02193cef06e 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -649,7 +649,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work)
> >
> >       if ((READ_ONCE(reg->flags) & FLAG_USE_DMA) &&
> >           !epf_test->dma_supported) {
> > -             dev_err(dev, "Cannot transfer data using DMA\n");
> > +             dev_err(dev, "DMA transfer not supported\n");
>
> Should we set the FAIL status flag here ?
> E.g.:
>                  reg->status |= STATUS_READ_FAIL;
>
> Note: I have no idea why the status flags are different for the different
> operations. We should really have a single SUCCESS/FAIL flag common to all
> operations. So I think we could just do:
>
>                 reg->status |= STATUS_READ_FAIL | STATUS_WRITE_FAIL |
>                         STATUS_COPY_FAIL;
>
> here, or go back to your v1 and handle the failure in each operation function to
> set the correct flag.
>

Good catch, indeed with the check outside of the functions, the status
FAIL bits are not set. I think setting the status as a combined fail
flag makes sense, however, it conveys the idea that read/write/copy
failed whereas only one of them actually failed.

I agree that a single status SUCCESS/FAIL flag would be simpler. But
changing this would require changes on both sides (EP & RC) and will
reduce compatibility between EP and RC side driver versions, so I
would refrain from changing this.

 I think I still prefer the v1/v2 code because even as it has a little
bit of duplication it is clear and sets the correct FAIL bit without
extra logic whereas here we either set all FAIL bits or have to add
extra logic.

Thank you for spotting this.

> > +             pci_epf_test_raise_irq(epf_test, reg);
> >               goto reset_handler;
> >       }
> >
>
> --
> Damien Le Moal
> Western Digital Research
>

Best regards,
Rick