Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4915970ybi; Sat, 6 Jul 2019 16:55:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqynm2K/q3vJHtYVLuddL504Zou4wsn2ckdqJ8BNvdRwMGMJKBh3pP9zgOuwnYLtLcz+Qg1O X-Received: by 2002:a63:fc52:: with SMTP id r18mr13241193pgk.378.1562457328424; Sat, 06 Jul 2019 16:55:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562457328; cv=none; d=google.com; s=arc-20160816; b=e56MKb78/e6ONq2SntJylowN2fMB8bvFiObgPhBC8zohO5Bo4hGt8TUTKuNBaKDi5K i0LQXieGu5s62kgLxffeZbnLnGbUzvEvd5SLcjj8BQpxZzijpbJIAmXRJlD0qaGQPOqs R0tZr8/KxvhP4k3t4F3S9BaJczJ0b++ieC0LEV/FZrJ6qR8y3L9GEtGX3MfteRXJpGII tOOXLhPNg6SLx3G2bTCAwXKkFy5qllMKXeZXuGVDMEMa2OT16ZoDSYV/S2IpoCJJeurL dulT8vBWD1rbGbVv8Y0+h3CYIVbwfCOVu16qOQZxYaliyIDynE1GnzBUknyJYlmyJlrs WEkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=F+KdBOzutVLsRQva6IwzXnEFNo/vJot9eQJdzajEKl0=; b=s3uBOIIUoc0qOOJW5pdx1m1HGn0QamRdXFBzngXC+BSeDW+XTHZBY0tvS6Xzbf+wOP Q82gIWk4CDP1OnnpXWbHzz1urhbH2Pp/qkMglVMsjVoDjZUqXwKDYUHmoAaU8iI7Q9Q3 Z2Jy6z7CCNMPmXHqY1KLRWAfl1gD7OStHCwt1p6SD6Ly+myg8J/JN0rxd6NSmmEwSX/g GbZG9MLlXbrZ2ZXs1YjTXQDwYLTGB6RbpIhJ1Eh27ZF4lOd/uSCfzjTMOAAz/A3I3Gx8 MbEWWi4pD+vQ4zEMHFEbTp2rwzR7qNLV94nB8f0By7eWsbIrpN9fbtndx6NmR+dy3wCl sDyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uB8mhOaw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r190si14447362pfr.102.2019.07.06.16.54.47; Sat, 06 Jul 2019 16:55:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uB8mhOaw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726969AbfGFXum (ORCPT + 99 others); Sat, 6 Jul 2019 19:50:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:42120 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726469AbfGFXum (ORCPT ); Sat, 6 Jul 2019 19:50:42 -0400 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEC022089C for ; Sat, 6 Jul 2019 23:50:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562457041; bh=AK8MgET1vrfHE69i8xCIsTkO4CaO+eooMrT7GkGRfGc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uB8mhOawdEGj0VVxb4LMPtx5LHx9vLECFUYEox/FkrIxQ9Sqh7wbFO5hd8pzUoiQR heR5E0wKqs2TN4jaxv9nYFJGRn0PZwgwZzbKpZfY3TjZ9IPNe2n2iMm+e5xWbPtMmf EVfSa6/FWjHbxJhG2NKZ5ByHkg5be5JCf07ijjSo= Received: by mail-wm1-f43.google.com with SMTP id l2so5695193wmg.0 for ; Sat, 06 Jul 2019 16:50:40 -0700 (PDT) X-Gm-Message-State: APjAAAUpKkjHPECSH2FPRKZhU7nJYmaNQJLnHmrzB9TWOPVYX9MgK0d7 vVEjpP1YMxEQpN4cZiDTpFCWNMT7OjVJHuq6Zph/SQ== X-Received: by 2002:a7b:c4d2:: with SMTP id g18mr5341761wmk.79.1562457039466; Sat, 06 Jul 2019 16:50:39 -0700 (PDT) MIME-Version: 1.0 References: <20190704195555.580363209@infradead.org> <20190704200050.534802824@infradead.org> <20190705134916.GU3402@hirez.programming.kicks-ass.net> <20190706182728.435a89ed@gandalf.local.home> In-Reply-To: <20190706182728.435a89ed@gandalf.local.home> From: Andy Lutomirski Date: Sat, 6 Jul 2019 16:50:27 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption To: Steven Rostedt Cc: Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Borislav Petkov , Ingo Molnar , Andrew Lutomirski , Peter Anvin , Dave Hansen , Juergen Gross , Linux List Kernel Mailing , He Zhe , Joel Fernandes , devel@etsukata.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 6, 2019 at 3:27 PM Steven Rostedt wrote: > > On Sat, 6 Jul 2019 14:41:22 -0700 > Linus Torvalds wrote: > > > On Fri, Jul 5, 2019 at 6:50 AM Peter Zijlstra wrote: > > > > > > Also; all previous attempts at fixing this have been about pushing the > > > read_cr2() earlier; notably: > > > > > > 0ac09f9f8cd1 ("x86, trace: Fix CR2 corruption when tracing page faults") > > > d4078e232267 ("x86, trace: Further robustify CR2 handling vs tracing") > > > > I think both of those are because people - again - felt like tracing > > can validly corrupt CPU state, and then they fix up the symptoms > > rather than the cause. > > > > Which I disagree with. > > > > > And I'm thinking that with exception of this patch, the rest are > > > worthwhile cleanups regardless. > > > > I don't have any issues with the patches themselves, I agree that they > > are probably good on their own. > > > > I *do* have issues with the "tracing can change CPU state so we need > > to deal with it" model, though. I think that mode of thinking is > > wrong. I don't believe tracing should ever change core CPU state and > > that be considered ok. > > > > > Also; while looking at this, if we do continue with the C wrappers from > > > the very last patch, we can do horrible things like this on top and move > > > the read_cr2() back into C code. > > > > Again, I don't think that is the problem. I think it's a much more > > fundamental problem in thinking that core code should be changed > > because tracing is broken garbage and didn't do things right. > > > > I see Eiichi's patch, and it makes me go "that looks better" - simply > > because it fixes the fundamental issue, rather than working around the > > symptoms. > > > > We also have to deal with reading vmalloc'd data as that can fault too. > The perf ring buffer IIUC is vmalloc, so if perf records in one of > these locations, then the reading of the vmalloc area has a potential > to fault corrupting the CR2 register as well. Or have we changed > vmalloc to no longer fault? > What context is that happening in? If the tracepoint-saves-CR2 patch is in, then it should be fine if it nests inside of tracing, right? And NMI needs to save and restore CR2 no matter what, since it can happen before we can possibly save CR2. For that matter, MCE should save and restore CR2 as well. All that being said, I do like the idea of moving all this crud (IRQ tracing, CR2 handling, and context tracking) into C. I haven't had time to review that part of Peter's series yet, but I should get to it soon.