Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751183AbcCFC7a (ORCPT ); Sat, 5 Mar 2016 21:59:30 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:35654 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbcCFC72 (ORCPT ); Sat, 5 Mar 2016 21:59:28 -0500 MIME-Version: 1.0 In-Reply-To: <20160305090432.GB23473@gmail.com> References: <87wppj4198.fsf@rasmusvillemoes.dk> <20160305090432.GB23473@gmail.com> From: Andy Lutomirski Date: Sat, 5 Mar 2016 18:59:07 -0800 Message-ID: Subject: Re: soft lockup when passing vvar address to write(2) To: Ingo Molnar Cc: Rasmus Villemoes , Thomas Gleixner , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 34 On Mar 5, 2016 1:04 AM, "Ingo Molnar" wrote: > > > * Thomas Gleixner 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 ... I'll do it for 4.7. > > 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. That weakness has closed for quite a while -- it's mapped NX and it's randomized. I'm also not planning to revert the mapping security improvement -- even if we remove the HPET code, it still applies to kvmclock and to anything else that gets added in the future. It's also very little code. --Andy