linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Finn Thain <fthain@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Greg Ungerer <gerg@linux-m68k.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][CFT] signal handling fixes
Date: Tue, 27 Jul 2021 14:42:21 +0000	[thread overview]
Message-ID: <YQAbTazP4/JB8Aas@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <5622d120-1b89-6898-d091-8b4ceff6418@linux-m68k.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].

  reply	other threads:[~2021-07-27 14:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-25 17:18 [RFC][CFT] signal handling fixes Al Viro
2021-07-25 17:19 ` [PATCH 1/3] m68k: handle arrivals of multiple signals correctly Al Viro
2021-09-15 22:08   ` Michael Schmitz
2021-07-25 17:19 ` [PATCH 2/3] m68k: update ->thread.esp0 before calling syscall_trace() in ret_from_signal Al Viro
2021-09-15 22:19   ` Michael Schmitz
2021-07-25 17:20 ` [PATCH 3/3] m68k: leave stack mangling to asm wrapper of sigreturn() Al Viro
2021-09-15 23:35   ` Michael Schmitz
2021-09-16  0:19     ` Al Viro
2021-09-16  0:53       ` Michael Schmitz
2021-09-16  3:21         ` Al Viro
2021-09-16  5:02           ` Michael Schmitz
2021-09-16 16:14             ` Al Viro
2021-07-27 10:21 ` [RFC][CFT] signal handling fixes Finn Thain
2021-07-27 14:42   ` Al Viro [this message]
2021-07-28  1:23     ` Finn Thain
2021-08-11  1:42     ` Finn Thain
2021-09-16  9:03 ` Finn Thain
2021-09-23 14:43   ` Geert Uytterhoeven
2021-09-23 14:45 ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YQAbTazP4/JB8Aas@zeniv-ca.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).