From: grundler@dsl2.external.hp.com (Grant Grundler)
To: Matthew Wilcox <willy@debian.org>
Cc: Randolph Chung <tausq@debian.org>,
John David Anglin <dave@hiauly1.hia.nrc.ca>,
carlos@baldric.uwo.ca, parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Re: Trap handler
Date: Mon, 9 Dec 2002 11:41:25 -0700 [thread overview]
Message-ID: <20021209184125.GC6635@dsl2.external.hp.com> (raw)
In-Reply-To: <20021209182033.L20336@parcelfarce.linux.theplanet.co.uk>
On Mon, Dec 09, 2002 at 06:20:33PM +0000, Matthew Wilcox wrote:
> On Mon, Dec 09, 2002 at 11:03:16AM -0700, Grant Grundler wrote:
> > > Judging from the use of cli & sti in the x86 asm, I would venture to
> > > suggest that the I bit should be cleared. It makes sense anyway --
> > > you can't expect interrupts to be disabled over a page fault.
...
> i misremembered the sense of the I bit
As jsm agreed, if interrupts were disabled when we took the fault,
we can't re-enable them while handling a page fault.
Where x86 disables interrupts seems ok to me.
But the 2.4.20 parisc code (entry.S) re-enables interrupts at
intr_return label (ssm insn). Should parisc *not* be re-enabling
interrupts at all or at least not until after intr_check_resched
code block?
I'm trying to align x86/parisc implementations.
And "misaligned trap handler" is one difference I suspect
the x86 code doesn't have to handle.
thanks,
grant
next prev parent reply other threads:[~2002-12-09 18:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20021208232601.GH21187@tausq.org>
2002-12-08 23:55 ` [parisc-linux] Re: Trap handler John David Anglin
2002-12-09 5:12 ` Randolph Chung
2002-12-09 6:19 ` Randolph Chung
2002-12-09 12:54 ` Matthew Wilcox
2002-12-09 18:03 ` Grant Grundler
2002-12-09 18:20 ` Matthew Wilcox
2002-12-09 18:41 ` Grant Grundler [this message]
2002-12-09 18:55 ` Matthew Wilcox
2002-12-09 16:18 ` John David Anglin
2002-12-09 16:31 ` John David Anglin
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=20021209184125.GC6635@dsl2.external.hp.com \
--to=grundler@dsl2.external.hp.com \
--cc=carlos@baldric.uwo.ca \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=tausq@debian.org \
--cc=willy@debian.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.