DEBUG_SHIRQ generates spurious interrupts, triggering handlers such as
mconsole_interrupt() or line_interrupt(). They expect data to be available to
be read from their sockets/pipes, but in the case of spurious interrupts, the
host didn't actually send anything, so UML hangs in read() and friends.
Setting those fd's as O_NONBLOCK makes DEBUG_SHIRQ-enabled UML kernels boot
and run correctly.
Signed-off-by: Eduard-Gabriel Munteanu <maxdamage@aladin.ro>
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
user_util.h isn't needed any more, so delete it and remove all includes of it.
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add an error message when two umids are put on the command line.
umid.h is kind of pointless since it only declares one thing, and that
is already declared in os.h.
Commented the lack of locking of some data in os-Linux/umid.h.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 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>
Fix some stack abuse in the sysrq t path.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There were a bunch of missed ARRAY_SIZE opportunities.
Also, some formatting fixes in the affected areas of code.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Handling a host mconsole version request must be done in a process context
rather than interrupt context now that utsname information can be
process-specific rather than global.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is needed for the console output patch, since we have a possibly
non-NULL-terminated string there. So, the new interface takes a string and a
length, and the old interface calls strlen on its string and calls the new
interface with the length.
There's also a bit of whitespace cleanup.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Revert commit 12ebcd73e4, i.e. [PATCH] uml: run
mconsole "sysrq" in process context on request from Jeff Dike.
a) sysrq may be run when the scheduler is non-functioning
b) the warning I wanted to fix actually came from the fault handler run in
atomic context. But I fixed that not to take the semaphore in a separate
patch.
c) the fault handler is run because of a fault, and that fault was
unaffected by this patch.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Things are breaking horribly with sysrq called in interrupt context. I want
to try to fix it, but probably this is simpler. To tell the truth, sysrq is
normally run in interrupt context, so there shouldn't be any problem.
There's also a warning from the fault handler because it's run in atomic
context (I have a patch for that, only I deferred it). This is why I'm doing
this.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The poster child for this patch is the third tuntap_user hunk. When an ioctl
fails, it properly closes the opened file descriptor and returns. However,
the close resets errno to 0, and the 'return errno' that follows returns 0
rather than the value that ioctl set. This caused the caller to believe that
the device open succeeded and had opened file descriptor 0, which caused no
end of interesting behavior.
The rest of this patch is a pass through the UML sources looking for places
where errno could be reset before being passed back out. A common culprit is
printk, which could call write, being called before errno is returned.
In some cases, where the code ends up being much smaller, I just deleted the
printk.
There was another case where a caller of run_helper looked at errno after a
failure, rather than the return value of run_helper, which was the errno value
that it wanted.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch implements a stack trace for a thread, not unlike sysrq-t does.
The advantage to this is that a break point can be placed on showreqs, so that
upon showing the stack, you jump immediately into the debugger. While sysrq-t
does the same thing, sysrq-t shows *all* threads stacks. It also doesn't work
right now. In the future, I thought it might be acceptable to make this show
all pids stacks, but perhaps leaving well enough alone and just using sysrq-t
would be okay. For now, upon receiving the stack command, UML switches
context to that thread, dumps its registers, and then switches context back to
the original thread. Since UML compacts all threads into one of 4 host
threads, this sort of mechanism could be expanded in the future to include
other debugging helpers that sysrq does not cover.
Note by jdike - The main benefit to this is that it brings an arbitrary thread
back into context, where it can be examined by gdb. The fact that it dumps it
stack is secondary. This provides the capability to examine a sleeping
thread, which has existed in tt mode, but not in skas mode until now.
Also, the other threads, that sysrq doesn't cover, can be gdb-ed directly
anyway.
Signed-off-by: Allan Graves<allan.graves@gmail.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Eduard-Gabriel Munteanu
Jeff Dike
Al Viro
Paolo 'Blaisorblade' Giarrusso
Linus Torvalds