Peter, Arnd, Roland - do you have any concerns with requiring all
architectures to specify the stack to eclone() as [base, offset]
I can't see why that would be a problem.
It's consistent with the sigaltstack interface we already have.
Thanks,
Roland
Yes, it does unset MSR_SE bit in single_step_dabr_instruction()
irrespective of whether it was previously enabled through
user_enable_single_step(). This could be mitigated with the use of a
separate flag which can be used to conditionally unset MSR_SE, however
given further concerns about
I can't see anything you've done to keep this use of MSR_SE in the
user-mode register state from interfering with user_enable_single_step().
It looks to me like you'd swallow the normal step indications.
Likewise I'm not very clear on the interaction with kprobes, kgdb,
or whatnot for kernel-mode
Thanks! I'm very glad to finally see this ironed out by someone who
actually knows about powerpc innards.
Thanks,
Roland
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The BookE variant is superior in some ways as it allows to know where
you come from on branches. But that also means that the semantics exposed
to user space would not be consistent which is BAD (tm).
If it were me I would start with a simpler patch that doesn't implement it
at all on BookE,
Ptrace has performance and/or reliability problems when used to
sandbox threaded applications due to potential race conditions when
inspecting system call arguments. We hope that we can avoid this
problem with seccomp.
ptrace certainly has performance issues. I take it the only reliability
Ptrace has performance and/or reliability problems when used to
sandbox threaded applications due to potential race conditions when
inspecting system call arguments. We hope that we can avoid this
problem with seccomp.
ptrace certainly has performance issues. I take it the only reliability
Ptrace has performance and/or reliability problems when used to
sandbox threaded applications due to potential race conditions when
inspecting system call arguments. We hope that we can avoid this
problem with seccomp.
ptrace certainly has performance issues. I take it the only reliability
The patch only implements it for server/classic processors, not BookE,
thus it should probably only advertise it for these :-)
Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
(Branch Taken debug event) though it might need some careful fixups such
as the one we have
I don't think having it working for BookE is really a requirement before this
gets in though. If we can get it working with minimal effort for ppc64, that
would help get systemtap and related things functioning correctly there.
Sure, just conditionalize arch_has_block_step() however is
McGrath rol...@redhat.com
Date: Thu, 1 May 2008 23:40:58 -0700
Subject: [PATCH] powerpc ptrace block-step
This adds block-step support on powerpc,
including a PTRACE_SINGLEBLOCK request for ptrace.
Signed-off-by: Roland McGrath rol...@redhat.com
---
arch/powerpc/include/asm/ptrace.h |4
%ld\n, ret);
#else
# error not this one
#endif
write (1, buf, ret);
syscall (__NR_exit, 1);
return 2;
}
Signed-off-by: Roland McGrath rol...@redhat.com
---
arch/mips/include/asm/seccomp.h|1 -
arch/powerpc/include/asm
btw., shouldnt is_compat_task() expand to 0 in the
!CONFIG_COMPAT case? That way we could remove this #ifdef too.
(and move the first #ifdef inside the array initialization so
that we always have a mode1_syscalls_32[] array.)
I guess you mean define it in linux/compat.h then?
Go right
The patch is right though the log entry and comment are perhaps misleading.
The effect of the patch is to restore the compiler behavior to what it was
before. What it was before includes cases of producing .eh_frame and cases
of not producing it. The default behavior of a gcc-4.4 that was built
I certainly have no objection in principle. I doubt that any x86 userland
apps expect certain si_code values for SIGTRAP now, since the existing
values are not of any real use. (Signal handlers get the thread.trap_no and
thread.error_code values from hardware to guess from, and debuggers via
8be1a6d6c77ab4532e4476fdb8177030ef48b52c:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../roland/infiniband
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git
powerpc-tracehook
Roland McGrath (5
and
other machines do, and what users and debuggers want.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/signal.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index 7aada78..11a5c45
This changes powerpc syscall tracing to use the new tracehook.h entry
points. There is no change, only cleanup.
The assembly changes allow do_syscall_trace_enter() to abort the
syscall without losing the information about the original r0 value.
Signed-off-by: Roland McGrath [EMAIL PROTECTED
Add asm/syscall.h for powerpc with all the required entry points.
This will allow arch-independent tracing code for system calls.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
include/asm-powerpc/ptrace.h |1 +
include/asm-powerpc/syscall.h | 84
.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/entry_32.S|4 ++--
arch/powerpc/kernel/entry_64.S|3 +--
arch/powerpc/kernel/signal.c | 13 -
include/asm-powerpc/signal.h |3 +--
include/asm-powerpc/thread_info.h |5 -
5 files
The powerpc arch code has all the prerequisites, so set HAVE_ARCH_TRACEHOOK.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fe88418..587da5e 100644
Well, we use strings to represent the platforms already (ie, the actual
CPU microarchitecture). Fitting those into bits would be annoying, it
Then use dsocaps.
makes sense to have AT_BASE_PLATFORM to be the base variant of
AT_PLATFORM.
I understand why you think so. But let's not be too
I'm not sure... if ld.conf.d isn't parse of the kernel source tree then
it -will- end in tears...
Of course, you should include the file you want people to install
as part of the kernel source or build. You can copy it into
place in make install or something if you like (convention is to
call
That will make it part of the kernel ABI, since the mapping depends on
the running kernel, doesn't it?
Well, not the permanent ABI in the sense that AT_* et al are. This
mapping must agree among all users sharing the same ld.so.cache file.
That is all. So if you were to change the meaning of
The kernel does not have to come from the same place as the root
filesystem. You may want to run a new kernel with an old filesystem, or
vice-versa.
Well, it's not like these bits are really going to change in practice. My
point was just that this is a far softer ABI than the general
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
left there (keeping it to 32), but 3 is not 0. If not that, why not use
dsocaps? That is, some magic in the vDSO, which glibc already supports on
all machines where it uses the vDSO. (For how it works, see the use in
That all looks fine to me, though I won't claim to have paid close
attention to the nits in the various odd archs' files.
Thanks,
Roland
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kumar was just mentioning this post a few messages ago:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html
That is a very interesting approach to handle all the differences
between each processor's architecture, and a much cleaner way to set the
facilities we want than the
I would think there would be a different REQUEST value to mean set a
hardware breakpoint. Roland McGrath (cc'd) might be able to tell us
what other architectures do.
Other architectures don't give a good model to follow. (If anything,
they just trivally virtualize their own idiosyncratic
So it looks like we need to define a new feature bit to mean supports
block-step. Is this something that userspace will expect to be told
about via the AT_HWCAP entry in the aux vector?
I don't care to have userland know about it. I'm just concerned with the
arch_has_block_step() definition
I haven't seen that error before. Can you show the output of {eu-,}readelf -lS
on vdso64.so.dbg, and also on the vdso64.so successfully built when you
revert the patch?
Thanks,
Roland
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Oh and classic pitfall: If you define a new feature bit, make sure
CPU_FTRS_POSSIBLE is updated to contain it in cputable.h
Yeah, all that stuff I could figure out as needed. What I really meant
was, where is the big official table of which chips behave which ways that
you base all code that
, remove the 0 from this line:
# elif defined __powerpc__ 0/* XXX not upstream yet */
and compile with -D_GNU_SOURCE.
Thanks,
Roland
---
[PATCH] powerpc ptrace block-step
This adds block-step support on powerpc,
including a PTRACE_SINGLEBLOCK request for ptrace.
Signed-off-by: Roland
For the short answer, no, I'd like not to extend PTRACE_SET_DEBUGREG in
the simple fashion. The direction I want to move with this is away from
providing the hardware register formats directly as the user ABI.
What I mean is resurrecting, finishing, and porting the hw_breakpoint
work that Alan
I've been looking at PowerISA_Public.pdf that I downloaded from some ppc
site. It describes various things as need not be supported on all
implementations, for example the MSR_BE bit. Is there a generic way to
detect if such a feature is supported, or a known table of models that
support
and define
our own set_restore_sigmask() function. This saves the costly
SMP-safe set_bit operation, which we do not need for the sigmask
flag since TIF_SIGPENDING always has to be set too.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/entry_32.S|4 ++--
arch
Roland McGrath writes:
This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
This does the same for powerpc that I posted the x86 change for.
...
+static inline void set_restore_sigmask(void)
+{
+ struct thread_info *ti = current_thread_info();
+ ti-local_flags
I posted this before, but I hope it can go in now.
It's a prerequisite for some x86 ptrace cleanups I'd like to submit.
For powerpc, it requires this patch that's in Paul's queue:
commit 9c0c44dbd9bc380bee53e2f768c4ad5410b8aae2
Author: Roland McGrath [EMAIL PROTECTED
copy_siginfo_from_user32
Define the copy_siginfo_from_user32 entry point for powerpc, so
that generic CONFIG_COMPAT code can call it. We already had the
code rolled into compat_sys_rt_sigqueueinfo, this just moves it
out into the canonical function that other arch's define.
Signed-off-by: Roland McGrath
This crashes my powerpc mac g5.
It worked fine on mine.
It happens after the boot, during the first login-over-ssh.
Mine did lots of stuff fine.
This is with most of the rest of the -mm poopile applied. i386 and x86_64
seem OK.
I had only tested with Linus's tree plus the small handful
do not need for the sigmask
flag since TIF_SIGPENDING always has to be set too.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/entry_32.S|4 ++--
arch/powerpc/kernel/signal.c | 12 ++--
arch/powerpc/kernel/signal_32.c |2 +-
include/asm
No and no.
Good and good!
On ppc32 there is a sys_debug_setcontext system call that is there to
allow a process to debug itself. It does a setcontext and optionally
sets the MSR_SE or MSR_BE bit. We don't have it on ppc64 for some
reason (we should add it).
Wacky. I only looked in
These items in asm-offsets.c are not used anywhere. Remove them.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/asm-offsets.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm
This adds the forced_successful_syscall_return() macro, a mate to
force_successful_syscall_return() to test rather than set the condition.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
include/linux/ptrace.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
Define the forced_successful_syscall_return() macro to
pair with our force_successful_syscall_return() definition.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
include/asm-alpha/ptrace.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-alpha/ptrace.h b
Define the forced_successful_syscall_return() macro to
pair with our force_successful_syscall_return() definition.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
include/asm-powerpc/ptrace.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc
Define the forced_successful_syscall_return() macro to
pair with our force_successful_syscall_return() definition.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
include/asm-ia64/ptrace.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-ia64/ptrace.h b
Define the forced_successful_syscall_return() macro to
pair with our force_successful_syscall_return() definition.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
include/asm-sparc64/ptrace.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-sparc64
to change without
requiring any more updates in the arch code.
This change has no effect on the old arch code that still calls
ptrace_request or compat_ptrace_request.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
kernel/ptrace.c | 42 ++
1 files
Return -ENOSYS from arch_ptrace and compat_arch_ptrace
rather than calling ptrace_request or compat_ptrace_request.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/ptrace.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b
Return -ENOSYS from arch_ptrace and compat_arch_ptrace
rather than calling ptrace_request or compat_ptrace_request.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c |2 +-
arch/powerpc/kernel/ptrace32.c |2 +-
2 files changed, 2 insertions(+), 2
Are there any powerpc instructions that can read or change the MSR
explicitly from user mode? Any that can see or affect the MSR_SE bit?
e.g. x86 has pushf/popf unprivileged instructions, with which a user
program can both see the single-step flag set, and enable single-step for
its own next
The PT_DTRACE flag is meaningless and obsolete.
Don't touch it.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/process.c |5 -
arch/powerpc/kernel/sys_ppc32.c |5 -
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel
In both these cases, the storage access goes to LSU0, so you're
not hitting the errata.
I'll take your word for it.
If this doesn't help, and the failures stay intermittent, I don't think
there is a close-to-the-hardware problem here.
I saw no effect from that change. So now we're back to
comes up with PTRACE_SETREGS, not PPC_PTRACE_SETREGS.
It causes a BUG_ON to hit, so this fix needs to go in ASAP.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel
Define the copy_siginfo_from_user32 entry point for powerpc, so
that generic CONFIG_COMPAT code can call it. We already had the
code rolled into compat_sys_rt_sigqueueinfo, this just moves it
out into the canonical function that other arch's define.
Signed-off-by: Roland McGrath [EMAIL
-bit calls or 32-bit
kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
to examine e.g. siginfo_t.si_addr from a signal that sets it.
(This was broken as of 2.6.24 and, I presume, many or all prior versions.)
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
kernel/ptrace.c
This removes the special-case handling for PTRACE_GETSIGINFO
and PTRACE_SETSIGINFO from x86_64's sys32_ptrace. The generic
compat_ptrace_request code handles these.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/ptrace.c | 30 +-
1 files
Now that there are no more special cases in sys32_ptrace, we
can convert to using the generic compat_sys_ptrace entry point.
The sys32_ptrace function gets simpler and becomes compat_arch_ptrace.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/ia32/ia32entry.S |2 +-
arch/x86
Since the 970 kernel never sets DABRX currently, #8 cannot explain
_intermittent_ problems: either it always works, or never does.
That's kind of what I thought, but I couldn't make enough sense of
the #8 text to be very sure.
You could be happening upon #5, if the non-triggering data
This is advertised as a -mm patch but afacit it isn't against -mm. And it
doesn't seem to be against mainline either? At least, the fourth patch
fails to apply.
Oops, sorry for the bad labeling. The baseline I used was actually x86/mm.
(This was originally going to be just some x86_64
AFAICT the DABRX register just has two global bits that enable paying
attention to the DABR register. It only needs to be set once at boot time
(as the cell code does). I don't see how missing that initialization could
ever have explained the behavior we see where DABR matches are intermittent.
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
already did this. Uli Weigand found this back in November. I submitted
a patch for this which went into 2.6.25-rc4.
Can you please try again with rc4 ?
This is not the problem. This came up before and everyone seems have
The G5 that I have says:
cpu : PPC970FX, altivec supported
revision: 3.0 (pvr 003c 0300)
and it does indeed reproduce this bug.
It also strange for it to be the DABRX issue given the failure mode.
That is, it works sometimes but unreliably (as if the context
-mode
threads' registers for debugging and dumping.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 162 ++
1 files changed, 162 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel
This patch should go in immediately after:
commit 5e45efc63e33ee2bae9ff4d500b53d3bf86d2b48
Author: Roland McGrath [EMAIL PROTECTED]
compat_binfmt_elf
Thanks,
Roland
---
[PATCH] compat_binfmt_elf Kconfig
This adds Kconfig and Makefile bits to build fs
This patch replaces the earlier patch by the same title already in x86/mm:
commit a9014d2dfcb253fb3ce5f4e3318849f743b85427
Author: Roland McGrath [EMAIL PROTECTED]
x86 compat_binfmt_elf
It requires the new patch I just posted, titled compat_binfmt_elf Kconfig
to
define to make the generic support work out of the box.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |1 +
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/binfmt_elf32.c | 69
include/asm
On Thu, Dec 20, 2007 at 03:58:16AM -0800, Roland McGrath wrote:
+obj-$(CONFIG_PPC64)+= ../../../fs/compat_binfmt_elf.o
Building files from another directory is nasty. Please add a
CONFIG_BINFMT_COMPAT_ELF so we can simply build it in fs/
If that's better, please post
This implements user_regset-style accessors for the powerpc general registers.
In the future these functions will be the only place that needs to understand
the user_regset layout (core dump format) and how it maps to the internal
representation of user thread state.
Signed-off-by: Roland McGrath
Remove some dead code we no longer need now that the
user_regset interfaces are doing all these jobs.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/process.c | 48 -
include/asm-powerpc/elf.h | 46
-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 45 --
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 8c25b00..4edc118 100644
--- a/arch/powerpc
This switches powerpc to using the user_regset-based code for ELF core
dumps. The core dumps come out exactly the same either way, except that
the NT_PPC_VMX note is now omitted for any thread that never touched its
Altivec registers (thread_struct.vr_used).
Signed-off-by: Roland McGrath [EMAIL
.
But this demonstrates how simple it is to export register
information in core dumps when the user_regset style is
used for the low-level code.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c |2 +-
include/linux/elf.h |1 +
2 files changed, 2 insertions(+), 1
Now that ptrace_request handles these, we can drop some more boilerplate.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel
embedded knowledge of both those layouts
and of the internal data structures they correspond to. Only the
user_reget accessors need to implement that.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 234 +++---
1 files changed, 59
This replaces powerpc's compat_sys_ptrace with a compat_arch_ptrace and
enables the new generic definition of compat_sys_ptrace instead.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace32.c | 33 +
include/asm-powerpc/ptrace.h
-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/Makefile |3 +-
arch/powerpc/kernel/binfmt_elf32.c | 69
include/asm-powerpc/elf.h |1 +
3 files changed, 3 insertions(+), 70 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b
This cleans up the 32-bit ptrace syscall support to use user_regset calls
to get at the register data for PTRACE_*REGS* calls.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace32.c | 96 ++-
1 files changed, 25 insertions(+), 71
This removes some duplicated code by calling the new generic
compat_ptrace_request from powerpc's compat_sys_ptrace.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace32.c | 34 ++
1 files changed, 2 insertions(+), 32 deletions
This provides the task_user_regset_view entry point and support for all the
native-mode (64 on CONFIG_PPC64, 32 on CONFIG_PPC32) thread register state.
This will enable generic machine-independent code to access user-mode
threads' registers for debugging and dumping.
Signed-off-by: Roland McGrath
This extends task_user_regset_view CONFIG_PPC64 with support for the 32-bit
view of register state, compatible with what a CONFIG_PPC32 kernel provides.
This will enable generic machine-independent code to access user-mode
threads' registers for debugging and dumping.
Signed-off-by: Roland
This implements user_regset-style accessors for the powerpc Altivec data,
and rewrites the existing ptrace code in terms of those calls.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 112 +-
1 files changed, 78
This implements user_regset-style accessors for the powerpc SPE data,
and rewrites the existing ptrace code in terms of those calls.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 90 ++---
1 files changed, 57 insertions
This removes the handling for PTRACE_CONT et al from the powerpc
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 46 --
1 files changed, 0 insertions
This cleans up the formatting in the vDSO linker script, mostly just the
use of whitespace. It's intended to approximate the kernel standard
conventions for indenting C, treating elements of the linker script about
like initialized variable definitions.
Signed-off-by: Roland McGrath [EMAIL
This cleans up the formatting in the vDSO linker script, mostly just the
use of whitespace. It's intended to approximate the kernel standard
conventions for indenting C, treating elements of the linker script about
like initialized variable definitions.
Signed-off-by: Roland McGrath [EMAIL
before that were lost in the recent cleanup of GETREGS et al.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c |4
arch/powerpc/kernel/ptrace32.c |8
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b
-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/process.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e477c9d..fd799d2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel
Yup, I think I ditched most of them.. for some reason I decided it
couldn't happen, but maybe I'm wrong ?
Well, it's a BUG_ON. It's supposed to be for something that can't happen.
That's why it's a sanity check, not a wild assertion. ;-)
The 2/2 patch is an example of a bug that
) when producing lparmap.s.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index f39a72f..b0cb2e6 100644
--- a/arch/powerpc/kernel
91 matches
Mail list logo
