On 12/6/19 12:17 PM, Jan Beulich wrote: > On 06.12.2019 12:48, George Dunlap wrote: >> --- a/CODING_STYLE >> +++ b/CODING_STYLE >> @@ -133,3 +133,86 @@ the end of files. It should be: >> * indent-tabs-mode: nil >> * End: >> */ >> + >> +Handling unexpected conditions >> +------------------------------ >> + >> +GUIDELINES: >> + >> +Passing errors up the stack should be used when the caller is already >> +expecting to handle errors, and the state when the error was >> +discovered isn’t broken, or too isn't hard to fix. > > Was the "too" meant to come later in the sentence?
I did actually go through this several times; I don't have any idea how I managed to miss all these editing mistakes! All editing comments are "ack" unless otherwise mentioned. >> +domain_crash() should be used when passing errors up the stack is too >> +difficult, and/or when fixing up state of a guest is impractical, but >> +where fixing up the state of Xen will allow Xen to continue running. >> + >> +BUG_ON() should be used when you can’t pass errors up the stack, and >> +either continuing or crashing the guest would likely cause an >> +information leak or privilege escalation vulnerability. > > Strictly speaking BUG_ON() isn't an error handling mechanism either. > Further down it becomes more clear (it rather to be used for > detecting broken assumptions), but I guess it wouldn't hurt to say > so here as well. I guess it depends on what you mean by "error handling mechanism". The BUG_ON() in page_alloc.c has reliably changed potential privilege escalations into "mere" DoSes over the years. The distinction I'm trying to draw between BUG_ON() and ASSERT() is that BUG_ON() actually handles the situation (albeit with a very heavy hammer). ASSERT() is essentially a more noticeable printk. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
