Re: [PATCH 2/2] pm_qos: make update_request callable from interruptcontext

[Florian Mickler]

On Wed, 09 Jun 2010 11:32:26 -0400
James Bottomley <James.Bottomley@xxxxxxx> wrote:
 
> > > @@ -302,8 +330,12 @@ int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier)
> > >  {
> > >  	int retval;
> > >  
> > > +	/* someone tried to register a blocking notifier to a
> > > +	 * qos object that only supports atomic ones */
> > > +	BUG_ON(!pm_qos_array[pm_qos_class]->blocking_notifiers);
> > > +
> > >  	retval = blocking_notifier_chain_register(
> > > -			pm_qos_array[pm_qos_class]->notifiers, notifier);
> > > +			pm_qos_array[pm_qos_class]->blocking_notifiers, notifier);
> > >  
> > >  	return retval;
> > >  }
> > 
> > Why not:
> > 
> > 	retval = 1;
> > 	if(pm_qos_array[pm_qos_class]->blocking_notifiers) 
> > 		retval = blocking_notifier_chain_register(..
> > 	else 
> > 		WARN();
> > 	return retval;
> > 
> > That way, the offending programmer could eventually fix it, without
> > having to reboot? 
> 
> Because there are no current users that will trip the BUG_ON ... and we
> want to keep it that way.  Code doesn't go into the kernel if it BUGs on
> boot.
> 
> The point about failing hard for an abuse of a kernel API isn't to trap
> current abusers because you fix those before you add it.  It's to
> prevent future abuse.  If your kernel BUGs under test you tend to fix
> the code, so it becomes impossible for anyone to add any users which
> abuse the API in this fashion.
> 
> James
> 

There are actually people who ignore WARN()ings when submitting code??

....thinking about it... Yes, that may be possible. 

Cheers,
Flo

--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former. Albert Einstein 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/