[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-4.17 3/6] vpci: don't assume that vpci per-device data exists unconditionally
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 24 Oct 2022 18:06:55 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ixLkR1K9Q55B9dQyLI2XMpKJenS/ngAxUQrrBiLHQss=; b=ltU+oNFbLfhV+aWobF/JFqJUgOBD7J1EIFjT5f6HN0lEM0Jx+diqGWbCR88yXSkw3dpn0gMnBc4JUUvbu2mHRyU59T0nFl1vRuEG/bbTkVFJUnnt10m7hyovHNl4H1g0Jg0xftcFMgpm/Z68e1lALz1JTlrVK8+ZqDWnbObpAbG0BZAXoUdchEFpVc2xFKmLfgOk3lgRgFSc1Qaq8DYziK14JCb/zplwfaezJyRPD81iHlocg8qJ1v7UvBbDL4JEGyRwtLOZdZtiIMZp69LHft5nx8TW53iJ3xPdQtfyzTJxyu50fBrknlDS5iyKvHGuHkS4UmWkOjLAiYya1IQb5g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IPCvP761SPk0gUeX20qgGUyorRvQvLc43QTVXkO7bNt5HT7ZzSSuioSF3f26MW9/sh7JUetDCJjXMLtIDPSo5Okx5nSBLNNnvOhzV+iZ+0D/xrIVPyiytXiosd1qhiixb7hNb472jAAGnJemy4by/wCfkiP2IrRvJO4HgIl5WcQC+JTwU+v0eOr5MqSE8KwwHmX8L5TC4k38OsQpOs1+V8tq4ZUiCrLXh8oyswXVOxF+JoUPKpdd+DuYsjdpxtbM76L8VHND92k+YjBYj4SMNvLHASO5ORpV9P6QPlaZ+eWPbdtG5MO/FGXmh3Sl8FRepXtjSHW+Yn5zImTC0YAupQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 24 Oct 2022 16:07:03 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 24.10.2022 18:01, Roger Pau Monné wrote:
> On Mon, Oct 24, 2022 at 01:04:01PM +0200, Jan Beulich wrote:
>> Furthermore msix_find() iterates over d->arch.hvm.msix_tables, which
>> looks to only ever be added to. Doesn't this list need pruning by
>> vpci_remove_device()? I've noticed this only because of looking at
>> derefs of ->vpci in msix.c - I don't think I can easily see that all
>> of those derefs are once again immune to a pdev losing its ->vpci.
>
> I think you are correct, we are missing a
> list_del(&pdev->vpci->msix->next) in vpci_remove_device(). We will
> however have locking issues with this, as msix_find() doesn't take any
> locks, neither do it's callers. I guess this will be fixed as part of
> the lager add vPCI locking series. Will add another patch to the
> series with the MSIX table removal.
But the locking issue the isn't new then: List insertion can also disturb
msix_find(), can't it?
Jan
|
