linux-kernel - Re: [PATCH 0/2] clockevents: Hide CLOCK_EVT_STATE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.11.1505201411500.4225@nanos>
Date:	Wed, 20 May 2015 15:09:53 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Viresh Kumar <viresh.kumar@...aro.org>
cc:	linaro-kernel@...ts.linaro.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 0/2] clockevents: Hide CLOCK_EVT_STATE_* from rest of
 the kernel

On Wed, 20 May 2015, Viresh Kumar wrote:
> Ingo suggested [1] to keep CLOCK_EVT_STATE_* symbols somewhere in
> kernel/time/. We couldn't do it as bL_switcher code was using it
> earlier. But that's fixed now. And so the first patch moves these
> symbols to tick-internal.h.
> 
> Some of the drivers [2] need to verify state of the clockevent device
> from their callbacks or interrupt handlers.

They look at clock_event_mode and not at state, right?
 
> Because these symbols (defined by 'enum clock_event_state') will now be
> internal to the core, we need some helpers to verify state of a
> clockevent device.

So how are they affected by moving clock_event_state to the core code ?
 
> One way out was to maintain the state in drivers as well, but that would
> be unnecessary burden on them. And so the second patch introduces
> helpers for these states.

And that way we add the overhead of a full function call to those
drivers for the interrupt hot path?

I just looked at the drivers and there are three classes of mode
checks and CLOCK_EVT_MODE_ usage:

1) Interrupt handler:

   Act depending on the mode:

          - disable the device in case of oneshot

	    vf_pit_timer
	    timer-atlas7
	    sh_cmt
	    sh_tmu
	    rockchip_timer
	    qcom-timer
	    fsl_ftm_timer
	    cs5535-clockevt
	    arm_global_timer
	    evt-sb1250
	    cevt-bcm1480
	    mips/jz4740
	    dc21285-timer
	    arc/time
	    alpha/time

       	  - conditionally handle the device in case of shared
            interrupt hardware with trainwreck design or other
            shortcomings of the timer hardware

	    timer-atmel-pit
	    cs5535-clockevt
	    x86/apic

2) Sensible checks:

   i8253			init_pit_timer()
   x86/i8253			init_pit_clocksource()
   cs5535_mfgpt			init_mfgpt_timer()
   avr32/time			comparator_mode()

3) Use cases which can be fixed by conversion to the seperate mode
   setters

   x86/apic			Calibration code

4) Simple to fix stuff

   nios2			nios2_timer_config()
   exynos_mct			exynos4_mct_comp0_start()
   tcb_clksrc			tc_mode()

5) Set mode from driver code:

   time-armada-370-xp		armada_370_xp_timer_stop()
   qcom-timer			msm_local_timer_stop()
   exynos_mct			exynos4_local_timer_stop()
   arm_global_timer		gt_clockevents_stop()
   arm_arch_timer		arch_timer_stop()
   smp_twd			twd_timer_stop()
   hyperv/hv			hv_synic_cleanup()

6) Random nonsense:

   xen/time			xen_timerop_set_next_event()
   				xen_vcpuop_set_next_event()
   hyper/hv			hv_ce_set_next_event()
   sh_cmt			sh_cmt_clock_event_next()
   sh_tmu			sh_tmu_clock_event_next()
   arm/mach-imx/time		mxc_set_mode()
   arm/mach-imx/apit		epit_set_mode()
   mxs_timer			mxs_set_mode()
						
That list is way more useful than a pastebin with random grep output,
which does not cover use cases which SET a mode from driver code and
does not cover local storage of modes.

Of course you should have done that analysis before posting some
random helper functions.

Lets look how useful these functions are for the various use cases

#1) Adds function call over head to the timer interrupt

    Hot path does matter and that function call is a regression. So
    that's a NONO

#2) The function call overhead does not matter much for these, but
    they could be simply fixed by using local or device storage as
    well.

#3) A non issue

#4) Trivial to fix

#5) Trivial to replace by the explicit setter functions, but we want
    to know WHY this is done in the first place

#6) Simple to remove random crappola.

    I already did the patches while analysing the code, so that will
    be gone soon.

Now explain me how your magic functions help. For most of the cases
they would be a performance regression. And for the rest they really
do not matter at all.

Brilliant stuff that.

Thanks,

	tglx








--
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/