Hello.
Andrew Morton wrote:
OK, the `int $3' is part of the CONFIG_TRAP_BAD_SYSCALL_EXITS thing which I never use. I'm not sure what problem is actually being reported here, now you mention it.
The problem being reported here is that CONFIG_TRAP_BAD_SYSCALL_EXITS does nothing but locking up your machine. Actually the bug was so obvious, that I had real troubles finding it (the obvious things are difficult to spot), so I found some more bugs in a mean time. What was the bug? GET_THREAD_INFO(%ebp) was missing before TI_preempt_count(%ebp), hence the accesses beyond the stack. I'll have troubles beleiving this code worked without a lock-ups for someone sometimes. I fixed it differently though. The subsequent patches are addressing the issue.
Yup. But are you sure that the "+ 8" is correct, given these offsets are<> larger than that?
I don't think they are indeed larger. The %esp points to "struct pt_regs", which is 60 bytes in size, and without the xss/esp = 52. Adding 8 to this gives 60, so 56(+3) looks safe to me.
Probably it decided that some syscall got a "bad exit". Disable CONFIG_TRAP_BAD_SYSCALL_EXITS.
Yes, that's the fix too.
? It's still 4-byte-aligned.> - p->thread.esp0 = (unsigned long) (childregs+1) - 8; > + p->thread.esp0 = (unsigned long) (childregs+1) - 15; 15 is somewhat nasty - it will make the stack unaligned, should better be 16 I think.
I don't see your point. Why do you think that I substract the stack pointer by 32 bytes, for example? I literally substract it by 8 bytes, you propose to substract it by 15 *bytes* (not dwords), so why would it still be aligned? But anyway, fortunately this bug is not about the esp0 stuff at all.
I'm suspecting this is all due to CONFIG_TRAP_BAD_SYSCALL_EXITS taking the debug trap..
Sure. And that looks silly. I removed "int $3". Patches follow. Seems to work reliable now, but I don't know how to test it since there seem to be no such an offending syscalls here to test.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/