linux-kernel - Re: [PATCH] clockevents: Retry programming min delta up to 10 times

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]

Date:	Mon, 25 Apr 2016 15:48:58 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	James Hogan <james.hogan@...tec.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clockevents: Retry programming min delta up to 10 times

On Fri, 22 Apr 2016 11:40:11 +0100
James Hogan <james.hogan@...tec.com> wrote:

> Under virtualisation it is possible to get unexpected latency during a
> clockevent device's set_next_event() callback which can make it return
> -ETIME even for a delta based on min_delta_ns.

Do you have an example for this behavior? I would call that a BUG in the
implementation of the clockevent device, no?

> The clockevents_program_min_delta() implementation for
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=n doesn't handle retries when this
> happens, nor does clockevents_program_event() or its callers when force
> is true (for example hrtimer_reprogram()). This can result in hangs
> until the clock event device does a full period.

Is that because some clockevent devices can not program the minimum delta
in some corner cases?

> It isn't appropriate to use MIN_ADJUST in this case as occasional
> hypervisor induced high latency will cause min_delta_ns to quickly
> increase to the maximum.

I agree, the whole minimum delta adjustment is quite broken on a virtualized
system. On s390 we have seen the rise of the min_delta_ns to the maximum
value due to a busy hypervisor.

> Instead, borrow the retry pattern from the MIN_ADJUST case, but without
> making adjustments. We retry up to 10 times before giving up.

That will add a few unnecessary instruction for architectures that have a
sane set_next_event function, namely those that always returns 0. Should
not be too bad though. 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.