linux-kernel - Re: [PATCH 2/2] pm_qos: make update_request callable from interrupt context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100609184850.2779b784@schatten.dmk.lab>
Date:	Wed, 9 Jun 2010 18:48:50 +0200
From:	Florian Mickler <florian@...kler.org>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	markgross@...gnar.org, mgross@...ux.intel.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] pm_qos: make update_request callable from interrupt
 context

On Wed, 09 Jun 2010 11:32:26 -0400
James Bottomley <James.Bottomley@...e.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/