* [PATCH] qom: assert integer does not overflow @ 2022-02-25 14:10 Michael S. Tsirkin 2022-02-25 14:35 ` Daniel P. Berrangé 0 siblings, 1 reply; 4+ messages in thread From: Michael S. Tsirkin @ 2022-02-25 14:10 UTC (permalink / raw) To: qemu-devel Cc: Eduardo Habkost, Daniel P. Berrangé, Jason Wang, Victor Tom, Paolo Bonzini, Stefano Garzarella 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] qom: assert integer does not overflow 2022-02-25 14:10 [PATCH] qom: assert integer does not overflow Michael S. Tsirkin @ 2022-02-25 14:35 ` Daniel P. Berrangé 2022-02-28 12:16 ` Michael S. Tsirkin 0 siblings, 1 reply; 4+ messages in thread From: Daniel P. Berrangé @ 2022-02-25 14:35 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Eduardo Habkost, Jason Wang, qemu-devel, Victor Tom, Paolo Bonzini, Stefano Garzarella 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 :| ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] qom: assert integer does not overflow 2022-02-25 14:35 ` Daniel P. Berrangé @ 2022-02-28 12:16 ` Michael S. Tsirkin 2022-02-28 13:51 ` Michael S. Tsirkin 0 siblings, 1 reply; 4+ messages in thread From: Michael S. Tsirkin @ 2022-02-28 12:16 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Eduardo Habkost, Jason Wang, qemu-devel, Victor Tom, Paolo Bonzini, Stefano Garzarella 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 :| ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] qom: assert integer does not overflow 2022-02-28 12:16 ` Michael S. Tsirkin @ 2022-02-28 13:51 ` Michael S. Tsirkin 0 siblings, 0 replies; 4+ messages in thread From: Michael S. Tsirkin @ 2022-02-28 13:51 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Eduardo Habkost, Jason Wang, qemu-devel, Victor Tom, Paolo Bonzini, Stefano Garzarella 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 :| ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-02-28 13:56 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-02-25 14:10 [PATCH] qom: assert integer does not overflow Michael S. Tsirkin 2022-02-25 14:35 ` Daniel P. Berrangé 2022-02-28 12:16 ` Michael S. Tsirkin 2022-02-28 13:51 ` Michael S. Tsirkin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).