linux-kernel - Scheduling in interrupt and call trace

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <6eb6ed920703190537o3c4738d6l61dd946d9554b4a3@mail.gmail.com>
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/