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

Re: [Xen-devel] BUG_ON() vs ASSERT()



On 13/09/16 14:46, Mihai Donțu wrote:
> On Tue, 13 Sep 2016 09:10:32 -0400 Konrad Rzeszutek Wilk wrote:
>> On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote:
>>> All,
>>>
>>> in
>>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html
>>> and
>>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html
>>> Andrew basically suggests that we should switch away from using
>>> ASSERT() and over to BUG_ON() in perhaps quite broad a set of
>>> cases. And honestly I'm not convinced of this: We've been adding
>>> quite a few ASSERT()s over the last years with the aim of doing
>>> sanity checking in debug builds, without adding overhead to non-
>>> debug builds. I can certainly see possible cases where using
>>> BUG_ON() to prevent further possible damage is appropriate, but
>>> I don't think we should overdo here.
>>>
>>> Thanks for other's opinions,  
>> I am in the mindset that ASSERTS are in the cases where a check
>> has been done earlier and the ASSERT is more of a catch if we ended up
>> somehow in the wrong state. We can then slowly follow the breadcrumbs to
>> see what changed the state. In other words - something that the hypervisor
>> has checked for and that invariant should have not changed.
>>
>> But a BUG_ON is in the same category - it should not have happend.
>>
>> Perhaps the distinction is that for ASSERTS() it is to catch me messing
>> things up. While BUG_ON() is something (or somebody) else messing things up.
>>
>> It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now
>> that I think of it ..
> I would see ASSERT() used to check for conditions that have immediate
> and visible consequences, like the ones that lead to lack of
> functionality (like a hw feature misdetection) or straight crashes
> (like NULL-dereference).

NULL dereferences in the context of PV guests are also a security issue,
as the PV guest controls what is mapped at 0.

>  BUG_ON(), on the other hand, would be an early
> warning for subtle corruptions that can lead to a hypervisor crash or
> corrupted data after many hours of use (close to impossible to track
> down).
>
> For example, a while ago I posted a small patch that would BUG_ON()
> when it detected that the heap chunks were not properly linked. That's
> the type of bug that's a pain to detect.

Speaking of, what happened to that patch?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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