Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and the
arch_unmap hook is called).
The architectures w
CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.
However some architectures like powerpc are keeping a reference to the vDSO
base address to build th
On 26/03/2015 19:55, Ingo Molnar wrote:
>
> * Laurent Dufour wrote:
>
>> +{
>> +unsigned long vdso_end, vdso_start;
>> +
>> +if (!mm->context.vdso_base)
>> +return;
>> +vdso_start = mm->context.vdso_base;
>> +
>> +#ifdef CONFIG_PPC64
>> +/* Calling is_32bit_task() imp
* Laurent Dufour wrote:
> +{
> + unsigned long vdso_end, vdso_start;
> +
> + if (!mm->context.vdso_base)
> + return;
> + vdso_start = mm->context.vdso_base;
> +
> +#ifdef CONFIG_PPC64
> + /* Calling is_32bit_task() implies that we are dealing with the
> + * curre
On 26/03/2015 15:17, Ingo Molnar wrote:
>
> * Laurent Dufour wrote:
>
>>> I argue we should use the right condition to clear vdso_base: if
>>> the vDSO gets at least partially unmapped. Otherwise there's
>>> little point in the whole patch: either correctly track whether
>>> the vDSO is OK, o
Masahiro Yamada (4):
kbuild: use relative path to include Makefile
kbuild: use relative path more to include Makefile
kbuild: include $(src)/Makefile rather than $(obj)/Makefile
kbuild: ia64: use $(src)/Makefile.gate rather than particular path
Makefile | 22 ++---
Prior to this commit, it was impossible to use relative path to
include Makefiles from the top level Makefile because the option
"--include-dir=$(srctree)" becomes effective when Make enters into
sub Makefiles.
To use relative path in any places, this commit moves the option
above the "sub-make" t
Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to the new sigreturn address.
This patch handles vDSO remappin
On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
>
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar wrote:
> > >
> > > > > +#define __HAVE_ARCH_REMAP
> > > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > > +
Print a more sensible message about the minimum physical memory
requirement.
Signed-off-by: Thomas Meyer
---
diff --git a/arch/um/kernel/physmem.c b/arch/um/kernel/physmem.c
index 549ecf3..a91cf05 100644
--- a/arch/um/kernel/physmem.c
+++ b/arch/um/kernel/physmem.c
@@ -63,16 +63,23 @@ void __ini
Add a kmsg_dumper, that dumps the kmsg buffer to stdout, when no console
is available. This an enables the printing of early panic() calls
triggered in uml_postsetup().
When a panic() call happens so early in the UML kernel no
earlyprintk/console is available yet, but with a kmsg_dumper in place
t
atomic_notifier_chain_register() and uml_postsetup() do call kernel code
that rely on the "current" kernel macro and a valid task_struct resp.
thread_info struct. Give those functions a valid stack by moving
uml_postsetup() in the init_thread stack. This moves enables a panic()
call in this early
12 matches
Mail list logo
