| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 19 Mar 2007 20:37:57 +0800 From: "railroad seeker" <railroad.seeker@...il.com> To: linux-kernel@...r.kernel.org Subject: Scheduling in interrupt and call trace Hi all: I am tracking a driver bug in arm linux when I got a scheduling in interrupt context panic. I traced into kernel schedule() function, and found that "schedulingin interrupt" is a check point when the process scheduler is invoked, and the callstack reveals that the scheduler is invoked due to semaphore down(). After that, the program counter must located in BUG(), that is something like "(void *)0 = 0" if we really do scheduling in interrupt contxt, and should cause the kernel to panic. However, what i got is that the latest program counter is located within the do_IRQ() context when the kernel was crashed . But it seems that the stack trace is a kernel stack of process context since the bottom of the stack is ret_from_syscall. (I have not enabled the frame pointer when compiling the kernel, instead, I back traced by manually inspect each 32 bit value from the output of objdump) , and I think that the latest PC should point to the next instruction of "(void *) 0 = 0". Is there any possibility with which we got this incorrect information, or I have misunderstanding about "kernel system to interrupt context switch? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists