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: <20170926125206.63l6jlp76dhfu7um@hirez.programming.kicks-ass.net>
Date:   Tue, 26 Sep 2017 14:52:06 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Anna-Maria Gleixner <anna-maria@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Christoph Hellwig <hch@....org>, keescook@...omium.org,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 18/25] hrtimer: Enable soft and hard hrtimer

On Thu, Aug 31, 2017 at 12:23:42PM -0000, Anna-Maria Gleixner wrote:
> --- a/include/linux/hrtimer.h
> +++ b/include/linux/hrtimer.h
> @@ -23,6 +23,17 @@
>  #include <linux/timer.h>
>  #include <linux/timerqueue.h>
>  
> +/*
> + * Clock ids for hrtimers which expire in softirq context. These clock ids
> + * are kernel internal and never exported to user space.
> + */
> +#define HRTIMER_BASE_SOFT_MASK	MAX_CLOCKS
> +
> +#define CLOCK_REALTIME_SOFT	(CLOCK_REALTIME	 | HRTIMER_BASE_SOFT_MASK)
> +#define CLOCK_MONOTONIC_SOFT	(CLOCK_MONOTONIC | HRTIMER_BASE_SOFT_MASK)
> +#define CLOCK_BOOTTIME_SOFT	(CLOCK_BOOTTIME	 | HRTIMER_BASE_SOFT_MASK)
> +#define CLOCK_TAI_SOFT		(CLOCK_TAI	 | HRTIMER_BASE_SOFT_MASK)
> +
>  struct hrtimer_clock_base;
>  struct hrtimer_cpu_base;
>  

> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -1173,7 +1161,7 @@ u64 hrtimer_get_next_event(void)
>  
>  static inline int hrtimer_clockid_to_base(clockid_t clock_id)
>  {
> +	if (likely(clock_id < MAX_CLOCKS_HRT)) {
>  		int base = hrtimer_clock_to_base_table[clock_id];
>  
>  		if (likely(base != HRTIMER_MAX_CLOCK_BASES))
> @@ -1193,8 +1181,12 @@ static void __hrtimer_init(struct hrtime
>  
>  	cpu_base = raw_cpu_ptr(&hrtimer_bases);
>  
> +	if (mode != HRTIMER_MODE_ABS) {
> +		if (clock_id == CLOCK_REALTIME)
> +			clock_id = CLOCK_MONOTONIC;
> +		else if (clock_id == CLOCK_REALTIME_SOFT)
> +			clock_id = CLOCK_MONOTONIC_SOFT;
> +	}
>  
>  	base = hrtimer_clockid_to_base(clock_id);
>  	timer->base = &cpu_base->clock_base[base];

So why expose these extra bases at all, why not stick another flag in
MODE? These extra bases is a pure implementation detail imo; you could
equally implement the functionality without (albeit at extra cost).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ