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:37:19 +0200 [thread overview]
Message-ID: <1239953839.7443.44.camel@pasglop> (raw)
In-Reply-To: <88F07543-B7F6-4F27-B5FB-4780AD069D7E@kernel.crashing.org>
On Thu, 2009-04-16 at 13:53 -0500, Kumar Gala wrote:
> A bit more debug info that might be helpful, I'm hitting this bad_area
> fault :
>
> if (!(vma->vm_flags & VM_EXEC) &&
> (cpu_has_feature(CPU_FTR_NOEXECUTE) ||
> !(vma->vm_flags & (VM_READ | VM_WRITE))))
> goto bad_area;
>
> bad_area 7 = 48024bf4 vm_flags:0810 0873
> SEGV 3 address:48024bf4 trap:400 error_code:0
Right, it's trying to execute off the data section (brobably just a blrl
instruction, that's what it used to do). You can see the VMA at 48022000
it's trying to execute from doesn't have the x bit set.
Toolchains were fixed, afaik, a while ago to properly mark the bit where
it does that executable, though the whole 32-bit ABI also got somewhat
overhauled to remove the need for that junk in the first place. I don't
remember the details off hand.
If we really want to support that old crap, then we probably need a
config option of some sort to force 32-bit to allow execution from
readable pages as I don't think we can identify such broken
binaries at runtime. Note that I'd be surprised if those binaries worked
under a 64-bit kernel, do you have a G5 you can try on ?
> [root:~] cat /proc/1/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0feab000-0ffbe000 r-xp 00000000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffbe000-0ffcb000 ---p 00113000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffcb000-0ffeb000 rw-p 00110000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffeb000-0fff0000 rw-p 0ffeb000 00:00 0
> 10000000-10008000 r-xp 00000000 00:0d 9093222 /sbin/init
> 10017000-10018000 rw-p 00007000 00:0d 9093222 /sbin/init
> 10018000-1001c000 rwxp 10018000 00:00 0 [heap]
> 48000000-48013000 r-xp 00000000 00:0d 7127082 /lib/ld-2.2.5.so
> 48022000-48026000 rw-p 00012000 00:0d 7127082 /lib/ld-2.2.5.so
> bfd0e000-bfd23000 rwxp bffeb000 00:00 0 [stack]
next prev parent reply other threads:[~2009-04-17 7:37 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 [this message]
2009-04-17 7:33 ` Benjamin Herrenschmidt
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=1239953839.7443.44.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 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).