linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	paulus@samba.org, mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org, Denis Kirjanov <kda@linux-powerpc.org>
Subject: Re: [PATCH V2] powerpc/mm: Don't do debug print before we do feature fixup
Date: Sun, 19 Jun 2016 09:21:51 +1000	[thread overview]
Message-ID: <1466292111.24271.89.camel@kernel.crashing.org> (raw)
In-Reply-To: <1466274479-5650-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>

On Sat, 2016-06-18 at 23:57 +0530, Aneesh Kumar K.V wrote:
> We use feature fixup in segment and page fault path and hence we should
> not call any function that can cause either of these before we finish
> feature fixup.
> 
> Calling into early debug routine can result in segment fault as updated
> in https://lkml.kernel.org/r/CAOJe8K2L8D1M_yZPmyiZ11JvJ+HAS0aFHOnsqaY=xLOnQTA3AA@mail.gmail.com
> 
> Avoid the segment fault by removing the debug print. Also remove the
> matching closing debug print at the end of the function.

Please add a comment at the beginning of setup_system() explaining
the situation. IE, that until the fixups are done, not even debug
printfs can be used.

It used to work though, the fact that we used 256M segment in that
case wasn't an issue, in part because btext only really existed on
machines that didn't have 1T segments. It was only ever going to be
a segment fault, the rest was bolted (early ioremap).

Ben.

  reply	other threads:[~2016-06-18 23:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-18 18:27 [PATCH V2] powerpc/mm: Don't do debug print before we do feature fixup Aneesh Kumar K.V
2016-06-18 23:21 ` Benjamin Herrenschmidt [this message]
2016-06-20  7:16   ` Denis Kirjanov

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=1466292111.24271.89.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=kda@linux-powerpc.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).