All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: hazards during DO_FAULT macro..
Date: Wed, 4 Dec 2002 15:14:16 +0100	[thread overview]
Message-ID: <20021204151416.A31089@linux-mips.org> (raw)
In-Reply-To: <20021204101741.8326.qmail@webmail24.rediffmail.com>; from atulsrivastava9@rediffmail.com on Wed, Dec 04, 2002 at 10:17:41AM -0000

On Wed, Dec 04, 2002 at 10:17:41AM -0000, atul srivastava wrote:

> macro Do_FAULt(write) expands like..
> 
> #define DO_FAULT(write) \
>          .set    noreorder; \
>          .set    noat; \
>          SAVE_ALL; \
>          STI; \
>          nop; \

Unnecessary nop.

>          .set    at; \
>          move a0, sp; \
>          jal     do_page_fault; \
>          li     a1, write; \
>          nop; \

Unnecessary nop.

>          j       ret_from_sys_call; \

This is ret_from_exception since about 14 months.

>          nop; \
>         .set    noat;
> 
> this macro is called by handle_tlbx() routines.
> when I tracked this problem and i observed my pt_regs address
> looked o.k. and apparently right till after STI; \ and just before 
> instruction     mfc0    a2, CP0_BADVADDR;
> this i found by putting following instructions,
> 
> move  a0,sp; \
> jal show_regs; \
> nop; \
> 
> later it jumps to do_page_fault() ,and pt_regs address there 
> equals unexpectedly to envp_init and from thereon everythings goes 
> wrong..

This would means something like your user process was running with
c0_status.cu0 = 1 which is forbidden.  If that happens the kernel wouldn't
load a new stack pointer on kerne entry.

> I also tried with negating STI; \ , but same result.

This would means something like your user process was running with
c0_status.cu0 = 1 which is forbidden.  If that happens the kernel wouldn't
load a new stack pointer on kerne entry.

> 8001e6ac:	01094025 	or	$t0,$t0,$t1     STI macro code , though i 

The function there has doesn't have STI but KMODE since almost half a
year.  Time to upgrade.

And our code never had the mfc0 from the badvaddr register after the STI /
KMODE, so it seems you kernel tree is a) antique b) seems hacked beyond
recognition.

Moving the mfc0 behind the sti would be valid as long as we know there's
always a hazard of at least one cycle before interrupts get activated.  That
was true for the initially supported processors like R4000 (3 cycles) or
R4600 (1 cycle) but no longer for modern processors.

  Ralf

  reply	other threads:[~2002-12-04 14:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-04 10:17 hazards during DO_FAULT macro atul srivastava
2002-12-04 14:14 ` Ralf Baechle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-04 10:18 atul srivastava

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=20021204151416.A31089@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=atulsrivastava9@rediffmail.com \
    --cc=linux-mips@linux-mips.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.