From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Thorsten Glaser <tg@mirbsd.de>,
linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org
Subject: Re: aranym bug, manifests as "ida_remove called for id=13" on recent kernels
Date: Mon, 11 Oct 2010 23:02:24 +0100 [thread overview]
Message-ID: <20101011220224.GM19804@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20101011142428.GK19804@ZenIV.linux.org.uk>
On Mon, Oct 11, 2010 at 03:24:28PM +0100, Al Viro wrote:
> BTW, any comments on signal patchset? Seems to work here, including the
> stack expansion fixes, but that's on aranym. I'll try to resurrect the
> real hardware, but that may take a while. If somebody could give it a beating
> in the meanwhile...
Oh, lovely... One more signal bug (and a lot more on m68knommu): if we
strace a process and signal is delivered during pagefault handling, you'll
lose the second call of syscall_trace() on sigreturn(). If the signal
is delivered during a syscall or during an interrupt, syscall_trace() is
called twice on sigreturn() (as it does on all platforms). Fortunately,
that's easy to fix - same as on alpha (calling syscall_trace in ret_from_signal
if we are getting traced, just before doing RESTORE_SWITCH_STACK). Will test
and post...
FWIW, on other targets we either have sys_{rt,}_sigreturn() done as normal
functons (in which case the normal logics will take care of that), or
have them return to place in (common) syscall exit path earlier than
conditional call of syscall trace (mips, score), or check flags and do
call ourselves (sparc, alpha since it had been fixed). AFAICS, m68k and
m68knommu are the only ones buggered that way. On alpha we used to have
it even worse - there we did only one call on sigreturn() unconditionally...
next prev parent reply other threads:[~2010-10-11 22:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 17:49 aranym bug, manifests as "ida_remove called for id=13" on recent kernels Al Viro
2010-10-10 9:47 ` Geert Uytterhoeven
2010-10-10 14:49 ` Al Viro
2010-10-10 20:18 ` Geert Uytterhoeven
2010-10-10 23:52 ` Al Viro
2010-10-11 2:41 ` Al Viro
2010-10-11 4:36 ` Brad Boyer
2010-10-11 4:48 ` Al Viro
2010-10-11 12:21 ` Thorsten Glaser
2010-10-11 13:10 ` Andreas Schwab
2010-10-11 13:35 ` Al Viro
2010-10-11 14:15 ` Andreas Schwab
2010-10-11 14:24 ` Al Viro
2010-10-11 22:02 ` Al Viro [this message]
2010-11-02 15:30 ` Geert Uytterhoeven
2010-10-11 19:05 ` Mikael Pettersson
2010-10-11 9:27 ` Mikael Pettersson
2010-10-11 11:50 ` Mikael Pettersson
2010-10-11 12:29 ` Andreas Schwab
2010-10-11 8:39 ` 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=20101011220224.GM19804@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=schwab@linux-m68k.org \
--cc=tg@mirbsd.de \
/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