Re: [PATCH v1] virtio_blk: should not use IRQD_AFFINITY_MANAGED in init_rq

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Angus Chen <angus.chen@jaguarmicro.com>,
	jasowang@redhat.com, pbonzini@redhat.com, axboe@kernel.dk,
	virtualization@lists.linux-foundation.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	Liming Wu <liming.wu@jaguarmicro.com>,
	stefanha@redhat.com, tglx@linutronix.de
Subject: Re: [PATCH v1] virtio_blk: should not use IRQD_AFFINITY_MANAGED in init_rq
Date: Wed, 28 Sep 2022 06:03:07 -0400	[thread overview]
Message-ID: <20220928055718-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220928094545.GA19646@lst.de>

On Wed, Sep 28, 2022 at 11:45:45AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 27, 2022 at 04:47:20PM -0400, Michael S. Tsirkin wrote:
> > > The log :
> > > "genirq: Flags mismatch irq 0. 00000080 (virtio418) vs. 00015a00 (timer)"
> > > was print because of the irq 0 is used by timer exclusive,and when
> > > vp_find_vqs called vp_find_vqs_msix and return false twice,then it will
> > > call vp_find_vqs_intx for the last try.
> > > Because vp_dev->pci_dev->irq is zero,so it will be request irq 0 with
> > > flag IRQF_SHARED.
> > 
> > First this is a bug. We can fix that so it will fail more cleanly.
> > 
> > We should check pci_dev->pin and if 0 do not try to use INT#x
> > at all.
> > It will still fail, just with a nicer backtrace.
> 
> How do we end up with a pci_dev without a valid PIN?

This patch is broken but there's no v3 which looks right,
and includes an explanation.

>  Btw, that whole
> vp_find_* code looks extremely fucked up to me.  The whole point of
> pci_alloc_irq_vectors* API is that it keeps drivers from poling into
> details of MSI-X v MSI vs INTX.

Poking? I think that code predates that, a minimal change was
made to support affinity... but again, it does not look like the
main issue has anything to do with that. Or maybe I'm wrong ...

> > - because of auto affinity, we try to reserve an interrupt on all CPUs
> > - as there are 512 devices with a single vector per VQ we would
> >   have no issue as they would be spread between CPUs,
> >   but allocating on all CPUs fails.
> > 
> > 
> > I don't think the issue should be fixed at blk level - it is not
> > blk specifix - but yes this looks like a problem.
> > Christoph, any idea?
> 
> I think this goes into the low-level interrupt vector allocator.  I think
> Thomas is still the expert on it.

syzbot is also telling us there's an issue in next (and not due to
virtio changes - I intentionally removed most of them for a while
and the issue was there) but I could not figure it out.

-- 
MST