Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4455725pxv; Tue, 27 Jul 2021 07:49:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwURXOQAW2RMzPbYn6mDnw3wbYItHPCuBFYs2t8RDN6R1V54R8F7t5LC4ivGOnrOw6tTMG0 X-Received: by 2002:aa7:da02:: with SMTP id r2mr5042134eds.249.1627397344794; Tue, 27 Jul 2021 07:49:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627397344; cv=none; d=google.com; s=arc-20160816; b=DSc4G9+sSyHQWw90fli+tb/6jYY8c6XW6HzHcdnjUh+i5ce3Fomq0RZpVtnDsvcDUY lgINP/gUqONbD5gcBc5QzbJq8tDzuDGhg2nWOC+UX1ndVKhPKtxrxuCP5mnHX2zbowoy 34OclV3LT5kn29KQFnjLQvbExo0pLd/7spyrpQyrXqtTu3RO3mPcmUbVs6xqjjXPfuEg oT9qAK2z0qZNcEh77dcgciKO99GXMqAJUKJ81mZl63vqIHKsPuYWpLmHrcIYBDWjN61e g34K31y10YJQE+s++AxWtacYEdKWHeOGpSokOdwiaHXNqFj9eEE37hz1wf3OYdkeQEN+ eiXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=pbRhVRbBTIHOZBUruvIekNMXQ1RVixhWQe0iZdApOAA=; b=gsLYqJ5pZb0OdZ1Oijc9iFBOUnRR0a2tYq5uS31h2BkMgWI4Ed2yKp2T/aBJkbnC/h Ghk4ozWah/JPdXgkZagsqeMnzaaw7z4Eet4xFi/4pwxwEqIfWAcsBpQJHXrBIrBrDOfX VwoXHe/G3qg63mIQzh1/vqv42CW6Xotw+kbEv+DthSSvuKw2kz8T47lJva7cmFY8Lu0X vty5WpF6CjI7ABQ94Jkx77wJ/4TPxcZszTNyh4p83TADf2n+egqJW8ff6lDTJNmDB7AJ K1988MeFhZ1L9hhtF1v8gpvUfN0dZl9rf74X1lONDX8zuqBCSnzi00Ud++jEHdHZ36p3 0kVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h9si3142423edt.358.2021.07.27.07.48.41; Tue, 27 Jul 2021 07:49:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232570AbhG0Oof (ORCPT + 99 others); Tue, 27 Jul 2021 10:44:35 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:57022 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232419AbhG0Oob (ORCPT ); Tue, 27 Jul 2021 10:44:31 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8OHl-004NhG-6G; Tue, 27 Jul 2021 14:42:21 +0000 Date: Tue, 27 Jul 2021 14:42:21 +0000 From: Al Viro To: Finn Thain Cc: linux-m68k@lists.linux-m68k.org, Geert Uytterhoeven , Greg Ungerer , linux-kernel@vger.kernel.org Subject: Re: [RFC][CFT] signal handling fixes Message-ID: References: <5622d120-1b89-6898-d091-8b4ceff6418@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5622d120-1b89-6898-d091-8b4ceff6418@linux-m68k.org> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 27, 2021 at 08:21:52PM +1000, Finn Thain wrote: > On Sun, 25 Jul 2021, Al Viro wrote: > > > > > The series is on top of 5.14-rc1; it lives in > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #untested.m68k > > Individual patches in followups... > > > > _Very_ lightly tested on aranym; no real hardware to test it on. > > Any help with review and testing would be very welcome. > > > > I can test this branch on a Motorola 68040 machine I have here. Can you > advise how to get decent code coverage? Maybe there's a package out there > with a signal-heavy test suite? Maybe I need a break point in a signal > handler? Or perhaps just send ^C to a process running under strace? Generally, SIGINT is not the best insertion vector... Set a handler of e.g. SIGALRM with sigaction(), with a couple of other signals in sa_mask (e.g. SIGUSR1 and SIGUSR2). With raise() on those inside the SIGALRM handler - then they will become deliverable on return from handler. And have SIGUSR1 and SIGUSR2 handlers print siginfo and ucontext contents (have them set with SA_SIGINFO in sa_flags, look at the second and third arguments of sighandler). Use alarm(2) to arrange for SIGALRM and sit in a tight loop - that'll give you delivery on return from interrupt. Alternatively, raise(SIGALRM) will give you delivery on return from trap. And making that a SIGBUS handler instead, mmapping a file, truncating it to 0 and dereferencing something in mmapped area will give you delivery on return from access error trap. Division by zero (and insertion handler on SIGFPE) ought to give you a type 2 exception stack frame (4 bytes of aux data, that makes shifted exception frame bugger format and vector fields of the original). FWIW, the third argument of handler points to struct ucontext { unsigned long uc_flags; struct ucontext *uc_link; stack_t uc_stack; struct mcontext uc_mcontext; unsigned long uc_filler[80]; sigset_t uc_sigmask; /* mask last for extensibility */ }; and type/vector is stored in uc_filler[54] (216 bytes into the array), with aux data from exception stack frame starting from uc_filler[55].