From: "Neelakantam, NaveenX" <naveenx.neelakantam@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] determining read or write on a page fault
Date: Sun, 14 Apr 2002 22:08:54 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590701905452@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905163@msgid-missing>
It turns out that we have been running into a cc code generation bug.
Changing the si_code = 0 case from "write" to "read" happened to make the
bug go away.
We have rewritten our code to workaround the bug, and everything works as
expected. Sorry for the false alarm.
Naveen Neelakantam
-----Original Message-----
From: Hoeflinger, Jay P
Sent: Wednesday, April 03, 2002 10:19 AM
To: 'davidm@hpl.hp.com'
Cc: linux-ia64@linuxia64.org; Neelakantam, NaveenX
Subject: RE: [Linux-ia64] determining read or write on a page fault
We want to report success using the 2.4.18 kernel and the
info sent to the segv handler on a page fault for our distributed
virtual shared memory system on IA64. Thanks for your help. We had
to make one assumption, though, that wasn't covered in your mail
(below).
The assumption was that if si_code=0, that the access was a "read".
We had originally assumed it was a "write", but this caused some errors.
When we changed to assuming "read", things worked. Is this assumption
valid? When does this case occur? Our scan of the kernel source seemed
to indicate that this case can't happen.
Thanks
Jay Hoeflinger and Naveen Neelakantam
-----Original Message-----
From: David Mosberger [mailto:davidm@hpl.hp.com]
Sent: Friday, February 22, 2002 7:25 PM
To: Hoeflinger, Jay P
Cc: linux-ia64@linuxia64.org
Subject: RE: [Linux-ia64] determining read or write on a page fault
If you want to try with a new kernel, the attached patch should give
you what you want. Specifically, if you get a SIGSEGV or a SIGBUS and
si_code is non-zero, you can check si_flags. If it has the
__ISR_VALID flag set, then the code in si_isr is valid. If si_isr is
valid, you can check whether bit 34 (read exception) or bit 35
(non-access exception) is set. If so, you may assume that the signal
was due to a load (or lfetch or some such). In all other cases, you'd
have to play it safe and assume that you're dealing with a write
access.
--david
< patch deleted >
next prev parent reply other threads:[~2002-04-14 22:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-21 21:09 [Linux-ia64] determining read or write on a page fault Hoeflinger, Jay P
2002-02-21 21:57 ` Boehm, Hans
2002-02-22 15:58 ` Hoeflinger, Jay P
2002-02-22 17:06 ` David Mosberger
2002-02-22 17:27 ` Hoeflinger, Jay P
2002-02-22 17:29 ` n0ano
2002-02-22 18:45 ` David Mosberger
2002-02-23 1:24 ` David Mosberger
2002-02-25 17:07 ` Hoeflinger, Jay P
2002-02-25 18:36 ` David Mosberger
2002-04-03 16:18 ` Hoeflinger, Jay P
2002-04-04 21:59 ` David Mosberger
2002-04-04 22:49 ` Neelakantam, NaveenX
2002-04-14 22:08 ` Neelakantam, NaveenX [this message]
2002-04-15 16:55 ` David Mosberger
2002-04-16 20:18 ` Neelakantam, NaveenX
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-105590701905452@msgid-missing \
--to=naveenx.neelakantam@intel.com \
--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