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

Re: [Xen-devel] [PATCH RFC V2 01/45] xen/sched: add inline wrappers for calling per-scheduler functions



On Thu, 2019-05-09 at 12:56 +0200, Juergen Gross wrote:
> On 09/05/2019 12:04, George Dunlap wrote:
> > On 5/9/19 6:32 AM, Juergen Gross wrote:
> > > On 08/05/2019 18:24, George Dunlap wrote:
> > > > 
> > > > I think these would better as BUG_ON()s.  These aren't hot
> > > > paths, and if
> > > > we do somehow hit this situation in production, 1) it's safer
> > > > to
> > > > BUG_ON() than dereferencing NULL, and 2) you'll get a more
> > > > helpful error
> > > > message.
> > > 
> > > Only for those 2 instances above? Or would you like BUG_ON()
> > > instead of
> > > ASSERT() in the other added inlines, too (maybe not for pick_cpu,
> > > but
> > > e.g. the ones in free_*) ?
> > 
> > Why not for pick_cpu()?  It's the same basic logic -- in
> > production, if
> > it *is* NULL, then you'll either crash with a segfault, or start
> > executing an exploit.  Much better to BUG_ON().
> 
> pick_cpu is called rather often, so maybe we should avoid additional
> tests.
> 
+1

> Hmm, thinking more about it: why don't we just drop those
> ASSERT/BUG_ON
> for mandatory functions and test them when doing the global_init()
> loop
> over all schedulers. We could just reject schedulers with missing
> functions.
> 
+10

:-D

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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