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 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

    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

    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

    Richard Weinberger
     

19 Jul, 2013

3 commits


02 May, 2013

1 commit


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_IDLE

    We 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

    Frederic Weisbecker
     

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 here

    Signed-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

    Sergei Trofimovich
     
  • 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

    Sergei Trofimovich
     

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

    Linus Torvalds
     
  • Signed-off-by: Al Viro

    Al Viro
     

10 Oct, 2012

1 commit


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 here

    The 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

    Miklos Szeredi
     

02 Aug, 2012

2 commits


22 May, 2012

1 commit


25 Mar, 2012

1 commit


02 Nov, 2011

18 commits


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

    Ingo van Lil
     

26 Jul, 2011

2 commits