All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: grundler@dsl2.external.hp.com (Grant Grundler)
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	Randolph Chung <randolph@tausq.org>,
	parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] 2.5 randomly kills applications with page faults
Date: Fri, 20 Dec 2002 23:03:33 -0600	[thread overview]
Message-ID: <200212210503.gBL53XV11940@localhost.localdomain> (raw)
In-Reply-To: Message from grundler@dsl2.external.hp.com (Grant Grundler) of "Fri, 20 Dec 2002 21:34:48 MST." <20021221043448.GB26293@dsl2.external.hp.com>

grundler@dsl2.external.hp.com said:
> I'm worried about sr7 getting modified without the user stack pointer
> getting saved to the proper place. It might not be a problem at all. I
> just don't know all the uses of user/kernel stacks in the interrupt
> code paths. I'm wondering if the entire code sequence I quoted needs
> to block interrupts while setting up the syscall. 

I don't think that's a problem.

An interruption can occur anywhere, and thus it saves all registers.  The only 
problem is that on parisc there aren't separate irq stacks, so the 
interruption expects to be able to use the current kernel stack (whatever it 
is).  As long as the kernel stack is always correctly set up when %sr7 points 
to kernel space, we should be fine.  If we take an interruption before zeroing 
sr7, we go through the procedure to obtain a kernel stack for an executing 
user process (however, in this case, the interruption will stash the registers 
in the task structure, so we can't modify the task structure until we've 
changed sr7 to kernel space).  Also note, we can't use the kernel stack until 
sr7 is in kernel space.

James

      reply	other threads:[~2002-12-21  5:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-18 16:37 [parisc-linux] 2.5 randomly kills applications with page faults James Bottomley
2002-12-18 17:02 ` Randolph Chung
2002-12-20 22:12   ` James Bottomley
2002-12-20 22:19     ` John David Anglin
2002-12-20 22:37     ` Grant Grundler
2002-12-22  7:11       ` Grant Grundler
2002-12-22 10:17         ` Helge Deller
2002-12-22 16:35         ` James Bottomley
2002-12-21  1:38     ` Grant Grundler
2002-12-21  1:46       ` James Bottomley
2002-12-21  4:34         ` Grant Grundler
2002-12-21  5:03           ` James Bottomley [this message]

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=200212210503.gBL53XV11940@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=grundler@dsl2.external.hp.com \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=randolph@tausq.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.