[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci
- To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 7 Feb 2022 14:02:33 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=P4WWKhgOi3M36MYz/R47AZ5xPpJCEJa3GFJDXQgEYPk=; b=BjganenY7zv/VH/f9IR5rdIVfk0D+uvWrYjdfVPwopQRRtKTXJDK32BR3CNL43mver3CXljK8kDlej5hMONSxtIIWd6AhBMvMsj7kviHtPpGsm4AIGWZBaS+snrCtLfCaU5lCqMi7t6i2ZW9Fxu+W5Vwh1uSX2k71M5Unx53H8EhAze7e3cNACiaAhdVmvPvCqEsbE8XnfeV7oZy10Cx92gL/cvEw/jpxR/yQtpsO4dlbjEQjZgQo5NJVjGdnC+C0dVox+dqfARlF6K1w4sZtgdnK4bFGjjA/rPomp/atfayDcJ+GhNhzzQIznCMTYVdR/buDU4Wx56wljjgNCgLew==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e1CpGsIWlQCn8KJ6AQp/b3ysDT5Q+UdZxzBaOyIYRXr+I/Hiozx9sNA6caTMDda3WaXb/Cjk1BoYfzTl/3wObESHnEUINlHs1laIuV5l4Dr7Dk+L/Amww+rFHXYxH0Q+00ISBC4s8n/8F1dvQn7ufYt3qKuts+WsFQ27m5QQbLPSB6p+3Pm8XvzurKi9QBOw1s7GcFptHfVF0oIf661UrvAKWhSwVVSm0dhBO1J3Zj7m5rFyMSSAY0E5VfH1ghXI6l+tzMcnQLV0OYbVuOrGmUTKdgPswp2bfwroS+ih8gmjqTDdNImD/mLjuKTt/Yt6Q73tuY4CIoL1tpseKWSXXA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "george.dunlap@xxxxxxxxxx" <george.dunlap@xxxxxxxxxx>, "paul@xxxxxxx" <paul@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Mon, 07 Feb 2022 13:02:43 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 07.02.2022 13:57, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 14:34, Jan Beulich wrote:
>> On 07.02.2022 12:08, Oleksandr Andrushchenko wrote:
>>> 1. vpci_{read|write} are not protected with pcidevs_lock and can run in
>>> parallel with pci_remove_device which can remove pdev after
>>> vpci_{read|write}
>>> acquired the pdev pointer. This may lead to a fail due to pdev dereference.
>>>
>>> So, to protect pdev dereference vpci_{read|write} must also use pdevs_lock.
>> I think this is not the only place where there is a theoretical race
>> against pci_remove_device().
> Not at all, that was just to demonstrate one of the possible sources of races.
>> I would recommend to separate the
>> overall situation with pcidevs_lock from the issue here.
> Do you agree that there is already an issue with that? In the currently
> existing code?
>> I don't view
>> it as an option to acquire pcidevs_lock in vpci_{read,write}().
> Yes, that would hurt too much, I agree. But this needs to be solved
>> If
>> anything, we need proper refcounting of PCI devices (at which point
>> likely a number of lock uses can go away).
> It seems so. Then not only pdev's need refcounting, but pdev->vpci as well
>
> What's your view on how can we achieve both goals?
> pdev and pdev->vpci and locking/refcounting
I don't see why pdev->vpci might need refcounting. And just to state it
in different words: I'd like to suggest to leave aside the pdev locking
as long as it's _just_ to protect against hot remove of a device. That's
orthogonal to what you need for vPCI, where you need to protect
against the device disappearing from a guest (without at the same time
disappearing from the host).
Jan
|