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 S932162AbbLNJ2o (ORCPT <rfc822;w@1wt.eu>);
	Mon, 14 Dec 2015 04:28:44 -0500
Received: from mail-wm0-f46.google.com ([74.125.82.46]:36514 "EHLO
	mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932065AbbLNJ2m (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 14 Dec 2015 04:28:42 -0500
Date: Mon, 14 Dec 2015 10:28:38 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Jeff Merkey <linux.mdb@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        Steven Rostedt <rostedt@goodmis.org>, Borislav Petkov <bp@alien8.de>,
        Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is
 registeredy
Message-ID: <20151214092837.GA30347@gmail.com>
References: <CAO6TR8W1ViJonskb0eObG+THObpabh909ob0Oz_8LAvNMuOPmA@mail.gmail.com>
 <alpine.DEB.2.11.1512101942470.3623@nanos>
 <CALCETrUaWxqyuyE2FqCs0ULPBdKMwCPtaoneyt4yBA8r5a5=yQ@mail.gmail.com>
 <alpine.DEB.2.11.1512102050290.3623@nanos>
 <CALCETrVeb9X+Z=kiA7zTQGjfdcwfE13-VtyJ1sPqdkwEV3k0oQ@mail.gmail.com>
 <CAO6TR8WwF9XDvGykyZX+qT8LDJEi-QN7t-LTPF0N_qPVeM1Puw@mail.gmail.com>
 <20151214080914.GA20556@gmail.com>
 <CAO6TR8WhN7E13xH55+WjXrpv1G8+kUvUfpJAk5=8hs3DCFQOYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAO6TR8WhN7E13xH55+WjXrpv1G8+kUvUfpJAk5=8hs3DCFQOYA@mail.gmail.com>
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


* Jeff Merkey <linux.mdb@gmail.com> wrote:

> On 12/14/15, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing in e-mail?
> >
> > * Jeff Merkey <linux.mdb@gmail.com> wrote:
> >
> >> I trigger it by writing to the dr7 and dr1, 2, 3 or four register and set an 
> >> execute breakpoint without going through arch_install_hw_breakpoint.  When 
> >> the breakpoint fires, the system crashes and hangs on the processor stuck in 
> >> an endless loop inside the int1 handler in hw_breakpoint.c --
> >
> > What is still not clear to me, can you trigger the hang not via some special
> >
> > kernel driver that goes outside regular APIs and messes with the state of the 
> > debug registers, but via the proper access methods, i.e. various user-space 
> > ABIs?
> 
> Any process that can get access to the debug registers can trigger this 
> condition. [...]

A process on an unmodified Linux kernel can only modify debug registers via the 
proper APIs:

> [...]  As it stands, if restricted to the established API in hw_breakpoint.c 
> this bug should not occur unless someone triggers an errant breakpoint. [...]

So am I interpreting your report correctly:

  "If the Linux kernel is modified to change debug registers without using the
   proper APIs (such as loading a module that changes hardware registers in a raw 
   fashion), things may break and a difficult to debug hang may occur."

right?

This key piece of information should have been part of the original report.

So I'm wondering, why does your module modify debug registers in a raw fashion? 
Why doesn't it use the proper APIs?

Thanks,

	Ingo