* mpc83xx USB support status
From: Grant Likely @ 2007-07-06 20:02 UTC (permalink / raw)
To: Li Yang-r58472, Timur Tabi, Behan Webster, Linux PPC Linux PPC
Li,
What is the state of mpc83xx support in arch/powerpc? I saw some of
the patches you posted to the ppc and usb-devel lists, but I want to
make sure I've got the whole set. Also, can you tell me what the
state of those patches are (ie. which ones will be picked up for
2.6.23?)
I'm working on the mpc8349-mitx-gp board, and I can do the work to get
your changes working on that board.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: Andi Kleen @ 2007-07-06 19:04 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Linux Kernel Development, Linux/PPC Development, Andi Kleen,
H. Peter Anvin, Geert Uytterhoeven, Hiroaki Fuse
In-Reply-To: <468E8B07.2030404@goop.org>
On Fri, Jul 06, 2007 at 11:33:43AM -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> >"H. Peter Anvin" <hpa@zytor.com> writes:
> >
> >>For one thing, it looks like we're returning the wrong thing (EINVAL
> >>rather than ENOTTY) across the board. This was unfortunately a common
> >>misunderstanding with non-tty-related ioctls in the early days of Linux.
> >>
> >
> >ENOTTY is so excessively misnamed that it is actually surprising
> >anybody ever got that "right" (for very small values of right i guess)
> >
>
> But it *isn't* a typewriter.
Most ioctls are not related to ttys in any way.
-Andi
^ permalink raw reply
* ARCH=ppc vs ARCH=powerpc
From: Mark Fortescue @ 2007-07-06 16:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have noticed and read a few comments regarding the demise of ARCH=ppc.
Having two PowerPC arcitectures and only supprting one of them makes
little sense. Is it not time to migrate (where required) the remaining
code from arch/ppc to arch/powerpc and asm-ppc to asm-powerpc. There are
not many files left that are unique to ARCH=ppc so it should not take too
long.
For me, the requirement is to keep support for the cards indicated in
arch/ppc/config/xxx_defconfig (as I have one that I might what to use with
linux) in the same way as they are supported in ARCH=ppc.
I have just made some tweeks to get ARCH=ppc building for me but I still
need to sort out what is required to get around *** Error: Headers not
exportable for this architecture (ppc).
Regards
Mark Fortescue.
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: Jeremy Fitzhardinge @ 2007-07-06 18:33 UTC (permalink / raw)
To: Andi Kleen
Cc: Geert Uytterhoeven, Linux/PPC Development,
Linux Kernel Development, Hiroaki Fuse, H. Peter Anvin
In-Reply-To: <p737ipd1jsg.fsf@bingen.suse.de>
Andi Kleen wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> For one thing, it looks like we're returning the wrong thing (EINVAL
>> rather than ENOTTY) across the board. This was unfortunately a common
>> misunderstanding with non-tty-related ioctls in the early days of Linux.
>>
>
> ENOTTY is so excessively misnamed that it is actually surprising
> anybody ever got that "right" (for very small values of right i guess)
>
But it *isn't* a typewriter. Of course, it's not a giraffe either.
J
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: Jeremy Fitzhardinge @ 2007-07-06 18:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Geert Uytterhoeven, Linux/PPC Development, Andi Kleen,
Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <468E8BBF.9020907@zytor.com>
H. Peter Anvin wrote:
> The union of things that are not typewriters and not giraffes are rather
> large, indeed.
>
> This is getting philosophical.
>
I think my point is that we're rather short of good quality open source
giraffe drivers.
J
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: H. Peter Anvin @ 2007-07-06 18:36 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Geert Uytterhoeven, Linux/PPC Development, Andi Kleen,
Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <468E8B07.2030404@goop.org>
Jeremy Fitzhardinge wrote:
>>
>> ENOTTY is so excessively misnamed that it is actually surprising
>> anybody ever got that "right" (for very small values of right i guess)
>
> But it *isn't* a typewriter. Of course, it's not a giraffe either.
>
The union of things that are not typewriters and not giraffes are rather
large, indeed.
This is getting philosophical.
-hpa
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: H. Peter Anvin @ 2007-07-06 17:48 UTC (permalink / raw)
To: Andi Kleen
Cc: Geert Uytterhoeven, Linux/PPC Development,
Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <p737ipd1jsg.fsf@bingen.suse.de>
Andi Kleen wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>> For one thing, it looks like we're returning the wrong thing (EINVAL
>> rather than ENOTTY) across the board. This was unfortunately a common
>> misunderstanding with non-tty-related ioctls in the early days of Linux.
>
> ENOTTY is so excessively misnamed that it is actually surprising
> anybody ever got that "right" (for very small values of right i guess)
>
No argument there.
-hpa
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: Andi Kleen @ 2007-07-06 18:14 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Geert Uytterhoeven, Linux/PPC Development,
Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <468E6E33.3040000@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
>
> For one thing, it looks like we're returning the wrong thing (EINVAL
> rather than ENOTTY) across the board. This was unfortunately a common
> misunderstanding with non-tty-related ioctls in the early days of Linux.
ENOTTY is so excessively misnamed that it is actually surprising
anybody ever got that "right" (for very small values of right i guess)
-Andi
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: H. Peter Anvin @ 2007-07-06 16:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <Pine.LNX.4.62.0707061431360.1203@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
>
> Fuse-san discovered that running the umount that's part of busybox on a PS3
> with a recent kernel causes an error message to be printed on the console:
>
> | ioctl32(busybox:1340): Unknown cmd fd(3) cmd(00004c01){t:'L';sz:0} arg(00000000) on /dev/sda1
>
> On older kernels (e.g. 2.6.16), this doesn't happen.
>
> It can easily be reproduced by installing busybox and running
>
> | busybox umount /mountpoint
>
> on a mounted filesystem (except when using the loop device).
>
> Apparently Busybox uses the LOOP_CLR_FD ioctl when unmounting a file system,
> which is supported by the loop device only.
> On other block device types, this ioctl is not supported:
> - With a 64-bit application, the block layer returns ENOTTY (Inappropriate
> ioctl for device), while the SCSI layer returns EINVAL (Invalid argument)
> - With a 32-bit application, the compat_ioctl code returns EINVAL (Invalid
> argument) and prints an error on the console (for the first 50
> occurrencies, cfr. fs/compat_ioctl.c:compat_sys_ioctl())
>
> As I understand, compat_ioctl_error() is used to inform the user about ioctl
> values that are not yet handled by the compat_ioctl layer. However, LOOP_CLR_FD
> doesn't need to be handled (no data to convert between 32-bit and 64-bit), and
> it's perfectly valid for a block device to not implement it.
> So it's confusing to print this error message.
>
> Is there anything we can do about this?
>
For one thing, it looks like we're returning the wrong thing (EINVAL
rather than ENOTTY) across the board. This was unfortunately a common
misunderstanding with non-tty-related ioctls in the early days of Linux.
-hpa
^ permalink raw reply
* Re: Executing from readablee, no-exec pages
From: Scott Wood @ 2007-07-06 16:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <4A6D2FF2-ADD3-4D8A-ADBB-F04CAA778539@kernel.crashing.org>
On Fri, Jul 06, 2007 at 03:24:20PM +0200, Segher Boessenkool wrote:
> >Personally, I'd rather stick the VM_READ in there, partially for
> >selfish reasons (our root filesystems are based on older glibcs),
> >and because it seems a little too soon to deprecate glibc 2.3,
>
> Oh I don't know, can't we just deprecate glibc completely? ;-)
I wish. :-)
> >but also because in the absence of hardware support, the VM_EXEC
> >check will be nondeterministic, kicking in only when the first
> >fault for a page is to execute.
>
> I don't think that is a big concern.
Well, it means that leaving VM_READ out of the check (except where the
hardware PTE has an exec bit) isn't really buying us anything
security-wise (especially since the primary reason for no-exec protection
is to avoid code injections via stack overflow, and those pages will
usually already be present), so it doesn't hurt much to let things keep
working.
At the least, I'd like it to keep working for a few more kernel releases
(with a warning printed when a VM_EXEC-only test would have failed), so
people have time to upgrade glibc.
-Scott
^ permalink raw reply
* [PATCH] compat32: ignore the LOOP_CLR_FD ioctl
From: Geert Uytterhoeven @ 2007-07-06 15:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux/PPC Development, Adrian 'Trivial' Bunk,
Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <jevecxhep6.fsf@sykes.suse.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1349 bytes --]
compat32: Ignore the LOOP_CLR_FD ioctl for the loop block device, to kill an
annoying kernel message when e.g. busybox umount is used.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
fs/compat_ioctl.c | 4 ++++
1 files changed, 4 insertions(+)
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -63,6 +63,7 @@
#include <linux/wireless.h>
#include <linux/atalk.h>
#include <linux/blktrace_api.h>
+#include <linux/loop.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci.h>
@@ -3489,6 +3490,9 @@ HANDLE_IOCTL(LPSETTIMEOUT, lp_timeout_tr
IGNORE_IOCTL(VFAT_IOCTL_READDIR_BOTH32)
IGNORE_IOCTL(VFAT_IOCTL_READDIR_SHORT32)
+
+/* loop */
+IGNORE_IOCTL(LOOP_CLR_FD)
};
#define IOCTL_HASHSIZE 256
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: Geert Uytterhoeven @ 2007-07-06 15:49 UTC (permalink / raw)
To: Andreas Schwab
Cc: Linux/PPC Development, Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <jevecxhep6.fsf@sykes.suse.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 845 bytes --]
On Fri, 6 Jul 2007, Andreas Schwab wrote:
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> writes:
>
> > Is there anything we can do about this?
>
> Define it as IGNORE_IOCTL in fs/compat_ioctl.c?
Works fine, thx! I'll submit a patch.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Executing from readablee, no-exec pages
From: David Woodhouse @ 2007-07-06 14:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <468D68D4.4050704@freescale.com>
On Thu, 2007-07-05 at 16:55 -0500, Scott Wood wrote:
> To maintain compatibility with these versions, we could change the test
> in do_page_fault() to include VM_READ as well as VM_EXEC on targets that
> don't have a separate exec-bit in hardware (are there any powerpc mmus
> that do?).
64-bit implementations since POWER4 have separate exec permissions,
don't they? So any userspace which tries to execute non-executable pages
is already broken when running on a ppc64 machine; I wouldn't worry too
much about letting it break on ppc32 too.
We already use vDSO signal trampolines even on the 32-bit kernel, right?
--
dwmw2
^ permalink raw reply
* Re: Executing from readablee, no-exec pages
From: Johannes Berg @ 2007-07-06 13:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <9E7F4501-6F8F-430B-AC14-8DCDE437A2F9@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Fri, 2007-07-06 at 15:36 +0200, Segher Boessenkool wrote:
> > Umm, are you sure about this? The "prevent data exception in kernel
> > space" patch came from a test program I had that attempted to
> > execute a
> > page with /no permissions/ at all!
>
> I haven't looked at the code path in detail, but I believe Scott's
> analysis is correct. The kernel would merrily let a program run
> code from a page without execute permission (so also from a page
> without any permissions at all); not anymore, after my patch.
>
> Programs relying on this behaviour are obviously buggy, but the
> problem is that one of these broken programs is glibc, at least
> some not-all-that-new but also not-all-that-old versions.
Ok I can see how your patch changes that if the page is readable but not
executable and hasn't been faulted in yet, then executing it will kill
the program. However, reading first (prefaulting) and then executing
code on the page will not kill the program.
> Too many negatives, I don't see which way you're arguing :-)
Heh.
> I think you're saying to treat read access as including execute
> access? I believe that would be too permissive here.
Yeah well what I was trying to say is that there's no point in having
read without execute if prefaulting the page can get you around that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: PCI IO range limitation
From: Marian Balakowicz @ 2007-07-06 13:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1183461210.10386.104.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Tue, 2007-07-03 at 11:24 +0200, Marian Balakowicz wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
>>>> I guess that with the above dropping of non-zero based PCI IO ranges
>>>> this is not supposed to be working. But does anyone know why?
>>> We just fixed that for 64 bits but 32 bits still has the limitation.
>>> Note that it's not a very good idea to have your IO range at !0 if
>>> you're going to use anything ISA-like, such as a VGA video card or other
>>> legacy devices behind a PCI southbridge or SuperIO.
>> Agree with the zero-based IO range for ISA devices. But, knowing we don't
>> have any ISA stuff on board it should be possible to change the IO base.
>
> And you don't plan to ever have a VGA video card ?
You definitely got a point, but still, I tend to think that if someone wants to shoot himself in a foot he should be free to do it.
>> Are you planning on modifications for 32 bits as well?
>
> Not right now, but you are welcome to send a patch :-) Though I fail to
> see why you want to do it.
I don't necessarily need that, I was rather wondering what were the reasons for such modification. This used to be allowed in 2.4, while 2.6 kernel with the legacy setup will silently reset. Kernel booting and issuing a big warning instead would be much nicer if we are to stick to the 0 based IO ranges.
Marian
^ permalink raw reply
* Re: Executing from readablee, no-exec pages
From: Segher Boessenkool @ 2007-07-06 13:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, paulus
In-Reply-To: <1183720722.3818.126.camel@johannes.berg>
>> As revealed by the recent "Prevent data exception in kernel space"
>> patch, versions of glibc prior to 2.4[1] assume that, on
>> powerpc32, they
>> can execute out of any readable mapping, regardless of whether it is
>> marked for execution. This happens in the elf_machine_load_address()
>> function.
>
> Umm, are you sure about this? The "prevent data exception in kernel
> space" patch came from a test program I had that attempted to
> execute a
> page with /no permissions/ at all!
I haven't looked at the code path in detail, but I believe Scott's
analysis is correct. The kernel would merrily let a program run
code from a page without execute permission (so also from a page
without any permissions at all); not anymore, after my patch.
Programs relying on this behaviour are obviously buggy, but the
problem is that one of these broken programs is glibc, at least
some not-all-that-new but also not-all-that-old versions.
> I know that I used to have problems with mono making this
> assumption but
> these have since been fixed; however if I understand you correctly
> then
> you can always pre-fault the page by a read and then execute it so I
> don't see the point in not doing the change you suggest.
Too many negatives, I don't see which way you're arguing :-)
I think you're saying to treat read access as including execute
access? I believe that would be too permissive here.
Anyway, let's first decide what is the right thing to do, and
only then look at the code ;-)
Segher
^ permalink raw reply
* Re: Executing from readablee, no-exec pages
From: Segher Boessenkool @ 2007-07-06 13:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <468D68D4.4050704@freescale.com>
> As revealed by the recent "Prevent data exception in kernel
> space" patch, versions of glibc prior to 2.4[1] assume that,
Are you sure that this hasn't been fixed somewhere in the 2.3
series, too?
> on powerpc32, they can execute out of any readable mapping,
> regardless of whether it is marked for execution. This happens
> in the elf_machine_load_address() function.
>
> To maintain compatibility with these versions, we could change
> the test in do_page_fault() to include VM_READ as well as VM_EXEC
> on targets that don't have a separate exec-bit in hardware (are
> there any powerpc mmus that do?). However, Segher suggested on
> IRC that we may want to drop compatibility with those old versions
> of glibc, and that I should seek your input.
"drop compatibility" -- this sounds worse than it is, this is all
about supporting a badly broken application.
I wonder how this works with 32-bit userland on a 64-bit kernel,
or with older kernels. With arch/ppc/ an exec fault would do
the read checks IIRC, maybe we need to change to that.
> Personally, I'd rather stick the VM_READ in there, partially for
> selfish reasons (our root filesystems are based on older glibcs),
> and because it seems a little too soon to deprecate glibc 2.3,
Oh I don't know, can't we just deprecate glibc completely? ;-)
> but also because in the absence of hardware support, the VM_EXEC
> check will be nondeterministic, kicking in only when the first
> fault for a page is to execute.
I don't think that is a big concern.
> [1] It's possible that there are other instances of this in 2.4 and
> that the actual version is newer; I ran into obnoxious cross
> compilation issues trying to try it. However,
<rant>"Trying to try it" sounds like compiling glibc, indeed.</rant>
> <rant>
> Glibc already has target-specific code/headers; if you need to know
> something that you'd otherwise need a runs-on-the-target autoconf
> test for, why not just stick it in such a target-specific header?
> In this case, it was trying to figure out the size of "long double".
> </rant>
You can do a test like this by cross-compiling some code, and looking
at the size of the symbol in the resulting object file. Well that's
all off-topic here.
Segher
^ permalink raw reply
* Re: Too verbose compat_ioctl messages?
From: Andreas Schwab @ 2007-07-06 12:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development, Hiroaki Fuse
In-Reply-To: <Pine.LNX.4.62.0707061431360.1203@pademelon.sonytel.be>
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> writes:
> Is there anything we can do about this?
Define it as IGNORE_IOCTL in fs/compat_ioctl.c?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Too verbose compat_ioctl messages?
From: Geert Uytterhoeven @ 2007-07-06 12:47 UTC (permalink / raw)
To: Linux Kernel Development; +Cc: Linux/PPC Development, Hiroaki Fuse
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1992 bytes --]
Hi,
Fuse-san discovered that running the umount that's part of busybox on a PS3
with a recent kernel causes an error message to be printed on the console:
| ioctl32(busybox:1340): Unknown cmd fd(3) cmd(00004c01){t:'L';sz:0} arg(00000000) on /dev/sda1
On older kernels (e.g. 2.6.16), this doesn't happen.
It can easily be reproduced by installing busybox and running
| busybox umount /mountpoint
on a mounted filesystem (except when using the loop device).
Apparently Busybox uses the LOOP_CLR_FD ioctl when unmounting a file system,
which is supported by the loop device only.
On other block device types, this ioctl is not supported:
- With a 64-bit application, the block layer returns ENOTTY (Inappropriate
ioctl for device), while the SCSI layer returns EINVAL (Invalid argument)
- With a 32-bit application, the compat_ioctl code returns EINVAL (Invalid
argument) and prints an error on the console (for the first 50
occurrencies, cfr. fs/compat_ioctl.c:compat_sys_ioctl())
As I understand, compat_ioctl_error() is used to inform the user about ioctl
values that are not yet handled by the compat_ioctl layer. However, LOOP_CLR_FD
doesn't need to be handled (no data to convert between 32-bit and 64-bit), and
it's perfectly valid for a block device to not implement it.
So it's confusing to print this error message.
Is there anything we can do about this?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Executing from readablee, no-exec pages
From: Johannes Berg @ 2007-07-06 11:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <468D68D4.4050704@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Thu, 2007-07-05 at 16:55 -0500, Scott Wood wrote:
> As revealed by the recent "Prevent data exception in kernel space"
> patch, versions of glibc prior to 2.4[1] assume that, on powerpc32, they
> can execute out of any readable mapping, regardless of whether it is
> marked for execution. This happens in the elf_machine_load_address()
> function.
Umm, are you sure about this? The "prevent data exception in kernel
space" patch came from a test program I had that attempted to execute a
page with /no permissions/ at all!
I know that I used to have problems with mono making this assumption but
these have since been fixed; however if I understand you correctly then
you can always pre-fault the page by a read and then execute it so I
don't see the point in not doing the change you suggest.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: powerpc stacktrace and lockdep support
From: Johannes Berg @ 2007-07-06 10:59 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Christoph Hellwig
In-Reply-To: <468D45CD.1080008@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
Sergei, Thanks for your review!
> I suggest to also remove these 3 lines from the heading comment in this
> file -- they're not true anyway:
>
> * This file gets included from lowlevel asm headers too, to provide
> * wrapped versions of the local_irq_*() APIs, based on the
> * raw_local_irq_*() macros from the lowlevel headers.
Good point.
> > +#ifdef CONFIG_TRACE_IRQFLAGS
> > +#define TRACE_DISABLE_INTS bl .powerpc_trace_hardirqs_off
> > +#else
> > +#define TRACE_DISABLE_INTS
> > +#endif
> > +
>
> Erm, weren't those supposed to be in <asm-powerpc/irqflags.h>?
I guess they could be there. I was mucking my way through ;)
> The following code seemed over-engineered:
Yeah, perfectly correct. See my last mail to this thread from this
morning.
> Again, could have been more compact... unless trace_hardirqs_*() calls
> need to be in certain order WRT writes to PACASOFTIRQEN -- if so, in the 1st
> case that I've pointed out the order was not identical (probably wrong?)...
Yeah, there is an ordering requirement and it was wrong in that version
of the patch.
> > +/*
> > + * crappy helper for irq-trace
> > + */
> > +
> > +#include <asm/ppc_asm.h>
> > +#include <asm/asm-offsets.h>
> > +
> > +#define STACKSPACE GPR0 + 16*8
>
> I guess this should be 16*4 for PPC32.
> Didn't you forget to add GPR0 to the offsets here?
> You certainly did. I bet you're clobbering GPR11/12 (if I didn't miscount)...
All correct. That might even be why it didn't work on 32-bit for me and
then I gave up. In any case, I completely rewrote this file.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: powerpc stacktrace and lockdep support
From: Johannes Berg @ 2007-07-06 9:54 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <1183713827.3818.71.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
*sigh* I really shouldn't have mailed this out in the first place. Every
time I look at it I find new bugs despite the fact that it actually
works on my machine.
> ld r3,SOFTE(r1)
> - bl .local_irq_restore
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + cmpdi r3,0
> + beq 14f
> + bl .trace_hardirqs_on
> + ld r3,SOFTE(r1)
> +14:
> + bl .raw_local_irq_restore
> + cmpdi r3,0
This should reload r3 before the second compare as raw_local_irq_restore
returns nothing (void). And why does it need a second compare anyway?
Just rewrite as
ld r3, SOFTE(r1)
#ifdef CONFIG_TRACE_IRQFLAGS
cmpdi r3, 0
bne 14f
bl .raw_local_irq_restore
bl .trace_hardirqs_off
b 15f
14:
bl .trace_hardirqs_on
li r3, 1
#endif
bl .raw_local_irq_restore
15:
which has the advantage of having only one conditional branch and less
preprocessor foo.
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + cmpdi r5,0
> + beq 5f
> + bl .trace_hardirqs_on
> + ld r5,SOFTE(r1)
> stb r5,PACASOFTIRQEN(r13)
> -
> + b 6f
> +5:
> + stb r5,PACASOFTIRQEN(r13)
> + bl .trace_hardirqs_off
> +6:
> +#else
> + stb r5,PACASOFTIRQEN(r13)
> +#endif
Similarly, that could be rewritten as
#ifdef CONFIG_TRACE_IRQFLAGS
cmpdi r5, 0
bne 5f
stb r5, PACASOFTIRQEN(r13)
bl .trace_hardirqs_off
b 6f
5:
bl .trace_hardirqs_on
li r5, 1
#endif
stb r5, PACASOFTIRQEN(r13)
6:
I can't test these modifications over the weekend but they should be
fine.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: powerpc stacktrace and lockdep support
From: Johannes Berg @ 2007-07-06 9:23 UTC (permalink / raw)
To: Christoph Hellwig, Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1183588814.3818.1.camel@johannes.berg>
On Thu, 2007-07-05 at 00:40 +0200, Johannes Berg wrote:
> On Sat, 2007-06-30 at 10:58 +0200, Christoph Hellwig wrote:
> > On Thu, Jun 28, 2007 at 06:20:42PM +0200, Johannes Berg wrote:
> > > This one doesn't break 32-bit build by simply disabling irqtrace for
> > > 32-bit.
> >
> > This looks really cool to me. I'd love to see this in 2.6.23.
>
> Hmm. Looks like I just found a case where I forgot to trace in some
> place:
>
> [ 241.629380] hardirqs last enabled at (1319): [<c0000000000b3718>] .get_page_from_freelist+0x298/0x620
> [ 241.629714] hardirqs last disabled at (1320): [<c000000000033690>] .native_hpte_invalidate+0x60/0x320
> [ 241.629732] softirqs last enabled at (1282): [<c000000000059e28>] .__do_softirq+0x198/0x1e0
> [ 241.629748] softirqs last disabled at (1273): [<c00000000000c7e4>] .do_softirq+0xd4/0xe0
Not sure what that was, but I found one place where it could have come
from (do an interdiff if you want to know). Below patch is a bit nicer,
especially those trace_hardirqs wrappers. However, the presence of those
itself is indication that I haven't given most of the hooks I added much
thought. Though, in case somebody wants to develop it further I'll even
sign it off.
For me it's doing what I want, it allows me to develop with and for
lockdep, take advantage of lockdep and still use my machine (with forced
preemption) as expected; however I don't think I'd be comfortable with
anybody else using it except on test machines unless somebody else gives
it a thorough look first. Especially for say iSeries which is quite
different in the low-level code and I can't even test.
johannes
Subject: powerpc: 64-bit irqtrace support
From: Johannes Berg <johannes@sipsolutions.net>
This adds irqtrace support to 64-bit powerpc.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
arch/powerpc/Kconfig | 9 ++++
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/entry_64.S | 24 +++++++++++
arch/powerpc/kernel/head_64.S | 54 +++++++++++++++++++++-----
arch/powerpc/kernel/irq.c | 2
arch/powerpc/kernel/irqtrace.S | 82 ++++++++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/ppc_ksyms.c | 2
arch/powerpc/kernel/setup_64.c | 6 ++
include/asm-powerpc/hw_irq.h | 14 +++---
include/asm-powerpc/irqflags.h | 13 ------
include/asm-powerpc/rwsem.h | 34 ++++++++++++----
include/asm-powerpc/spinlock.h | 1
12 files changed, 202 insertions(+), 40 deletions(-)
--- linux-2.6-git.orig/arch/powerpc/Kconfig 2007-07-05 23:01:18.001397556 +0200
+++ linux-2.6-git/arch/powerpc/Kconfig 2007-07-05 23:01:18.068397556 +0200
@@ -38,6 +38,15 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ depends on PPC64
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
--- linux-2.6-git.orig/arch/powerpc/kernel/irq.c 2007-07-05 23:01:11.727397556 +0200
+++ linux-2.6-git/arch/powerpc/kernel/irq.c 2007-07-05 23:01:18.084397556 +0200
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
--- linux-2.6-git.orig/arch/powerpc/kernel/ppc_ksyms.c 2007-07-05 23:01:11.759397556 +0200
+++ linux-2.6-git/arch/powerpc/kernel/ppc_ksyms.c 2007-07-05 23:01:18.094397556 +0200
@@ -50,7 +50,7 @@
#endif
#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif
#ifdef CONFIG_PPC32
--- linux-2.6-git.orig/include/asm-powerpc/hw_irq.h 2007-07-05 23:01:11.985397556 +0200
+++ linux-2.6-git/include/asm-powerpc/hw_irq.h 2007-07-05 23:01:18.108397556 +0200
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags) ((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags) ((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
@@ -108,6 +109,7 @@ static inline void local_irq_save_ptr(un
#define local_save_flags(flags) ((flags) = mfmsr())
#define local_irq_save(flags) local_irq_save_ptr(&flags)
#define irqs_disabled() ((mfmsr() & MSR_EE) == 0)
+#define irqs_disabled_flags(flags) (((flags) & MSR_EE) == 0)
#define hard_irq_enable() local_irq_enable()
#define hard_irq_disable() local_irq_disable()
--- linux-2.6-git.orig/include/asm-powerpc/irqflags.h 2007-07-05 23:01:12.018397556 +0200
+++ linux-2.6-git/include/asm-powerpc/irqflags.h 2007-07-05 23:01:18.141397556 +0200
@@ -15,17 +15,4 @@
*/
#include <asm-powerpc/hw_irq.h>
-/*
- * Do the CPU's IRQ-state tracing from assembly code. We call a
- * C function, so save all the C-clobbered registers:
- */
-#ifdef CONFIG_TRACE_IRQFLAGS
-
-#error No support on PowerPC yet for CONFIG_TRACE_IRQFLAGS
-
-#else
-# define TRACE_IRQS_ON
-# define TRACE_IRQS_OFF
-#endif
-
#endif
--- linux-2.6-git.orig/include/asm-powerpc/rwsem.h 2007-07-05 23:01:12.050397556 +0200
+++ linux-2.6-git/include/asm-powerpc/rwsem.h 2007-07-05 23:01:18.149397556 +0200
@@ -28,11 +28,21 @@ struct rw_semaphore {
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
struct list_head wait_list;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+# define __RWSEM_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
+#else
+# define __RWSEM_DEP_MAP_INIT(lockname)
+#endif
+
#define __RWSEM_INITIALIZER(name) \
{ RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
- LIST_HEAD_INIT((name).wait_list) }
+ LIST_HEAD_INIT((name).wait_list) \
+ __RWSEM_DEP_MAP_INIT(name) }
#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
@@ -42,12 +52,15 @@ extern struct rw_semaphore *rwsem_down_w
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem);
-static inline void init_rwsem(struct rw_semaphore *sem)
-{
- sem->count = RWSEM_UNLOCKED_VALUE;
- spin_lock_init(&sem->wait_lock);
- INIT_LIST_HEAD(&sem->wait_list);
-}
+extern void __init_rwsem(struct rw_semaphore *sem, const char *name,
+ struct lock_class_key *key);
+
+#define init_rwsem(sem) \
+ do { \
+ static struct lock_class_key __key; \
+ \
+ __init_rwsem((sem), #sem, &__key); \
+ } while (0)
/*
* lock for reading
@@ -74,7 +87,7 @@ static inline int __down_read_trylock(st
/*
* lock for writing
*/
-static inline void __down_write(struct rw_semaphore *sem)
+static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
{
int tmp;
@@ -84,6 +97,11 @@ static inline void __down_write(struct r
rwsem_down_write_failed(sem);
}
+static inline void __down_write(struct rw_semaphore *sem)
+{
+ __down_write_nested(sem, 0);
+}
+
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
int tmp;
--- linux-2.6-git.orig/include/asm-powerpc/spinlock.h 2007-07-05 23:01:12.097397556 +0200
+++ linux-2.6-git/include/asm-powerpc/spinlock.h 2007-07-05 23:01:18.152397556 +0200
@@ -19,6 +19,7 @@
*
* (the type definitions are in asm/spinlock_types.h)
*/
+#include <linux/irqflags.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
#include <asm/hvcall.h>
--- linux-2.6-git.orig/arch/powerpc/kernel/head_64.S 2007-07-05 23:01:11.796397556 +0200
+++ linux-2.6-git/arch/powerpc/kernel/head_64.S 2007-07-05 23:01:18.173397556 +0200
@@ -394,6 +394,12 @@ label##_iSeries: \
EXCEPTION_PROLOG_ISERIES_2; \
b label##_common; \
+#ifdef CONFIG_TRACE_IRQFLAGS
+#define TRACE_DISABLE_INTS bl .powerpc_trace_hardirqs_off
+#else
+#define TRACE_DISABLE_INTS
+#endif
+
#ifdef CONFIG_PPC_ISERIES
#define DISABLE_INTS \
li r11,0; \
@@ -405,14 +411,15 @@ BEGIN_FW_FTR_SECTION; \
mfmsr r10; \
ori r10,r10,MSR_EE; \
mtmsrd r10,1; \
-END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
+END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES); \
+ TRACE_DISABLE_INTS
#else
#define DISABLE_INTS \
li r11,0; \
stb r11,PACASOFTIRQEN(r13); \
- stb r11,PACAHARDIRQEN(r13)
-
+ stb r11,PACAHARDIRQEN(r13); \
+ TRACE_DISABLE_INTS
#endif /* CONFIG_PPC_ISERIES */
#define ENABLE_INTS \
@@ -965,24 +972,38 @@ bad_stack:
*/
fast_exc_return_irq: /* restores irq state too */
ld r3,SOFTE(r1)
- ld r12,_MSR(r1)
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r3,0
+ beq 1f
+ bl .trace_hardirqs_on
+ ld r3,SOFTE(r1)
+1:
stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
+ cmpdi r3,0
+ bne 2f
+ bl .trace_hardirqs_off
+ ld r3,SOFTE(r1)
+2:
+#else
+ stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
+#endif
+ ld r12,_MSR(r1)
rldicl r4,r12,49,63 /* get MSR_EE to LSB */
stb r4,PACAHARDIRQEN(r13) /* restore paca->hard_enabled */
- b 1f
+ b 3f
.globl fast_exception_return
fast_exception_return:
ld r12,_MSR(r1)
-1: ld r11,_NIP(r1)
+3: ld r11,_NIP(r1)
andi. r3,r12,MSR_RI /* check if RI is set */
beq- unrecov_fer
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
andi. r3,r12,MSR_PR
- beq 2f
+ beq 4f
ACCOUNT_CPU_USER_EXIT(r3, r4)
-2:
+4:
#endif
ld r3,_CCR(r1)
@@ -1387,11 +1408,24 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
/*
* hash_page couldn't handle it, set soft interrupt enable back
- * to what it was before the trap. Note that .local_irq_restore
+ * to what it was before the trap. Note that .raw_local_irq_restore
* handles any interrupts pending at this point.
*/
ld r3,SOFTE(r1)
- bl .local_irq_restore
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r3,0
+ beq 14f
+ bl .trace_hardirqs_on
+ ld r3,SOFTE(r1)
+14:
+ bl .raw_local_irq_restore
+ cmpdi r3,0
+ bne 15f
+ bl .trace_hardirqs_off
+15:
+#else
+ bl .raw_local_irq_restore
+#endif
b 11f
/* Here we have a page fault that hash_page can't handle. */
--- linux-2.6-git.orig/arch/powerpc/kernel/setup_64.c 2007-07-05 23:01:11.829397556 +0200
+++ linux-2.6-git/arch/powerpc/kernel/setup_64.c 2007-07-05 23:01:18.185397556 +0200
@@ -33,6 +33,7 @@
#include <linux/serial_8250.h>
#include <linux/bootmem.h>
#include <linux/pci.h>
+#include <linux/lockdep.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -359,6 +360,11 @@ void __init setup_system(void)
&__start___fw_ftr_fixup, &__stop___fw_ftr_fixup);
/*
+ * start lockdep
+ */
+ lockdep_init();
+
+ /*
* Unflatten the device-tree passed by prom_init or kexec
*/
unflatten_device_tree();
--- linux-2.6-git.orig/arch/powerpc/kernel/entry_64.S 2007-07-05 23:01:11.864397556 +0200
+++ linux-2.6-git/arch/powerpc/kernel/entry_64.S 2007-07-05 23:01:18.211397556 +0200
@@ -88,6 +88,13 @@ system_call_common:
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
std r11,-16(r9) /* "regshere" marker */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ REST_GPR(0,r1)
+ REST_4GPRS(3,r1)
+ REST_2GPRS(7,r1)
+ addi r9,r1,STACK_FRAME_OVERHEAD
+#endif
li r10,1
stb r10,PACASOFTIRQEN(r13)
stb r10,PACAHARDIRQEN(r13)
@@ -491,8 +498,20 @@ BEGIN_FW_FTR_SECTION
4:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r5,0
+ beq 5f
+ bl .trace_hardirqs_on
+ ld r5,SOFTE(r1)
stb r5,PACASOFTIRQEN(r13)
-
+ b 6f
+5:
+ stb r5,PACASOFTIRQEN(r13)
+ bl .trace_hardirqs_off
+6:
+#else
+ stb r5,PACASOFTIRQEN(r13)
+#endif
/* extract EE bit and use it to restore paca->hard_enabled */
ld r3,_MSR(r1)
rldicl r4,r3,49,63 /* r0 = (r3 >> 15) & 1 */
@@ -560,6 +579,9 @@ do_work:
bne restore
/* here we are preempting the current task */
1:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .powerpc_trace_hardirqs_on
+#endif
li r0,1
stb r0,PACASOFTIRQEN(r13)
stb r0,PACAHARDIRQEN(r13)
--- linux-2.6-git.orig/arch/powerpc/kernel/Makefile 2007-07-05 23:01:18.002397556 +0200
+++ linux-2.6-git/arch/powerpc/kernel/Makefile 2007-07-05 23:01:18.212397556 +0200
@@ -62,6 +62,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
+obj-$(CONFIG_TRACE_IRQFLAGS) += irqtrace.o
module-$(CONFIG_PPC64) += module_64.o
obj-$(CONFIG_MODULES) += $(module-y)
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-git/arch/powerpc/kernel/irqtrace.S 2007-07-06 02:11:15.110814034 +0200
@@ -0,0 +1,82 @@
+/*
+ * helpers for irq-trace
+ *
+ * We invoke the hardirq trace functions from various inconvenient
+ * places; these helpers save all callee-saved registers.
+ *
+ * Author: Johannes Berg <johannes@sipsolutions.net>
+ */
+
+#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+
+#ifdef CONFIG_PPC64
+#define ST std
+#define STU stdu
+#define L ld
+#define WSZ 8
+#define FREE 32
+#else
+#error double-check please
+#define ST stw
+#define STU stwu
+#define L lwz
+#define WSZ 4
+#define FREE 16
+#endif
+
+#define STACKSPACE (FREE + 16*WSZ)
+#define SAVE(n) (FREE + n*WSZ)
+
+_GLOBAL(powerpc_trace_hardirqs_on)
+ ST r3, (SAVE(2)-STACKSPACE)(r1)
+ LOAD_REG_IMMEDIATE(r3, .trace_hardirqs_on)
+ b powerpc_trace_hardirqs
+
+_GLOBAL(powerpc_trace_hardirqs_off)
+ ST r3, (SAVE(2)-STACKSPACE)(r1)
+ LOAD_REG_IMMEDIATE(r3, .trace_hardirqs_off)
+
+powerpc_trace_hardirqs:
+ ST r0, (SAVE(0)-STACKSPACE)(r1)
+ mflr r0
+ ST r0, LRSAVE(r1)
+ STU r1, -STACKSPACE(r1)
+ mfctr r0
+ ST r0, SAVE(14)(r1)
+ mtctr r3
+ ST r2, SAVE(1)(r1)
+ ST r4, SAVE(3)(r1)
+ ST r5, SAVE(4)(r1)
+ ST r6, SAVE(5)(r1)
+ ST r7, SAVE(6)(r1)
+ ST r8, SAVE(7)(r1)
+ ST r9, SAVE(8)(r1)
+ ST r10, SAVE(9)(r1)
+ ST r11, SAVE(10)(r1)
+ ST r12, SAVE(11)(r1)
+ ST r13, SAVE(12)(r1)
+ mfcr r0
+ ST r0, SAVE(13)(r1)
+ bctrl
+ L r2, SAVE(1)(r1)
+ L r3, SAVE(2)(r1)
+ L r4, SAVE(3)(r1)
+ L r5, SAVE(4)(r1)
+ L r6, SAVE(5)(r1)
+ L r7, SAVE(6)(r1)
+ L r8, SAVE(7)(r1)
+ L r9, SAVE(8)(r1)
+ L r10, SAVE(9)(r1)
+ L r11, SAVE(10)(r1)
+ L r12, SAVE(11)(r1)
+ L r13, SAVE(12)(r1)
+ L r0, SAVE(13)(r1)
+ mtcr r0
+ L r0, SAVE(14)(r1)
+ mtctr r0
+ L r1, 0(r1)
+ L r0, LRSAVE(r1)
+ mtlr r0
+ L r0, (SAVE(0)-STACKSPACE)(r1)
+ blr
^ permalink raw reply
* Re: [PATCH] pseries: don't die if unknown/missing interrupt controller property
From: Sonny Rao @ 2007-07-06 9:16 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <20070705133734.GA9215@lixom.net>
On Thu, Jul 05, 2007 at 08:37:34AM -0500, Olof Johansson wrote:
> On Sun, Jul 01, 2007 at 08:49:37PM -0400, Sonny Rao wrote:
> > The pseries platform does not have a default function for init_IRQ and
> > does not install one if it doesn't find or doesn't recognize an
> > interrupt controller in the device tree. Currently, the kernel dies
> > when it tries to call the NULL init_IRQ() function. Clean that up.
>
> Doesn't it make more sense to make init_IRQ() check that the pointer is
> set instead? That'll work for more platforms than just pseries.
Yeah, that might be the simplest way. The only reason I can think of
to do it this way is that (I think) every single other platform in
arch/powerpc statically initializes init_IRQ, with pseries being the
oddball. It doesn't matter much to me, so I can post another patch in a
bit.
Sonny
^ permalink raw reply
* Porting kernel to MPC 74X7
From: linuxdev @ 2007-07-06 6:33 UTC (permalink / raw)
To: linuxppc-embedded
HI guys!
I have to port a linux kernel on Motorola MPC 74X7 based board.
Since am pretty new to this tech, I would be grateful if anyone could help
with directing to information source or guide me in selecting a proper
kernel and the respective BSP.
Thanks...
--
View this message in context: http://www.nabble.com/Porting-kernel-to-MPC-74X7-tf4033888.html#a11459454
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox