mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-16 16:54:20 +08:00
3a51237dc1
* when we have stop/sysrq/go, we get pt_regs of whatever executes mc_work_proc(). Would be better to see what we had at the time of interrupt that got us stop. * stop/stop/stop..... will give stack overflow. Shouldn't allow stop from mconsole_stop(). * stop/stop/go leaves us inside mconsole_stop() with os_set_fd_block(req->originating_fd, 0); reactivate_fd(req->originating_fd, MCONSOLE_IRQ); just done by nested mconsole_stop(). Ditto. * once we'd seen stop, there's a period when INTR commands are executed out of order (as they should; we might have the things stuck badly enough to never reach mconsole_stop(), but still not badly enough to block mconsole_interrupt(); in that situation we _want_ things like "cad" to be executed immediately). Once we enter monsole_stop(), all INTR commands will be executed in order, mixed with PROC ones. We'd better let user see that such change of behaviour has happened. (Suggested by lennert). * stack footprint of monsole_interrupt() is an atrocity; AFAICS we can safely make struct mc_request req; static in function there. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
||
---|---|---|
.. | ||
drivers | ||
include | ||
kernel | ||
os-Linux | ||
scripts | ||
sys-i386 | ||
sys-ia64 | ||
sys-ppc | ||
sys-x86_64 | ||
config.release | ||
defconfig | ||
Kconfig | ||
Kconfig.char | ||
Kconfig.debug | ||
Kconfig.i386 | ||
Kconfig.net | ||
Kconfig.scsi | ||
Kconfig.x86_64 | ||
Makefile | ||
Makefile-i386 | ||
Makefile-ia64 | ||
Makefile-os-Linux | ||
Makefile-ppc | ||
Makefile-skas | ||
Makefile-tt | ||
Makefile-x86_64 |