> I agree this can be a bit kludgy, so if you want add another solution.
Patch is ok for me, but you have a good chance of having broken
other archs too due to the string.c changes. Probably needs some testing.
-Andi
---
This SF.Net email is s
On Sun, May 01, 2005 at 08:45:15PM +0200, [EMAIL PROTECTED] wrote:
>
> From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
>
> These are some trivial fixes for the x86-64 subarch module support. The only
> potential problem is that I have to modify arch/x
On Sunday 01 May 2005 18:07, Al Viro wrote:
> On Sun, May 01, 2005 at 01:30:57PM +0200, Blaisorblade wrote:
> > For now I've added an #ifdef to re-include that code for x86, while
> > excluding it for x86_64. Also, is that up-to-date wrt. 2.6.12-rc3?
>
> Yes, it is. As for the ptrace.c... IMO the
This var is currently useless, as it's apparent from reading the code. Until
2.6.11 it was used in some code related to jail mode, in the same proc.:
if(jail){
while(!reading) sched_yield();
}
jail mode has been dropped, together with that use, so let's finish dro
On Monday 02 May 2005 07:14, Rob Landley wrote:
> On Sunday 01 May 2005 07:06 am, Blaisorblade wrote:
> > > (That said, if you do use -p to get get a setuid bash, there's several
> > > other things you should do to make this marginally less dangerous. And
> > > I wouldn't trust myself to remember
On Sun, May 01, 2005 at 06:38:15PM +0200, [EMAIL PROTECTED] wrote:
>
> This var is currently useless, as it's apparent from reading the code. Until
> 2.6.11 it was used in some code related to jail mode, in the same proc.:
>
> if(jail){
> while(!reading) sched_yield();
>
Okay, I was in the process of attempting to recreate this when I
encountered the
following. Is this your "stack trace"? It occured on a slightly newer version
of both the host kernel and guest kernel.
This guest is 2.6.11.7 with the bs4 patches applied. The host is
2.6.11.7-skas3-v8. Of course, I'
[EMAIL PROTECTED] wrote:
>
> These are some trivial fixes for the x86-64 subarch module support. The only
> potential problem is that I have to modify arch/x86_64/kernel/module.c, to
> avoid copying the whole of it.
>
> I can't use it verbatim because it depends on a special vmalloc-like area for
[EMAIL PROTECTED] said:
> Is this your "stack trace"?
Close. What I'd really like is to get it to crash when it's running under
gdb, with a breakpoint on panic. Then, 'bt' to gdb at that point.
That gives the true call trace, plus line number information.
> 08297488: [<080697f0>] sig_handler
