All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Linuxppc-dev Development <linuxppc-dev@ozlabs.org>
Subject: Re: issues w/init
Date: Fri, 17 Apr 2009 09:33:08 +0200	[thread overview]
Message-ID: <1239953588.7443.40.camel@pasglop> (raw)
In-Reply-To: <680ABFDC-A67F-48BB-B46C-564CB5373FEB@kernel.crashing.org>

On Thu, 2009-04-16 at 13:21 -0500, Kumar Gala wrote:
> Ben,
> 
> The following patch is causing me issues w/init SEGV on boot.  This is  
> a pretty old version of init and I'm wondering what the commit you had  
> related to old ABI breakage:

Can you test if the binary is trying to execute something that is
in a program section that isn't marked executable ? It could be
that it's build with a very old and broken toolchains.

(Note that when we finally add proper per-page exec permission support,
this will -also- break there even if we avoid that test below).

Maybe we can make a .config option for supporting obsolete crap that
tries to execute out of non executable sections ?

Cheers,
Ben.

> commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date:   Tue Feb 10 16:02:37 2009 +0000
> 
>      powerpc/mm: Rework I$/D$ coherency (v3)
> 
>      This patch reworks the way we do I and D cache coherency on  
> PowerPC.
> 
> 
> ---
>                  /*
>                   * Allow execution from readable areas if the MMU  
> does not
>                   * provide separate controls over reading and  
> executing.
> +                *
> +                * Note: That code used to not be enabled for 4xx/BookE.
> +                * It is now as I/D cache coherency for these is done at
> +                * set_pte_at() time and I see no reason why the test
> +                * below wouldn't be valid on those processors. This - 
> may-
> +                * break programs compiled with a really old ABI though.
>                   */
> 
> - k

      parent reply	other threads:[~2009-04-17  7:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-16 18:21 issues w/init Kumar Gala
2009-04-16 18:53 ` Kumar Gala
2009-04-16 19:25   ` Scott Wood
2009-04-16 19:27     ` Kumar Gala
2009-04-17  7:38       ` Benjamin Herrenschmidt
2009-04-17 10:05         ` Paul Mackerras
2009-04-17 10:33           ` Benjamin Herrenschmidt
2009-04-17 10:41           ` Benjamin Herrenschmidt
2009-04-17 13:23             ` Kumar Gala
2009-04-17 17:03               ` Benjamin Herrenschmidt
2009-04-17 17:40                 ` Kumar Gala
2009-04-17 17:51                   ` Benjamin Herrenschmidt
2009-04-17 13:59             ` Kumar Gala
2009-04-17 17:04               ` Benjamin Herrenschmidt
2009-04-17  7:37   ` Benjamin Herrenschmidt
2009-04-17  7:33 ` Benjamin Herrenschmidt [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=1239953588.7443.40.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.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.