diff options
author | Al Viro <viro@ftp.linux.org.uk> | 2006-10-24 11:15:29 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-10-24 22:01:10 -0700 |
commit | 3a51237dc11efe283b40ea0248f4e26ab935dbd1 (patch) | |
tree | d27f5f2cbaea27119914186650739f281f796e77 /drivers | |
parent | 6c50444723f2e6487b3377450f90d813a88e6c31 (diff) | |
download | kernel_samsung_smdk4412-3a51237dc11efe283b40ea0248f4e26ab935dbd1.zip kernel_samsung_smdk4412-3a51237dc11efe283b40ea0248f4e26ab935dbd1.tar.gz kernel_samsung_smdk4412-3a51237dc11efe283b40ea0248f4e26ab935dbd1.tar.bz2 |
[PATCH] uml: mconsole fixes
* 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>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions