linux-kernel - Re: [PATCH V3 2/3] tick/cpuidle: Initialize hrtimer mode of broadcast

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]

Date:	Thu, 6 Feb 2014 21:52:35 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
cc:	deepthi@...ux.vnet.ibm.com, daniel.lezcano@...aro.org,
	linux-pm@...r.kernel.org, peterz@...radead.org, fweisbec@...il.com,
	rafael.j.wysocki@...el.com, linux-kernel@...r.kernel.org,
	paulus@...ba.org, srivatsa.bhat@...ux.vnet.ibm.com,
	paulmck@...ux.vnet.ibm.com, linuxppc-dev@...ts.ozlabs.org,
	mingo@...nel.org
Subject: Re: [PATCH V3 2/3] tick/cpuidle: Initialize hrtimer mode of
 broadcast

On Thu, 6 Feb 2014, Preeti U Murthy wrote:
> On 02/06/2014 09:33 PM, Thomas Gleixner wrote:
> > On Thu, 6 Feb 2014, Preeti U Murthy wrote:
> > 
> > Compiler warnings are not so important, right?
> > 
> > kernel/time/tick-broadcast.c: In function ‘tick_broadcast_oneshot_control’:
> > kernel/time/tick-broadcast.c:700:3: warning: ‘return’ with no value, in function returning non-void [-Wreturn-type]
> > kernel/time/tick-broadcast.c:711:3: warning: ‘return’ with no value, in function returning non-void [-Wreturn-type]
> 
> My apologies for this, will make sure this will not repeat. On compilation I
> did not receive any warnings with the additional compile time flags too.I
> compiled it on powerpc. Let me look into why the warnings did not show up.
> Nevertheless I should have taken care of this even by simply looking at the
> code.

Huch, PPC seems to have an extra stupid version of gcc :)
 
> The cpuidle patch then is below. The trace_cpu_idle_rcuidle() functions have
> been moved around so that the broadcast CPU does not trace any idle event
> and that the symmetry between the trace functions and the call to the
> broadcast framework is  maintained. Wow, it does become very simple :)

Indeed :)

Care to resend the whole lot with all fixes applied and perhaps
compile tested on x86 :)
 
Thanks,

	tglx