• Andy Lutomirski's avatar
    x86/vdso: Remove direct HPET access through the vDSO · 1ed95e52
    Andy Lutomirski authored
    Allowing user code to map the HPET is problematic.  HPET
    implementations are notoriously buggy, and there are probably many
    machines on which even MMIO reads from bogus HPET addresses are
    problematic.
    
    We have a report that the Dell Precision M2800 with:
    
      ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL   CBX3  01072009 AMI. 00000005)
    
    is either so slow when accessing the HPET or actually hangs in some
    regard, causing soft lockups to be reported if users do unexpected
    things to the HPET.
    
    The vclock HPET code has also always been a questionable speedup.
    Accessing an HPET is exceedingly slow (on the order of several
    microseconds), so the added overhead in requiring a syscall to read
    the HPET is a small fraction of the total code of accessing it.
    
    To avoid future problems, let's just delete the code entirely.
    
    In the long run, this could actually be a speedup.  Waiman Long as a
    patch to optimize the case where multiple CPUs contend for the HPET,
    but that won't help unless all the accesses are mediated by the
    kernel.
    Reported-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
    Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Acked-by: default avatarBorislav Petkov <bp@alien8.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Waiman Long <Waiman.Long@hpe.com>
    Cc: Waiman Long <waiman.long@hpe.com>
    Link: http://lkml.kernel.org/r/d2f90bba98db9905041cff294646d290d378f67a.1460074438.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    1ed95e52
trace.h 31.1 KB