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

[Mihai Donțu <mihai.dontu@xxxxxxxxx>]

On Tue, 13 Sep 2016 19:25:54 +0100 Andrew Cooper wrote:
> 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?

I did not post and updated version after the last review because I
wanted to produce some numbers too (wrt performance impact) ... and I
stopped there as I got distracted by other issues. I have a good mind
to update it, write a quick test and publish them. I hope I can do this
all sometime next week.

-- 
Mihai Donțu

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