From: Matt Chapman <matthewc@cse.unsw.edu.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] sigaltstack and RBS
Date: Sun, 09 Feb 2003 10:55:50 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590709805829@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590709805824@msgid-missing>
On Sun, Feb 09, 2003 at 12:48:40AM -0800, David Mosberger wrote:
>
> The current sigaltstack implementation isn't designed to handle such a
> case. And I'm not sure whether it should. Is there a particular
> reason you want to do this sort of thing?
I'll explain the context. I've written a virtual machine monitor which
currently (for ease of prototyping) runs completely in userspace.
e.g. itc does an mmap, ptc does an munmap, changing RID unmaps a whole
region, SIGSEGV delivers a TLB miss to the "guest" kernel.
Now after a flush or RID change the guest kernel returns to its
userspace with ar.bspstore pointing off to somewhere that isn't mapped,
expecting to get a fault eventually. This is where the problem occurs.
A mandatory RSE load faults as expected and the kernel tries to deliver
SIGSEGV. But then the RFI to the signal trampoline repeats the same
RSE load that caused the fault in the first place, before the signal
handler can deal with it.
Is there any reason that the signal trampoline needs to see the
original frame, or would it suffice to give it an empty frame?
(Hmm, presumably this would mean filling out sc_cfm in the kernel...
how to do that if we're in a syscall and haven't done the cover?)
Matt
next prev parent reply other threads:[~2003-02-09 10:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-09 5:19 [Linux-ia64] sigaltstack and RBS Matt Chapman
2003-02-09 5:27 ` David Mosberger
2003-02-09 5:47 ` Matt Chapman
2003-02-09 7:58 ` Matt Chapman
2003-02-09 8:48 ` David Mosberger
2003-02-09 10:55 ` Matt Chapman [this message]
2003-02-09 18:22 ` David Mosberger
2003-02-11 3:06 ` David Mosberger
2003-02-11 7:26 ` Matt Chapman
2003-02-11 19:11 ` David Mosberger
2003-03-07 23:35 ` Bjorn Helgaas
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=marc-linux-ia64-105590709805829@msgid-missing \
--to=matthewc@cse.unsw.edu.au \
--cc=linux-ia64@vger.kernel.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