From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2631C4363A for ; Tue, 27 Oct 2020 09:09:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 52B6220747 for ; Tue, 27 Oct 2020 09:09:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="BtzrIzj6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2895376AbgJ0JJH (ORCPT ); Tue, 27 Oct 2020 05:09:07 -0400 Received: from casper.infradead.org ([90.155.50.34]:35278 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2408760AbgJ0JJG (ORCPT ); Tue, 27 Oct 2020 05:09:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XQcCXngkhvG5SpWi+kmrjq+Hhq+RSDL5FOHryXsDGRM=; b=BtzrIzj6HwyZBDTEHNbg3zdDyU JLC06krkKQ4LJZtobhd+/TZUhariuccXrET0dFg4VKRG9V6A1Z00tSI5eyzzwXVWn3PSfwI64V9JI VU4YLYTS9bxwhpD7pTTZJbj6vTphMoY8Six3XpFxxs50egZeQWlF5xBlsBEnxhW6wjWW6I8Nd3O17 xTtHn0ZtnKKzqAIAa2WHaQGrtSLJcx1KEQX5f1jFAYNcTUKFOvsm14QtEgzX6e+81MNRD6jDpOl4Z MZs95OTghCbeHh+cANiPjHMXAjMyAteOzf1kmhsX/RftV8uDKOJLuRt1AmUMCJ/eeKOHrdUMfcKSw E/pcTLAw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXKxo-0004Zb-SK; Tue, 27 Oct 2020 09:08:23 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id B2B6D301179; Tue, 27 Oct 2020 10:08:14 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A58692141F77E; Tue, 27 Oct 2020 10:08:14 +0100 (CET) Date: Tue, 27 Oct 2020 10:08:14 +0100 From: Peter Zijlstra To: Andy Lutomirski Cc: Kyle Huey , open list , Thomas Gleixner , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Linus Torvalds , Robert O'Callahan , Alexandre Chartre , "Paul E. McKenney" , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Joel Fernandes , Steven Rostedt , Boris Ostrovsky , Juergen Gross , Brian Gerst , Josh Poimboeuf , Daniel Thompson Subject: Re: [REGRESSION] x86/debug: After PTRACE_SINGLESTEP DR_STEP is no longer reported in dr6 Message-ID: <20201027090814.GJ2628@hirez.programming.kicks-ass.net> References: <20201026155521.GQ2594@hirez.programming.kicks-ass.net> <20201026160513.GC2651@hirez.programming.kicks-ass.net> <20201026163100.GR2594@hirez.programming.kicks-ass.net> <20201026165519.GD2651@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 26, 2020 at 04:30:32PM -0700, Andy Lutomirski wrote: > Is there any compelling reason not to just drop the condition and do: > > current->thread.virtual_dr6 |= (dr6 & DR_STEP); > > unconditionally? Because why should it? > This DR6 cause, along with ICEBP, have the > regrettable distinctions of being the only causes that a user program > can trigger all on its own without informing the kernel first. This > means that we can't fully separate the concept of "user mode is > single-stepping itself" from "ptrace or something else is causing the > kernel to single step a program." TIF_SINGLESTEP does that. If the kernel is single-stepping userspace it has TIF_SINGLESTEP (and possibly TIF_FORCED_TF) to distinguish these cases. > I bet that, without making this tweak, the virtual_dr6 change will > regress some horrific Wine use case. Then we should make sure the Wine people are aware and test this. Do you know who to poke? If there are regressions, we'll fix them, but I'd prefer to not create a mess just because. This whole #DB thing was a giant trainwreck, we'll obviously have to be bug compatible, but only when people actually notice.