[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/6] xen: add reference counter support


  • To: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 17 Apr 2023 08:47:20 +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=LNN16guSb2UEKvY1cXgGIaAE7s/NGut5AB7BbY3dch4=; b=j31cs1grh0L33WcxbPnYhRwrWjpMHpySg2VBMnfaXmr0BE0DEKcSB6oegT43gYrBkpyZ0bTyjLS6eXbui4rH8rlI0xOqaphQ8byTthiubuqmbg/FM+99tpbIbKdTDq5Vn9hooAikqkFNt4vXvIDT0qOaDRaBZ52I5RgMKbAu8oHE8R3DvamYGMvHRX8vKY7gyo0/xpsRBCiG6NszRgUTWlzU9VHyLIj4oWm05rWXHGaejjaOZHNK0UFJqm/lzKunUuzbjnyylPIm+/zSe5DpE2pVIYw7YYyle0CyBajfgyyOMUehtcESpIN+DvpShfRltcIowsYu90D4oFc3Yqc2xA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CqpyRRbk21QSISyV2TR+VZv6X9ueppvEXNWDLkWNjO3T5++bFzF9fOHmGO+egj1fZV63GZxwBr7g9eLcMdf0tIBzWDrmv/k+fzFV7WWU8Hh49y0n/CvB7EzWZEa+WnAYUTJEmm5ZXgJ9TJQfDQOpXGz2W6FHwomLhn1wiEQBYbN1TZ8tWW0f1B+IaKuADpebNZPhCDudXaTS0EiZecTj/loI1QECXU7FuGaNC58MiZdAZIaboFgGGqKvh9zGpofdgUo2lOtzn6zeu7naU8xSILa6PwcalhfwhTuDtxhFSTbS7qWDGW4zW5ntjH+Du/S9YMNiRL5bfiPn/Tyg1BNtCA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • 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: Mon, 17 Apr 2023 06:47:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12.04.2023 00:38, Volodymyr Babchuk wrote:
> 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.

If provided via wrappers, that'll be fine of course.

>>> +{
>>> +    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.

Wait. Saturating on overflow might still be a reasonable concept. But
here you convert an underflow to the "saturated" value.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.