For me it's perfectly ok... I don't remember the exact traces, but some
sporadical SKAS-related Oops were reported... in no case they were repeatable
(since -V1 at least), so they were likely very thin races conditions.
I'm going to merge also the patches for PTRACE_SYSEMU_SINGLESTEP in SKAS,
since I'm now at releasing SKAS updates.
I'm also going to add this patch, which fixes another potential problem:
diff -puN arch/i386/kernel/ptrace.c~skas-add-wmb-for-mm-switch
2005-01-26 20:12:14.233441416 +0100
+++ vanilla-linux-2.6.9-paolo/arch/i386/kernel/ptrace.c 2005-01-26
@@ -570,8 +570,10 @@ asmlinkage int sys_ptrace(long request,
child->mm = new;
child->active_mm = new;
ret = 0;
* Protects ->fs, ->files, ->mm, ->ptrace, ->group_info, ->comm and
* synchronises with wait4().
* Nests both inside and outside of read_lock(&tasklist_lock).
* It must not be nested with write_lock_irq(&tasklist_lock),
* neither inside nor outside.
static inline void task_lock(struct task_struct *p)
The release will wait at least a couple of days, since I'm adding all this
stuff... especially, since there is a lock addition, I'd like at least one
positive report from one SMP user before *officially* releasing.
I've not seen any update to them from their original version (i.e. when they
were first discussed). Is this correct?
And my doubts about their technical merit were totally wrong. I simply was
missing that SYSEMU stands to SYSEMU_SINGLESTEP as SYSCALL stands on
SINGLESTEP (in correct, >=2.6.9 kernels), while I thought SYSEMU_SINGLESTEP
was equal to the correct SINGLESTEP (I was maybe misguided by the "using it
to check the host kernel correctness" hack we need to use).
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729