07 Sep, 2013
4 commits
-
If UML is not run by a shell it can happen that UML
will kill unrelated proceses upon a fatal exit because
it issues a kill(0, ...).
To prevent such oddities we create a new session in main().Reported-and-tested-by: Richard W.M. Jones
Signed-off-by: Richard Weinberger -
Richard reported that some UML processes survive if the UML
main process receives a SIGTERM.
This issue was caused by a wrongly placed signal(SIGTERM, SIG_DFL)
in init_new_thread_signals().
It disabled the UML exit handler accidently for some processes.
The correct solution is to disable the fatal handler for all
UML helper threads/processes.
Such that last_ditch_exit() does not get called multiple times
and all processes can exit due to SIGTERM.Reported-and-tested-by: Richard W.M. Jones
Signed-off-by: Richard Weinberger -
UML's block device driver does not support write barriers,
to support this this patch adds REQ_FLUSH suppport.
Every time the block layer sends a REQ_FLUSH we fsync() now
our backing file to guarantee data consistency.Reported-and-tested-by: Richard W.M. Jones
Signed-off-by: Richard Weinberger -
UML needs it's own probe_kernel_read() to handle kernel
mode faults correctly.
The implementation uses mincore() on the host side to detect
whether a page is owned by the UML kernel process.This fixes also a possible crash when sysrq-t is used.
Starting with 3.10 sysrq-t calls probe_kernel_read() to
read details from the kernel workers. As kernel worker are
completely async pointers may turn NULL while reading them.Cc:
Cc:
Cc: # 3.10.x
Signed-off-by: Richard Weinberger
19 Jul, 2013
3 commits
-
Currently we use both struct siginfo and siginfo_t.
Let's use struct siginfo internally to avoid ongoing
compiler warning. We are allowed to do so because
struct siginfo and siginfo_t are equivalent.Signed-off-by: Richard Weinberger
-
which_tmpdir did the wrong thing if /dev/shm was a symlink (e.g., to /run/shm),
if there were multiple mounts on top of each other, if the mount(s) were
obscured by a later mount, or if /dev/shm was a prefix of another mount point.
This fixes these cases. Applies to 3.9.6.Signed-off-by: Tristan Schmelcher
Signed-off-by: Richard Weinberger -
If we die within a stub handler we only way to reliable
kill the (obviously) dying uml guest process is killing
it's host twin on the host side.Signed-off-by: Richard Weinberger
02 May, 2013
1 commit
-
The full dynticks tree needs the latest RCU and sched
upstream updates in order to fix some dependencies.Merge a common upstream merge point that has these
updates.Conflicts:
include/linux/perf_event.h
kernel/rcutree.h
kernel/rcutree_plugin.hSigned-off-by: Frederic Weisbecker
03 Apr, 2013
1 commit
-
We are planning to convert the dynticks Kconfig options layout
into a choice menu. The user must be able to easily pick
any of the following implementations: constant periodic tick,
idle dynticks, full dynticks.As this implies a mutual exclusion, the two dynticks implementions
need to converge on the selection of a common Kconfig option in order
to ease the sharing of a common infrastructure.It would thus seem pretty natural to reuse CONFIG_NO_HZ to
that end. It already implements all the idle dynticks code
and the full dynticks depends on all that code for now.
So ideally the choice menu would propose CONFIG_NO_HZ_IDLE and
CONFIG_NO_HZ_EXTENDED then both would select CONFIG_NO_HZ.On the other hand we want to stay backward compatible: if
CONFIG_NO_HZ is set in an older config file, we want to
enable CONFIG_NO_HZ_IDLE by default.But we can't afford both at the same time or we run into
a circular dependency:1) CONFIG_NO_HZ_IDLE and CONFIG_NO_HZ_EXTENDED both select
CONFIG_NO_HZ
2) If CONFIG_NO_HZ is set, we default to CONFIG_NO_HZ_IDLEWe might be able to support that from Kconfig/Kbuild but it
may not be wise to introduce such a confusing behaviour.So to solve this, create a new CONFIG_NO_HZ_COMMON option
which gathers the common code between idle and full dynticks
(that common code for now is simply the idle dynticks code)
and select it from their referring Kconfig.Then we'll later create CONFIG_NO_HZ_IDLE and map CONFIG_NO_HZ
to it for backward compatibility.Signed-off-by: Frederic Weisbecker
Cc: Andrew Morton
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Geoff Levand
Cc: Gilad Ben Yossef
Cc: Hakan Akkan
Cc: Ingo Molnar
Cc: Kevin Hilman
Cc: Li Zhong
Cc: Namhyung Kim
Cc: Paul E. McKenney
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
11 Mar, 2013
2 commits
-
arch/um/os-Linux/signal.c:18:8: error: conflicting types for 'sig_info'
In file included from /home/slyfox/linux-2.6/arch/um/os-Linux/signal.c:12:0:
arch/um/include/shared/as-layout.h:64:15: note: previous declaration of 'sig_info' was hereSigned-off-by: Sergei Trofimovich
CC: Jeff Dike
CC: Richard Weinberger
CC: "Martin Pärtel"
CC: Al Viro
CC: user-mode-linux-devel@lists.sourceforge.net
CC: user-mode-linux-user@lists.sourceforge.net
CC: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger -
arch/um/os-Linux/start_up.c: In function 'check_coredump_limit':
arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known
arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration]Signed-off-by: Sergei Trofimovich
CC: Jeff Dike
CC: Richard Weinberger
CC: Al Viro
CC: user-mode-linux-devel@lists.sourceforge.net
CC: user-mode-linux-user@lists.sourceforge.net
CC: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger
13 Oct, 2012
2 commits
-
Pull third pile of kernel_execve() patches from Al Viro:
"The last bits of infrastructure for kernel_thread() et.al., with
alpha/arm/x86 use of those. Plus sanitizing the asm glue and
do_notify_resume() on alpha, fixing the "disabled irq while running
task_work stuff" breakage there.At that point the rest of kernel_thread/kernel_execve/sys_execve work
can be done independently for different architectures. The only
pending bits that do depend on having all architectures converted are
restrictred to fs/* and kernel/* - that'll obviously have to wait for
the next cycle.I thought we'd have to wait for all of them done before we start
eliminating the longjump-style insanity in kernel_execve(), but it
turned out there's a very simple way to do that without flagday-style
changes."* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal:
alpha: switch to saner kernel_execve() semantics
arm: switch to saner kernel_execve() semantics
x86, um: convert to saner kernel_execve() semantics
infrastructure for saner ret_from_kernel_thread semantics
make sure that kernel_thread() callbacks call do_exit() themselves
make sure that we always have a return path from kernel_execve()
ppc: eeh_event should just use kthread_run()
don't bother with kernel_thread/kernel_execve for launching linuxrc
alpha: get rid of switch_stack argument of do_work_pending()
alpha: don't bother passing switch_stack separately from regs
alpha: take SIGPENDING/NOTIFY_RESUME loop into signal.c
alpha: simplify TIF_NEED_RESCHED handling -
Signed-off-by: Al Viro
10 Oct, 2012
1 commit
-
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger
06 Sep, 2012
1 commit
-
Fix the following compile error on UML.
arch/um/os-Linux/time.c: In function 'deliver_alarm':
arch/um/os-Linux/time.c:117:3: error: too few arguments to function 'alarm_handler'
arch/um/os-Linux/internal.h:1:6: note: declared hereThe error was introduced by commit d3c1cfcd ("um: pass siginfo to guest
process") in 3.6-rc1.Signed-off-by: Miklos Szeredi
CC: Martin Pärtel
Signed-off-by: Linus Torvalds
02 Aug, 2012
2 commits
-
UML guest processes now get correct siginfo_t for SIGTRAP, SIGFPE,
SIGILL and SIGBUS. Specifically, si_addr and si_code are now correct
where previously they were si_addr = NULL and si_code = 128.Signed-off-by: Martin Pärtel
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger
22 May, 2012
1 commit
-
Signed-off-by: Richard Weinberger
25 Mar, 2012
1 commit
-
... the same one that controls whether elf_aux.o is included into the
build, bringing the vsyscall_e... into it.Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger
02 Nov, 2011
18 commits
-
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
it's i386-specific; moreover, analogs on other targets have
incompatible interface - PTRACE_GET_THREAD_AREA does exist
elsewhere, but struct user_desc does *not*Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
now we don't mix host and guest signal frame layouts anymore; moreover,
we don't need host's struct sigcontext at all.Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
For one thing, we always block the same signals (IRQ ones - IO, WINCH, VTALRM),
so there's no need to pass sa_mask elements in arguments. For another, the
flags depend only on whether it's an IRQ signal or not (we add SA_RESTART
for them).Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
We used to generate those, but we hadn't done that for a long
time. No need to bother blocking them for signal handlers.Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger -
Signed-off-by: Al Viro
Signed-off-by: Richard Weinberger
15 Sep, 2011
1 commit
-
Some time ago Jeff prepared 42daba316557 ("uml: stop saving process FP
state") for UML to stop saving the process FP state between task
switches. The assumption was that since with SKAS0 every guest process
runs inside a host process context the host OS will take care of keeping
the proper FP state.Unfortunately this is not true for multi-threaded applications, where
all guest threads share a single host process context yet all may use
the FPU on their own. Although I haven't verified it I suspect things
to be even worse in SKAS3 mode where all guest processes run inside a
single host process.The patch reintroduces the saving and restoring of the FP context
between task switches.[richard@nod.at: Ingo posted this patch in 2009, sadly it was never applied
and got lost. Now in 2011 the problem was reported by Gunnar.]Signed-off-by: Ingo van Lil
Signed-off-by: Richard Weinberger
Reported-by:
Tested-by:
Cc: Stanislav Meduna
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jul, 2011
2 commits
-
Reusing the host's vDSO makes only sense on x86_32.
Signed-off-by: Richard Weinberger
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
When creating the temp file there's a memory and file descriptor leak upon
error.Signed-off-by: Davidlohr Bueso
Signed-off-by: Richard Weinberger
Reviewed-by: Vitaliy Ivanov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds