mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mikael Pettersson <mikpe@it.uu.se>
To: David Miller <davem@davemloft.net>
Cc: mikpe@it.uu.se, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Re: [BUG] 2.6.25-rc3 hangs in early boot on Sun Ultra5
Date: Wed, 27 Feb 2008 20:16:17 +0100	[thread overview]
Message-ID: <18373.46849.662187.25323@alkaid.it.uu.se> (raw)
In-Reply-To: <20080226.170613.107688605.davem@davemloft.net>

David Miller writes:
 > From: David Miller <davem@davemloft.net>
 > Date: Tue, 26 Feb 2008 16:49:00 -0800 (PST)
 > 
 > [ Thomas, forgot to CC: you earlier, changeset
 >   a0c1e9073ef7428a14309cba010633a6cd6719ea ("futex: runtime enable pi
 >   and robust functionality") broke sparc64. ]
 > 
 > > From: Mikael Pettersson <mikpe@it.uu.se>
 > > Date: Tue, 26 Feb 2008 09:55:50 +0100
 > > 
 > > > Minor update: rc2-git7 has the slow initial console behaviour,
 > > > but successfully switches to the framebuffer. rc2-git8 however
 > > > hangs in the console handover. So I'll bisect git7->git8 next.
 > > 
 > > Between the VT layer registering it's console and the atyfb
 > > driver initializing we get a crash, and it happens on all
 > > sparc64 systems.  It is caused by this commit and I am working
 > > on a fix:
 > 
 > The following patch will let things "work" but the trick being used
 > here by the FUTEX layer is borderline valid in my opinion.
 > 
 > Basically for 10+ years on sparc64 we've had this check here in the
 > fault path, which makes sure that if we're processing an exception
 > table entry we really, truly, are doing an access to userspace from
 > the kernel.  Otherwise we OOPS.
 > 
 > What the FUTEX checking code is doing now is doing a "user" access
 > with set_fs(KERNEL_DS) since it runs from the kernel bootup early init
 > sequence.  And this is illegal according to the existing checks.
 > 
 > When we do set_fs(KERNEL_DS) then pass a "user" pointer down
 > into a system call or something like that, we give it a pointer
 > that "cannot fault".  So if we get into the fault handling
 > path here for a case like that we really do want to scream and
 > print out an OOPS message in my opinion.
 > 
 > I realize that not many platforms other than sparc64 can check
 > for things this precisely, but it's something to consider.
 > 
 > Did this FUTEX change go into -stable too?
 > 
 > diff --git a/arch/sparc64/mm/fault.c b/arch/sparc64/mm/fault.c
 > index e2027f2..9183633 100644
 > --- a/arch/sparc64/mm/fault.c
 > +++ b/arch/sparc64/mm/fault.c
 > @@ -244,16 +244,8 @@ static void do_kernel_fault(struct pt_regs *regs, int si_code, int fault_code,
 >  	if (regs->tstate & TSTATE_PRIV) {
 >  		const struct exception_table_entry *entry;
 >  
 > -		if (asi == ASI_P && (insn & 0xc0800000) == 0xc0800000) {
 > -			if (insn & 0x2000)
 > -				asi = (regs->tstate >> 24);
 > -			else
 > -				asi = (insn >> 5);
 > -		}
 > -	
 > -		/* Look in asi.h: All _S asis have LS bit set */
 > -		if ((asi & 0x1) &&
 > -		    (entry = search_exception_tables(regs->tpc))) {
 > +		entry = search_exception_tables(regs->tpc);
 > +		if (entry) {
 >  			regs->tpc = entry->fixup;
 >  			regs->tnpc = regs->tpc + 4;
 >  			return;
 > 

Thanks, 2.6.25-rc3 plus this patch works fine on my Ultra5.

/Mikael

  parent reply	other threads:[~2008-02-27 19:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 20:41 Mikael Pettersson
2008-02-26  8:55 ` Mikael Pettersson
2008-02-26 21:32   ` David Miller
2008-02-27  0:49   ` David Miller
2008-02-27  1:06     ` David Miller
2008-02-27  8:02       ` Thomas Gleixner
2008-02-27 19:05         ` David Miller
2008-02-27 19:55           ` Thomas Gleixner
2008-02-27 19:16       ` Mikael Pettersson [this message]
2008-02-27 19:37         ` David Miller
2008-02-27  8:27     ` Mikael Pettersson
2008-02-26 20:46 ` David Miller

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=18373.46849.662187.25323@alkaid.it.uu.se \
    --to=mikpe@it.uu.se \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®