From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [RFC PATCH 04/10] xen: add reference counter support
Date: Fri, 17 Feb 2023 01:56:26 +0000 [thread overview]
Message-ID: <87sff512d2.fsf@epam.com> (raw)
In-Reply-To: <a89db71d-dc4d-5b17-1528-4b8a4243addc@suse.com>
Hello Jan,
Jan Beulich <jbeulich@suse.com> writes:
> On 31.08.2022 16:10, Volodymyr Babchuk wrote:
>> --- /dev/null
>> +++ b/xen/include/xen/refcnt.h
>> @@ -0,0 +1,28 @@
>> +#ifndef __XEN_REFCNT_H__
>> +#define __XEN_REFCNT_H__
>> +
>> +#include <asm/atomic.h>
>> +
>> +typedef atomic_t refcnt_t;
>
> Like Linux has it, I think this would better be a separate struct. At
> least in debug builds, i.e. it could certainly use typesafe.h if that
> ended up to be a good fit (which I'm not sure it would, so this is
> merely a thought).
Sadly, TYPE_SAFE does not support pointers. e.g I can't get pointer to
an encapsulated value which is also passed as a pointer. I can expand
TYPE_SAFE with $FOO_x_ptr():
static inline _type *_name##_x_ptr(_name##_t *n) { &return n->_name; }
or make custom encapsulation in refcnt.h. Which one you prefer?
>> +static inline void refcnt_init(refcnt_t *refcnt)
>> +{
>> + atomic_set(refcnt, 1);
>> +}
>> +
>> +static inline void refcnt_get(refcnt_t *refcnt)
>> +{
>> +#ifndef NDEBUG
>> + ASSERT(atomic_add_unless(refcnt, 1, 0) > 0);
>> +#else
>> + atomic_add_unless(refcnt, 1, 0);
>> +#endif
>> +}
> I think this wants doing without any #ifdef-ary, e.g.
>
> static inline void refcnt_get(refcnt_t *refcnt)
> {
> int ret = atomic_add_unless(refcnt, 1, 0);
>
> ASSERT(ret > 0);
> }
>
Thanks, did as you suggested. I was afraid that compiler would complain
about unused ret in non-debug builds.
> I wonder though whether certain callers may not want to instead know
> whether a refcount was successfully obtained, i.e. whether instead of
> asserting here you don't want to return a boolean success indicator,
> which callers then would deal with (either by asserting or by suitably
> handling the case). See get_page() and page_get_owner_and_reference()
> for similar behavior we have (and use) already.
For now there are no such callers, so I don't want to implement unused
functionality. But, if you prefer this way, I'll do this.
[...]
next prev parent reply other threads:[~2023-02-17 1:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 14:10 [RFC PATCH 00/10] Rework PCI locking Volodymyr Babchuk
2022-08-31 14:10 ` [RFC PATCH 01/10] xen: pci: add per-domain pci list lock Volodymyr Babchuk
2023-01-26 23:18 ` Stefano Stabellini
2023-01-27 8:01 ` Jan Beulich
2023-02-14 23:38 ` Volodymyr Babchuk
2023-02-15 9:06 ` Jan Beulich
2022-08-31 14:10 ` [RFC PATCH 03/10] xen: pci: introduce ats_list_lock Volodymyr Babchuk
2023-01-26 23:56 ` Stefano Stabellini
2023-01-27 8:13 ` Jan Beulich
2023-02-17 1:20 ` Volodymyr Babchuk
2023-02-17 7:39 ` Jan Beulich
2022-08-31 14:10 ` [RFC PATCH 02/10] xen: pci: add pci_seg->alldevs_lock Volodymyr Babchuk
2023-01-26 23:40 ` Stefano Stabellini
2023-02-28 16:32 ` Jan Beulich
2022-08-31 14:10 ` [RFC PATCH 04/10] xen: add reference counter support Volodymyr Babchuk
2023-02-15 11:20 ` Jan Beulich
2023-02-17 1:56 ` Volodymyr Babchuk [this message]
2023-02-17 7:53 ` Jan Beulich
2023-02-19 22:34 ` Volodymyr Babchuk
2022-08-31 14:11 ` [RFC PATCH 06/10] xen: pci: print reference counter when dumping pci_devs Volodymyr Babchuk
2022-08-31 14:11 ` [RFC PATCH 05/10] xen: pci: introduce reference counting for pdev Volodymyr Babchuk
2023-01-27 0:43 ` Stefano Stabellini
2023-02-20 22:00 ` Volodymyr Babchuk
2023-02-28 17:06 ` Jan Beulich
2022-08-31 14:11 ` [RFC PATCH 08/10] xen: pci: remove pcidev_[un]lock[ed] calls Volodymyr Babchuk
2023-01-28 1:32 ` Stefano Stabellini
2023-02-20 23:13 ` Volodymyr Babchuk
2023-02-21 9:50 ` Jan Beulich
2023-03-09 1:22 ` Volodymyr Babchuk
2023-03-09 9:06 ` Jan Beulich
2023-02-28 16:51 ` Jan Beulich
2022-08-31 14:11 ` [RFC PATCH 09/10] [RFC only] xen: iommu: remove last pcidevs_lock() calls in iommu Volodymyr Babchuk
2023-01-28 1:36 ` Stefano Stabellini
2023-02-20 0:41 ` Volodymyr Babchuk
2023-02-28 16:25 ` Jan Beulich
2022-08-31 14:11 ` [RFC PATCH 07/10] xen: pci: add per-device locking Volodymyr Babchuk
2023-01-28 0:56 ` Stefano Stabellini
2023-02-20 22:29 ` Volodymyr Babchuk
2023-02-28 16:46 ` Jan Beulich
2022-08-31 14:11 ` [RFC PATCH 10/10] [RFC only] xen: pci: remove pcidev_lock() function Volodymyr Babchuk
2022-09-06 10:32 ` [RFC PATCH 00/10] Rework PCI locking Jan Beulich
2023-01-18 18:21 ` Julien Grall
2023-01-19 9:47 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sff512d2.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=Oleksandr_Andrushchenko@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.