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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFDDAC77B61 for ; Wed, 26 Apr 2023 01:59:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238411AbjDZB70 (ORCPT ); Tue, 25 Apr 2023 21:59:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239218AbjDZB7V (ORCPT ); Tue, 25 Apr 2023 21:59:21 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3D0717DFE for ; Tue, 25 Apr 2023 18:59:20 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2B1E05C0185; Tue, 25 Apr 2023 21:59:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 25 Apr 2023 21:59:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1682474360; x=1682560760; bh=CKFv2zbZHNGSS QItixtf3/h8sPV025PAhbek9mNixrQ=; b=UtpNpJrnQo3Qs+1n9dJPJeONb7zsC /pmsKo2KpKsiGu/tm1C7TNtmxzaweqSv9uitla75B+KuYxysAsR9jCP7ST2QjjHt u+4577EyTAh80iZqsnuYO1EeBNjMXlJ8+vFlRAoKboJukaQgToHgZ8q8XZpFRTHx iTytIUjjXDtRL16EQVhtGfaWtAnrBze5hUQEKUr8er4yrM9oqnwT5JB8UboCQlE3 DKGji0dXoqhPYtYtnMGfDYq7Y5pU8b7JMbxdgLZAi8RR4WjtwQWcFpLZlXwaFNRb nO4fBPYm11FXxuJEkDQgYqj2p4z6s9qPYZrAt3bRJtrnLkpadtilrB/BQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedufedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevufgjkfhfgggtsehttdertddttddvnecuhfhrohhmpefhihhnnhcu vfhhrghinhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrg htthgvrhhnpeelueehleehkefgueevtdevteejkefhffekfeffffdtgfejveekgeefvdeu heeuleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hfthhhrghinheslhhinhhugidqmheikehkrdhorhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Apr 2023 21:59:17 -0400 (EDT) Date: Wed, 26 Apr 2023 12:02:56 +1000 (AEST) From: Finn Thain To: Michael Schmitz cc: Andreas Schwab , debian-68k@lists.debian.org, linux-m68k@lists.linux-m68k.org Subject: Re: signal delivery, was Re: reliable reproducer In-Reply-To: Message-ID: References: <4a9c1d0d-07aa-792e-921f-237d5a30fc44.ref@yahoo.com> <87fs8sz6e9.fsf@igel.home> <878rekz0md.fsf@igel.home> <87o7nfyd7e.fsf@igel.home> <87jzy3y79y.fsf@igel.home> <5824d97d-683b-a354-3c39-cb0f54e50bc0@gmail.com> <06c14a4a-1679-31d6-0501-97e20741f88a@gmail.com> <13d36a79-5aae-d63c-5014-5503688f07bb@linux-m68k.org> <1d9955d2-6016-a238-142a-887f95465dd8@linux-m68k.org> <4763c8e2-6fb3-eda6-10d0-94ed1d01cd60@gmail.com> <1fcaa695-5c2d-0c76-444d-6d6be0105f6e@linux-m68k.org> <87y1mgryp1.fsf@igel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org On Wed, 26 Apr 2023, Michael Schmitz wrote: > Thanks - we had seen evidence that a bus error generated mid-instruction > did leave the USP at the address where the bus fault happened (not > before the instruction started, neither what it would have been once the > instruction completed), and the operation did not complete normally > after the bus error (at least the value/address seen in the exception > frame not stored). I'm afraid I still don't fully understand how and why the user stack (rather than the supervisor stack) gets used for processing the exception frame. > Finn had also demonstrated that skipping signal delivery on bus errors > abolishes the stack corruption. Your patch achieves the same objective > in a different way, so I'm sure this will work as well. > > I had thought the 030 could resume the interrupted instruction using the > information from the exception frame - and that does appear to work in > all other cases except where signal delivery gets in the way, and it > also works if moving the exception frame a little bit further down the > stack. So our treatment of the bus error exception frame during signal > delivery appears to be incorrect. Wouldn't that depend on the exception frame format? Perhaps it is unsafe to treat any format 0xB exception frame in the way we do. If so, what do we do about address error exceptions, which are to produce SIGBUS? The Programmers Reference Manual says "a long bus fault stack frame may be generated" in this case.