[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/6] xen: add reference counter support
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Date: Tue, 11 Apr 2023 22:38:56 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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=BVMeI+YDw0P+RLQYwajulzk0QC6yTYde2vQfAduLjHg=; b=TV3TpcHLdqKn1LvUqmrKQRvANg4jmrh+kb1hvNiPU1KECCjK1I+RvvkLMA7skNkH3CSs2gcq0ki1oeudY6EYyWuoDw/afdFbtDgPneAobBLf8lEphoAB3j+DUk6ml380oNtXJp1t4uV8M6V1Ev7EzKy9w9cVUezVpr9GUZX6TeqzKERDKvcch9ZILdAZZM4fXlzFHCAkVQk9q+GQ5ZoMzHw9OVzB4wNkZhPKgEF1qtMotjM+7u+aEfpszTme6fI0dD4WAhBg4KQcpJXRtPpdj/EyvSkDmsDz5Wul5q2WyhT2re+IWciY090z4uCa9I9wV1XUXZKTrRYvK9MRMsrqjQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hvJjmrM7M3IQZEKpfk/1/0fX7L+q3Hpr5kVbX5otyatiHmap6aWNVzCv3UWCIFHo84zOqPb2DL9OrWWBoa3sBhiGK0BQHPemLXePDcpaj0dRtxcVdymd0Q/6xf4LXcAtRPbSd1s2YQgDufk3F1wrT5GK2ENkt3tJwRutRCD+wj1GdgcPkkXooc+sZe5dQT1NLlfVLhycmQwCoeKv6jvfGyuZ8Ea+obmyep/v7dOZt1gH0DyIzrWhXaFQFlvc4yPk0SJiPtxeHSgmX5oe7+56IGK7iJOEYM3zYLPdg1Xu5Fh3X9MMJlJxJ6oREIuBjxUcYWK1I43GTj6yK2r8TjQZ2w==
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 11 Apr 2023 22:39:18 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZVrdyBx9pogLqRUq3RbhGdjZNSK79pIaAgCk3xwA=
- Thread-topic: [PATCH v3 1/6] xen: add reference counter support
Jan Beulich <jbeulich@xxxxxxxx> writes:
> On 14.03.2023 21:56, Volodymyr Babchuk wrote:
>> +static inline void refcnt_put(refcnt_t *refcnt, void (*destructor)(refcnt_t
>> *refcnt))
>
> Hmm, this means all callers need to pass (and agree on) the supposedly
> single destructor function that needs calling. Wouldn't the destructor
> function better be stored elsewhere (and supplied to e.g. refcnt_init())?
>
I tried to replicate Linux approach. They provide destructor function
every time. On other hand, kref_put() is often called from a wrapper
function (like pdev_put() in our case), so destructor in fact, is
provided only once.
>> +{
>> + int ret = atomic_dec_return(&refcnt->refcnt);
>> +
>> + if ( ret == 0 )
>> + destructor(refcnt);
>> +
>> + if ( unlikely(ret < 0))
>> + {
>> + atomic_set(&refcnt->refcnt, REFCNT_SATURATED);
>
> It's undefined whether *refcnt still exists once the destructor was
> called (which would have happened before we can make it here). While
> even the atomic_dec_return() above would already have acted in an
> unknown way in this case I don't think it's a good idea to access the
> object yet another time. (Same for the "negative" case in
> refcnt_get() then.)
Okay, then I'll remove saturation logic.
--
WBR, Volodymyr
|
