From: Niklas Cassel <cassel@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-nvme@lists.infradead.org, Keith Busch <kbusch@kernel.org>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>
Subject: Re: [PATCH 1/4] nvmet: pci-epf: Clear completion queue IRQ flag on delete
Date: Fri, 9 May 2025 15:14:11 +0200 [thread overview]
Message-ID: <aB3_ownuFAlmOH5J@ryzen> (raw)
In-Reply-To: <457cdc67-443f-4fae-b029-7bbe5b66ff45@kernel.org>
On Fri, May 09, 2025 at 08:13:22AM +0900, Damien Le Moal wrote:
> On 5/8/25 10:07 PM, Niklas Cassel wrote:
> > On Thu, May 08, 2025 at 03:57:42PM +0900, Damien Le Moal wrote:
> >> The function nvmet_pci_epf_delete_cq() unconditionnally calls
> >
> > s/unconditionnally/unconditionally/
> >
> >
> >> nvmet_pci_epf_remove_irq_vector() even for completion queues that do not
> >> have interrupts enabled. Furthermore, for completion queues that do
> >> have IRQ enabled, deleting and re-creating the completion queue leaves
> >> the flag NVMET_PCI_EPF_Q_IRQ_ENABLED set, even if the completion queue
> >> is being re-created with IRQ disabled.
> >>
> >> Fix these issues by calling nvmet_pci_epf_remove_irq_vector() only if
> >> NVMET_PCI_EPF_Q_IRQ_ENABLED is set and make sure to always clear that
> >> flag.
> >>
> >> Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> >> ---
> >> drivers/nvme/target/pci-epf.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> >> index 7fab7f3d79b7..d5442991f2fb 100644
> >> --- a/drivers/nvme/target/pci-epf.c
> >> +++ b/drivers/nvme/target/pci-epf.c
> >> @@ -1344,7 +1344,8 @@ static u16 nvmet_pci_epf_delete_cq(struct nvmet_ctrl *tctrl, u16 cqid)
> >>
> >> cancel_delayed_work_sync(&cq->work);
> >> nvmet_pci_epf_drain_queue(cq);
> >> - nvmet_pci_epf_remove_irq_vector(ctrl, cq->vector);
> >> + if (test_and_clear_bit(NVMET_PCI_EPF_Q_IRQ_ENABLED, &cq->flags))
> >> + nvmet_pci_epf_remove_irq_vector(ctrl, cq->vector);
> >
> > I agree that we should only call nvmet_pci_epf_remove_irq_vector() if
> > NVMET_PCI_EPF_Q_IRQ_ENABLED is set.
> >
> > However, it looks a bit weird to explicitly only clear only this flag bit.
> > What about the other flag bits?
>
> NVMET_PCI_EPF_Q_LIVE is cleared in the same function in the same manner. The
> only other flag is NVMET_PCI_EPF_Q_IRQ_ENABLED, which this patch clears.
>
> > I would have expected a memset() of flags, or flags = 0; in either
> > .create_cq/.create_sq, or in .delete_cq/.delete_sq.
You patch looks fine, I was just thinking that it would be slightly more robust
to do flags = 0; in e.g. .create_cq/.create_sq, or .delete_cq/.delete_sq.
That way, we remove the possibility of ever introducing a similar bug to what
this patch fixes. (I.e if we ever add a new flag, we will not need to remember
to also add code that explicitly clears the bit for that new flag, since
flags = 0; clears all flags in one go.)
Kind regards,
Niklas
next prev parent reply other threads:[~2025-05-09 14:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 6:57 [PATCH 0/4] nvmet pci-epf fixes Damien Le Moal
2025-05-08 6:57 ` [PATCH 1/4] nvmet: pci-epf: Clear completion queue IRQ flag on delete Damien Le Moal
2025-05-08 13:07 ` Niklas Cassel
2025-05-08 23:13 ` Damien Le Moal
2025-05-09 13:14 ` Niklas Cassel [this message]
2025-05-08 6:57 ` [PATCH 2/4] nvmet: pci-epf: Do not fall back to using INTX if not supported Damien Le Moal
2025-05-08 13:07 ` Niklas Cassel
2025-05-08 23:14 ` Damien Le Moal
2025-05-08 6:57 ` [PATCH 3/4] nvmet: pci-epf: Cleanup nvmet_pci_epf_raise_irq() Damien Le Moal
2025-05-08 13:07 ` Niklas Cassel
2025-05-08 23:16 ` Damien Le Moal
2025-05-08 6:57 ` [PATCH 4/4] nvmet: pci-epf: Improve debug message Damien Le Moal
2025-05-08 13:07 ` Niklas Cassel
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=aB3_ownuFAlmOH5J@ryzen \
--to=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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.