linux-kernel - Re: [RFC][PATCH v2] timekeeping: Cap adjustments so they don't exceed the maxadj value

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: <20151214123958.GB21828@localhost>
Date:	Mon, 14 Dec 2015 13:39:58 +0100
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Cochran <richardcochran@...il.com>,
	Prarit Bhargava <prarit@...hat.com>,
	Andy Lutomirski <luto@...nel.org>
Subject: Re: [RFC][PATCH v2] timekeeping: Cap adjustments so they don't
 exceed the maxadj value

On Thu, Dec 10, 2015 at 11:54:01AM -0800, John Stultz wrote:
> Thus its been occasionally noted that users have seen
> confusing warnings like:
> 
>     Adjusting tsc more than 11% (5941981 vs 7759439)

> @@ -1612,13 +1615,32 @@ static __always_inline void timekeeping_freqadjust(struct timekeeper *tk,
>  	/* preserve the direction of correction */
>  	negative = (tick_error < 0);
>  
> -	/* Sort out the magnitude of the correction */
> +	/* If any adjustment would pass the max, just return */
> +	if (negative && (cur_adj - 1) < (base - max))
> +		return;
> +	if (!negative && (cur_adj + 1) > (base + max))
> +		return;

I ran the test that triggered the warning previously and it was silent
now.

But it looks like timekeeping_adjust() should check the adjustment too
before calling timekeeping_apply_adjustment(). In linux-tktest I was
able to find a configuration (-t 10 -n 150 -p 10000000) that triggered
the warning again. I'm not sure how likely it is to happen in real
world and if it's worth fixing though.

To avoid adding even more code, maybe the check could be moved to
timekeeping_apply_adjustment()? It would try decreasing adj_scale
until the check passes. When it reached -1, the function would return
immediately with no adjustment of the multiplier.

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