[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/6] xen: add reference counter support
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 16 Mar 2023 17:43:18 +0100
- 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=pEyxj6zpNLrSbvwDiU4yAXhzGGRI7iS52BqpzPdzo78=; b=fb88pi9vEIjlXkfPCTmua4S3szukraXfoQ9azBJoYMoa4uvcnS9S0qgvZ7rwmtnob+rnX/JiTNK7DLoGmwNNRVWIn5PcJn8mMu2ku9290UrXfkesTqokzHaicgSIN+rv0YBTaLUdbiyk9vDgAYfZ61xTzxxgZ7C6WrL0g/qnDFXIKubH4EtqLD0zz1xCEV2L20CvHNCwmizVZ/Nemcix0zHnOBtHvnjIChOFlDPTAzT0O+sRSRBt0O4Kgb9ogtZqzd+QVPyTxVO86GwziZB8/mIUHbX8ssPE9C0o5DxdY7Uhd/v0TMO6kjmnfWgMuTSmFpDHySyuDLWvrvc6KY9XXA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hx57RJghJu7slPmUgmjtwmK3u5NM4fA6xv+6QfacyB76X7K4IBWex2PGSx6xF2tcZLei1wgpQHrq0tNqMp0HCg9i75zmC25xTkzuL0KeeZfBegQ7XQmj1a83wTMS6sr2reHtnhIhCz4jsUJHvV0ixS+iME1QOkWgx8rVa8NJv+nK3SZ1kawAXiPyoyeTrYeSr6EwFd8pzDbrbncEcTzaZtd3LDpZbN9t+eG+wfPrwpJfftLgqUBpFJXya6rGwoT5sf3Ihnzw46PGuSQFZp/cveLTnfuXTfStZBg9R1hva/n6B8tooVQhwpBCZ9sgXdzuhdr4T4cWGo7AwEN992QZLw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Thu, 16 Mar 2023 16:43:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 16.03.2023 17:39, Roger Pau Monné wrote:
> On Thu, Mar 16, 2023 at 05:32:38PM +0100, Jan Beulich wrote:
>> On 16.03.2023 17:19, Roger Pau Monné wrote:
>>> On Tue, Mar 14, 2023 at 08:56:29PM +0000, Volodymyr Babchuk wrote:
>>>> +static inline void refcnt_get(refcnt_t *refcnt)
>>>> +{
>>>> + int old = atomic_add_unless(&refcnt->refcnt, 1, 0);
>>>
>>> Occurred to me while looking at the next patch:
>>>
>>> Don't you also need to print a warning (and saturate the counter
>>> maybe?) if old == 0, as that would imply the caller is attempting
>>> to take a reference of an object that should be destroyed? IOW: it
>>> would point to some kind of memory leak.
>>
>> Hmm, I notice the function presently returns void. I think what to do
>> when the counter is zero needs leaving to the caller. See e.g.
>> get_page() which will simply indicate failure to the caller in case
>> the refcnt is zero. (There overflow handling also is left to the
>> caller ... All that matters is whether a ref can be acquired.)
>
> Hm, likely. I guess pages never go away even when it's refcount
> reaches 0.
>
> For the pdev case attempting to take a refcount on an object that has
> 0 refcounts implies that the caller is using leaked memory, as the
> point an object reaches 0 it supposed to be destroyed.
Hmm, my thinking was that a device would remain at refcnt 0 until it is
actually removed, i.e. refcnt == 0 being a prereq for pci_remove_device()
to be willing to do anything at all. But maybe that's not a viable model.
Jan
|
