From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1760217AbcCEJEt (ORCPT <rfc822;w@1wt.eu>);
	Sat, 5 Mar 2016 04:04:49 -0500
Received: from mail-wm0-f65.google.com ([74.125.82.65]:33448 "EHLO
	mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754342AbcCEJEi (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 5 Mar 2016 04:04:38 -0500
Date: Sat, 5 Mar 2016 10:04:33 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@amacapital.net>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Andy Lutomirski <luto@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        X86 ML <x86@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: soft lockup when passing vvar address to write(2)
Message-ID: <20160305090432.GB23473@gmail.com>
References: <87wppj4198.fsf@rasmusvillemoes.dk>
 <CALCETrX__AbsmV161tYVvVfSjeETTHoMLgpZYo+tQB+ewG8kPQ@mail.gmail.com>
 <CAKwiHFhy8_f9R0QYUJiva-uF5ZLbU4tpVGzox+52=Ud0+SSf+Q@mail.gmail.com>
 <CALCETrVLbXpqUCdsFrHD+jBx=+fUb6=00j=-_v22VPdYEY-aTg@mail.gmail.com>
 <alpine.DEB.2.11.1603050927430.3686@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1603050927430.3686@nanos>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Fri, 4 Mar 2016, Andy Lutomirski wrote:
> > Thomas, I still think we should consider just deleting the HPET vclock
> > code and accept the syscall overhead on systems that are stuck using
> > HPET.  If fast syscalls are available (which should include every
> > system with HPET, unless there are some 32-bit AMD systems lying
> > around), then the overhead in a syscall is *tiny* compared to the code
> > of the HPET read itself.
> 
> No objection from my side, really.

Seconded. HPET hardware overhead is typically horrifically large in any case, no 
need to memory map it and expose hardware breakages to user-space ...

It's also a (mild) security hole: a well-known HPET address can be abused as a 
statistical trampoline periodically cycling through 'dangerous' instruction 
values.

Thanks,

	Ingo