[PATCH] qom: assert integer does not overflow

[PATCH] qom: assert integer does not overflow

[Michael S. Tsirkin]

QOM reference counting is not designed with an infinite amount of
references in mind, trying to take a reference in a loop will overflow
the integer. We will then eventually assert when dereferencing, but the
real problem is in object_ref so let's assert there to make such issues
cleaner and easier to debug.

Some micro-benchmarking shows using fetch and add this is essentially
free on x86.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 qom/object.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/qom/object.c b/qom/object.c
index 4f0677cca9..5db3974f04 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -1167,10 +1167,14 @@ GSList *object_class_get_list_sorted(const char *implements_type,
 Object *object_ref(void *objptr)
 {
     Object *obj = OBJECT(objptr);
+    uint32_t ref;
+
     if (!obj) {
         return NULL;
     }
-    qatomic_inc(&obj->ref);
+    ref = qatomic_fetch_inc(&obj->ref);
+    /* Assert waaay before the integer overflows */
+    g_assert(ref < INT_MAX);
     return obj;
 }
 
-- 
MST

Re: [PATCH] qom: assert integer does not overflow

[Daniel P. Berrangé]

On Fri, Feb 25, 2022 at 09:10:44AM -0500, Michael S. Tsirkin wrote:
> QOM reference counting is not designed with an infinite amount of
> references in mind, trying to take a reference in a loop will overflow
> the integer. We will then eventually assert when dereferencing, but the
> real problem is in object_ref so let's assert there to make such issues
> cleaner and easier to debug.

What is the actual bug / scenario that led you to hit this problem ?

I'm surprised you saw an assert in object_unref, as that would
imply you had exactly  UINT32_MAX calls to object_ref and then
one to object_unref.

> Some micro-benchmarking shows using fetch and add this is essentially
> free on x86.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>  qom/object.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/qom/object.c b/qom/object.c
> index 4f0677cca9..5db3974f04 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -1167,10 +1167,14 @@ GSList *object_class_get_list_sorted(const char *implements_type,
>  Object *object_ref(void *objptr)
>  {
>      Object *obj = OBJECT(objptr);
> +    uint32_t ref;
> +
>      if (!obj) {
>          return NULL;
>      }
> -    qatomic_inc(&obj->ref);
> +    ref = qatomic_fetch_inc(&obj->ref);
> +    /* Assert waaay before the integer overflows */
> +    g_assert(ref < INT_MAX);

Not that I expect this to hit, but why choose this lower
bound instead of g_assert(ref > 0) which is the actual
failure scenario, matching the existing object_unref
assert.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] qom: assert integer does not overflow

[Michael S. Tsirkin]

On Fri, Feb 25, 2022 at 02:35:36PM +0000, Daniel P. Berrangé wrote:
> On Fri, Feb 25, 2022 at 09:10:44AM -0500, Michael S. Tsirkin wrote:
> > QOM reference counting is not designed with an infinite amount of
> > references in mind, trying to take a reference in a loop will overflow
> > the integer. We will then eventually assert when dereferencing, but the
> > real problem is in object_ref so let's assert there to make such issues
> > cleaner and easier to debug.
> 
> What is the actual bug / scenario that led you to hit this problem ?

E.g. if during code development I call object_ref but not object_unref,
the counter eventually overflows. If this triggers in an error flow
and not a good path this kind of bug might thinkably make it through QE
into release code.

> I'm surprised you saw an assert in object_unref, as that would
> imply you had exactly  UINT32_MAX calls to object_ref and then
> one to object_unref.

Any imbalance with # of unrefs > # refs
will trigger an existing assert in unref.

However, an imbalance with # of refs > # unrefs does not trigger an
assert at the moment.


> > Some micro-benchmarking shows using fetch and add this is essentially
> > free on x86.
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >  qom/object.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/qom/object.c b/qom/object.c
> > index 4f0677cca9..5db3974f04 100644
> > --- a/qom/object.c
> > +++ b/qom/object.c
> > @@ -1167,10 +1167,14 @@ GSList *object_class_get_list_sorted(const char *implements_type,
> >  Object *object_ref(void *objptr)
> >  {
> >      Object *obj = OBJECT(objptr);
> > +    uint32_t ref;
> > +
> >      if (!obj) {
> >          return NULL;
> >      }
> > -    qatomic_inc(&obj->ref);
> > +    ref = qatomic_fetch_inc(&obj->ref);
> > +    /* Assert waaay before the integer overflows */
> > +    g_assert(ref < INT_MAX);
> 
> Not that I expect this to hit, but why choose this lower
> bound instead of g_assert(ref > 0) which is the actual
> failure scenario, matching the existing object_unref
> assert.

The earlier we catch it the better, if we overflowed to 0 some other
thread might already be confused.


> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] qom: assert integer does not overflow

[Michael S. Tsirkin]

On Mon, Feb 28, 2022 at 07:16:56AM -0500, Michael S. Tsirkin wrote:
> On Fri, Feb 25, 2022 at 02:35:36PM +0000, Daniel P. Berrangé wrote:
> > On Fri, Feb 25, 2022 at 09:10:44AM -0500, Michael S. Tsirkin wrote:
> > > QOM reference counting is not designed with an infinite amount of
> > > references in mind, trying to take a reference in a loop will overflow
> > > the integer. We will then eventually assert when dereferencing, but the
> > > real problem is in object_ref so let's assert there to make such issues
> > > cleaner and easier to debug.
> > 
> > What is the actual bug / scenario that led you to hit this problem ?
> 
> E.g. if during code development I call object_ref but not object_unref,
> the counter eventually overflows. If this triggers in an error flow
> and not a good path this kind of bug might thinkably make it through QE
> into release code.
> 
> > I'm surprised you saw an assert in object_unref, as that would
> > imply you had exactly  UINT32_MAX calls to object_ref and then
> > one to object_unref.
> 
> Any imbalance with # of unrefs > # refs
> will trigger an existing assert in unref.
> 
> However, an imbalance with # of refs > # unrefs does not trigger an
> assert at the moment.
> 

A vsock patch Stefano just posted would be one example where this can happen.

> > > Some micro-benchmarking shows using fetch and add this is essentially
> > > free on x86.
> > > 
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > >  qom/object.c | 6 +++++-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/qom/object.c b/qom/object.c
> > > index 4f0677cca9..5db3974f04 100644
> > > --- a/qom/object.c
> > > +++ b/qom/object.c
> > > @@ -1167,10 +1167,14 @@ GSList *object_class_get_list_sorted(const char *implements_type,
> > >  Object *object_ref(void *objptr)
> > >  {
> > >      Object *obj = OBJECT(objptr);
> > > +    uint32_t ref;
> > > +
> > >      if (!obj) {
> > >          return NULL;
> > >      }
> > > -    qatomic_inc(&obj->ref);
> > > +    ref = qatomic_fetch_inc(&obj->ref);
> > > +    /* Assert waaay before the integer overflows */
> > > +    g_assert(ref < INT_MAX);
> > 
> > Not that I expect this to hit, but why choose this lower
> > bound instead of g_assert(ref > 0) which is the actual
> > failure scenario, matching the existing object_unref
> > assert.
> 
> The earlier we catch it the better, if we overflowed to 0 some other
> thread might already be confused.
> 
> 
> > Regards,
> > Daniel
> > -- 
> > |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> > |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> > |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|