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 163F3C7618E for ; Mon, 24 Apr 2023 23:41:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231351AbjDXXlt (ORCPT ); Mon, 24 Apr 2023 19:41:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229929AbjDXXls (ORCPT ); Mon, 24 Apr 2023 19:41:48 -0400 Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C89E49E5 for ; Mon, 24 Apr 2023 16:41:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 135F3320055E; Mon, 24 Apr 2023 19:41:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 24 Apr 2023 19:41:42 -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=1682379701; x=1682466101; bh=dCyWMvalF1lUY +nNZYFmVolMCxSvlbqSuQGYDIYnMAc=; b=V1zLzkUt1YesV0VryziHhBc+Fw7Nd knXO482zQvBJaewiucIaYKUBEjcT4H6HudopLK5Y3aVZxTTbQ8SiGiBPwHsPAxmE 96U56bNE0JIWP8aCBHq+9puTSv7AsTKSE7jidYY0WwpcJAXHHZdTE8ybvTxpV/IR 9aR79MmjE/OYcSP/wLkxARTarOq3LIeEZMpWI0qmd18aLYVq4u4LIk0Fhd6B+vR/ Uvd8ZloH0x9O8fsaijm5dmXrD+QBIOKzEWOfwtQlXTcUY3R8tsUd7n/vUhnXf8Z5 bITzjQMSDfNsGTZAxmGLGEmhrU5QcrctRUcfIGzZyUJkQRlToeiVicHzw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeduuddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevufgjkfhfgggtsehttdertddttddvnecuhfhrohhmpefhihhnnhcu vfhhrghinhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrg htthgvrhhnpeelueehleehkefgueevtdevteejkefhffekfeffffdtgfejveekgeefvdeu heeuleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hfthhhrghinheslhhinhhugidqmheikehkrdhorhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Apr 2023 19:41:39 -0400 (EDT) Date: Tue, 25 Apr 2023 09:44:46 +1000 (AEST) From: Finn Thain To: Michael Schmitz cc: debian-68k@lists.debian.org, linux-m68k@lists.linux-m68k.org Subject: Re: reliable reproducer, was Re: core dump analysis In-Reply-To: Message-ID: <20f672ca-6fa7-a38b-e962-8c8eaddbd0c3@linux-m68k.org> References: <4a9c1d0d-07aa-792e-921f-237d5a30fc44.ref@yahoo.com> <71af7b52-a1d4-581c-d5af-afce6991c48d@gmail.com> <7ea095ba-7df1-1ffe-e87d-12d46ebe72f6@gmail.com> <2fdc2819-526a-756f-19d0-ac1147f85b63@linux-m68k.org> <868b5214-fa13-dcf7-a671-9843169eea06@gmail.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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org On Mon, 24 Apr 2023, Michael Schmitz wrote: > > I don't understand these results. If usp was really overwritten, the > > program would have crashed early, no? > > I think we're still at the point where rec() is called recursively, > before any returns. Right. I wasn't thinking. I'll try to confirm that each "overwrote usp" error from movemlrt.c corresponds to visible corruption at the given address in the core dump. > >> Exception right before crash was an interrupt in this case (only seen > >> that once in this context, though I've seen lots of those in the > >> course of the test runs). Frame start calculated from siginfo pointer > >> value in this case. > > > > I didn't realize that you could get a crash from a signal delivered > > following an interrupt. I'll try to modify the kernel such that > > signals are not delivered after page faults. > > Yes, that was news to me, too. > That seems to be a mistake (?) I didn't see any failures when I patched the kernel to skip signal delivery after a page fault.