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=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 CB5E7C64E8A for ; Mon, 30 Nov 2020 12:01:37 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 404A8206CA for ; Mon, 30 Nov 2020 12:01:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wAUFsvkm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 404A8206CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Owner; bh=BXBUs2LZ5mpaeMZxiJs2n39gBAfTNU8RFv4NP/E+QsE=; b=wAUFsvkm+pcFAiQW/fDIAjxhxW w/Jll0JTtFVhDzhRkchDO/KabkrsiGdIQzg/kVCYdXdMS01n8yU0vRYtnh0IZJyrEtfT+e9D0+8CW yhWVbsbfuaUjbEkjlRcVeqqLzutso+0ZG3m8UDfj/9rpVBgKHbJmc4j/IuGY/y/GtCY7TPt8v6h/s pcjtN0Atp8LDnr2pxpLZyct4XeCFoFfPnkvyZt7JVtOGmJszWkrS0AFZR5lEy9pXg64cn+09Tc952 mfKZo7Ugw3X5m+r9wEFT2GwGE8VHvClm3Th5cYhxdmXC+4jXQZvkLCy25WldX5V0Z2s4bEioibWmd udeDKhsg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjhqa-0008W1-8z; Mon, 30 Nov 2020 12:00:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjhqX-0008V3-Q6 for linux-arm-kernel@lists.infradead.org; Mon, 30 Nov 2020 11:59:58 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EACF730E; Mon, 30 Nov 2020 03:59:56 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B4C283F66B; Mon, 30 Nov 2020 03:59:55 -0800 (PST) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org, will@kernel.org Subject: [PATCHv2 00/11] arm64: entry lockdep/rcu/tracing fixes Date: Mon, 30 Nov 2020 11:59:39 +0000 Message-Id: <20201130115950.22492-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.11.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201130_065957_994508_B01909AB X-CRM114-Status: GOOD ( 18.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, elver@google.com, paulmck@kernel.org, peterz@infradead.org, catalin.marinas@arm.com, james.morse@arm.com, dvyukov@google.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, [series changelog at the end] Dmitry and Marco both reported some weirdness with lockdep on arm64 erroneously reporting the hardware IRQ state, and inexplicable RCU stalls: https://lore.kernel.org/r/CACT4Y+aAzoJ48Mh1wNYD17pJqyEcDnrxGfApir=-j171TnQXhw@mail.gmail.com https://lore.kernel.org/r/20201119193819.GA2601289@elver.google.com Having investigated, I believe that this is largely down to the arm64 entry code not correctly managing RCU, lockdep, irq flag tracing, and context tracking. This series attempts to fix those cases, and I've Cc'd folk from the previous threads as a heads-up. Today, the arm64 entry code: * Doesn't correctly save/restore the lockdep/tracing view of the HW IRQ state, leaving this inconsistent. * Doesn't correctly wake/sleep RCU arounds its use (e.g. by the IRQ tracing functions). * Calls the context tracking functions (which wake and sleep RCU) at the wrong point w.r.t. lockdep, tracing. Fixing all this requires reworking the entry/exit sequences along the lines of the generic/x86 entry code. Moving arm64 over to the generic entry code requires signficant changes to both arm64 and the generic code, so for now I've added arm64-specific helpers to achieve the same thing. There's a lot of cleanup we could do here as a follow-up, but for now I've tried to do the bare minimum to make things work as expected without making it unmaintainable. The patches are based on v5.10-rc3, and I've pushed them out to my arm64/entry-fixes branch on kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/entry-fixes Marco was able to test a WIP version of this, which seemed to address the issues he was seeing. Since then I've had to alter the debug exception handling, but I'm not expecting problems there. In future we'll want to make more changes to the debug cases to align with x86, handling single-step, watchpoints, and breakpoints as NMIs, but this will require significant refactoring of the way we handle BRKs. For now I don't believe that there's a major problem in practice with the approach taken in this series. This version (v2) has seen basic build and boot testing; v1 saw a several day soak under Syzkaller, where all the reports looked sound and no reports appeared to be an unintended consequences of this series. While investigating this Peter and I spotted a latent issue in the core idle code, for which Peter has a patch now merged in v5.10-rc6: https://lore.kernel.org/r/20201120114925.594122626@infradead.org ... which the second patch in this series refers to. Since v1 [1] * Fix trivial SDEI build failure * Fix typos * Remove TODO comments * Add comments for alignment with common entry code [1] https://lore.kernel.org/r/20201126123602.23454-1-mark.rutland@arm.com Thanks, Mark. Mark Rutland (11): arm64: syscall: exit userspace before unmasking exceptions arm64: mark idle code as noinstr arm64: entry: mark entry code as noinstr arm64: entry: move enter_from_user_mode to entry-common.c arm64: entry: prepare ret_to_user for function call arm64: entry: move el1 irq/nmi logic to C arm64: entry: fix non-NMI user<->kernel transitions arm64: ptrace: prepare for EL1 irq/rcu tracking arm64: entry: fix non-NMI kernel<->kernel transitions arm64: entry: fix NMI {user,kernel}->kernel transitions arm64: entry: fix EL1 debug transitions arch/arm64/include/asm/daifflags.h | 3 + arch/arm64/include/asm/exception.h | 5 + arch/arm64/include/asm/ptrace.h | 4 + arch/arm64/kernel/entry-common.c | 254 +++++++++++++++++++++++++++---------- arch/arm64/kernel/entry.S | 78 ++++-------- arch/arm64/kernel/irq.c | 15 --- arch/arm64/kernel/process.c | 8 +- arch/arm64/kernel/sdei.c | 7 +- arch/arm64/kernel/syscall.c | 1 - arch/arm64/kernel/traps.c | 22 ++-- arch/arm64/mm/fault.c | 25 ---- 11 files changed, 242 insertions(+), 180 deletions(-) -- 2.11.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel