[uml-user] [PATCH v4 1/2] mm: Introducing arch_remap hook
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 which need to call this hook should define
__HAVE_ARCH_REMAP in their asm/mmu_context.h and provide the arch_remap
service with the following prototype:
void arch_remap(struct mm_struct *mm,
unsigned long old_start, unsigned long old_end,
unsigned long new_start, unsigned long new_end);
Signed-off-by: Laurent Dufour
---
mm/mremap.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 57dadc025c64..bafc234db45c 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include "internal.h"
@@ -286,8 +287,14 @@ static unsigned long move_vma(struct vm_area_struct *vma,
old_len = new_len;
old_addr = new_addr;
new_addr = -ENOMEM;
- } else if (vma->vm_file && vma->vm_file->f_op->mremap)
- vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+ } else {
+ if (vma->vm_file && vma->vm_file->f_op->mremap)
+ vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+ arch_remap(mm, old_addr, old_addr+old_len,
+ new_addr, new_addr+new_len);
+#endif
+ }
/* Conceal VM_ACCOUNT so old reservation is not undone */
if (vm_flags & VM_ACCOUNT) {
--
1.9.1
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
[uml-user] [PATCH v4 0/2] Tracking user space vDSO remaping
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 the signal return stack frame by calling the vDSO sigreturn service. So once the vDSO has been moved, this reference is no more valid and the signal frame built later are not usable. This patch serie is introducing a new mm hook 'arch_remap' which is called when mremap is done and the mm lock still hold. The next patch is adding the vDSO remap and unmap tracking to the powerpc architecture. Changes in v4: -- - Reviewing the PowerPC part of the patch to handle partial unmap and remap of the vDSO. Changes in v3: -- - Fixed grammatical error in a comment of the second patch. Thanks again, Ingo. Changes in v2: -- - Following the Ingo Molnar's advice, enabling the call to arch_remap through the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch. Laurent Dufour (2): mm: Introducing arch_remap hook powerpc/mm: Tracking vDSO remap arch/powerpc/include/asm/mmu_context.h | 32 +++- arch/powerpc/kernel/vdso.c | 39 ++ mm/mremap.c| 11 -- 3 files changed, 79 insertions(+), 3 deletions(-) -- 1.9.1 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
[uml-user] [PATCH 0/4] kbuild: refactor Makefile inclusion
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 ++ arch/arm/boot/Makefile| 2 +- arch/ia64/kernel/Makefile | 2 +- arch/mips/Makefile| 2 +- arch/um/Makefile | 6 +++--- arch/x86/Makefile | 2 +- arch/x86/Makefile.um | 2 +- scripts/Makefile.dtbinst | 2 +- scripts/Makefile.fwinst | 2 +- 9 files changed, 20 insertions(+), 22 deletions(-) -- 1.9.1 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
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,
> > > > > + unsigned long old_start, unsigned long
> > > > > old_end,
> > > > > + unsigned long new_start, unsigned long
> > > > > new_end)
> > > > > +{
> > > > > + /*
> > > > > + * mremap() doesn't allow moving multiple vmas so we can limit
> > > > > the
> > > > > + * check to old_start == vdso_base.
> > > > > + */
> > > > > + if (old_start == mm->context.vdso_base)
> > > > > + mm->context.vdso_base = new_start;
> > > > > +}
> > > >
> > > > mremap() doesn't allow moving multiple vmas, but it allows the
> > > > movement of multi-page vmas and it also allows partial mremap()s,
> > > > where it will split up a vma.
> > >
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that
> > > case mremap() will unmap the end of the vma and will shrink the
> > > remaining vDSO vma.
> > >
> > > Doesn't that result in a non-working vDSO that should zero out
> > > vdso_base?
> >
> > Right. Now we can't completely prevent the user from shooting itself
> > in the foot I suppose, though there is a legit usage scenario which
> > is to move the vDSO around which it would be nice to support. I
> > think it's reasonable to put the onus on the user here to do the
> > right thing.
>
> 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, or
> don't ...
Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.
> There's also the question of mprotect(): can users mprotect() the vDSO
> on PowerPC?
Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).
Cheers,
Ben.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
[uml-user] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap
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 remapping and unmapping.
Moving or unmapping partially the vDSO lead to invalidate it from the
kernel point of view.
Signed-off-by: Laurent Dufour
---
arch/powerpc/include/asm/mmu_context.h | 32 +++-
arch/powerpc/kernel/vdso.c | 39 ++
2 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 73382eba02dc..67734ce8be67 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
#include
#include
#include
-#include
#include
/*
@@ -109,5 +108,36 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
#endif
}
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+extern void arch_vdso_remap(struct mm_struct *mm,
+ unsigned long old_start, unsigned long old_end,
+ unsigned long new_start, unsigned long new_end);
+static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ arch_vdso_remap(mm, start, end, 0, 0);
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+ unsigned long old_start, unsigned long old_end,
+ unsigned long new_start, unsigned long new_end)
+{
+ arch_vdso_remap(mm, old_start, old_end, new_start, new_end);
+}
+
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_MMU_CONTEXT_H */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 305eb0d9b768..a11b5d8f36d6 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -283,6 +283,45 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
return rc;
}
+void arch_vdso_remap(struct mm_struct *mm,
+unsigned long old_start, unsigned long old_end,
+unsigned long new_start, unsigned long new_end)
+{
+ 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
+* current process memory. If there is a call path where mm is not
+* owned by the current task, then we'll have need to store the
+* vDSO size in the mm->context.
+*/
+ BUG_ON(current->mm != mm);
+ if (is_32bit_task())
+ vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+ else
+ vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+ vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+ vdso_end += (1context.vdso_base = 0;
+ }
+}
+
const char *arch_vma_name(struct vm_area_struct *vma)
{
if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
--
1.9.1
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap
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() implies that we are dealing with the
>> + * current process memory. If there is a call path where mm is not
>> + * owned by the current task, then we'll have need to store the
>> + * vDSO size in the mm->context.
>> + */
>> +BUG_ON(current->mm != mm);
>> +if (is_32bit_task())
>> +vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +else
>> +vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
>> +#else
>> +vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +#endif
>> +vdso_end += (1<> +
>> +/* Check if the vDSO is in the range of the remapped area */
>> +if ((vdso_start <= old_start && old_start < vdso_end) ||
>> +(vdso_start < old_end && old_end <= vdso_end) ||
>> +(old_start <= vdso_start && vdso_start < old_end)) {
>> +/* Update vdso_base if the vDSO is entirely moved. */
>> +if (old_start == vdso_start && old_end == vdso_end &&
>> +(old_end - old_start) == (new_end - new_start))
>> +mm->context.vdso_base = new_start;
>> +else
>> +mm->context.vdso_base = 0;
>> +}
>> +}
>
> Oh my, that really looks awfully complex, as you predicted, and right
> in every mremap() call.
I do agree, that's awfully complex ;)
> I'm fine with your original, imperfect, KISS approach. Sorry about
> this detour ...
>
> Reviewed-by: Ingo Molnar
No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?
Thanks,
Laurent.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap
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, or don't ... >> >> That's a good option, but it may be hard to achieve in the case the >> vDSO area has been splitted in multiple pieces. >> >> Not sure there is a right way to handle that, here this is a best >> effort, allowing a process to unmap its vDSO and having the >> sigreturn call done through the stack area (it has to make it >> executable). >> >> Anyway I'll dig into that, assuming that the vdso_base pointer >> should be clear if a part of the vDSO is moved or unmapped. The >> patch will be larger since I'll have to get the vDSO size which is >> private to the vdso.c file. > > At least for munmap() I don't think that's a worry: once unmapped > (even if just partially), vdso_base becomes zero and won't ever be set > again. > > So no need to track the zillion pieces, should there be any: Humpty > Dumpty won't be whole again, right? My idea is to clear vdso_base if at least part of the vdso is unmap. But since some part of the vdso may have been moved and unmapped later, to be complete, the patch has to handle partial mremap() of the vDSO too. Otherwise such a scenario will not be detected: new_area = mremap(vdso_base + page_size, ); munmap(new_area,...); >>> There's also the question of mprotect(): can users mprotect() the >>> vDSO on PowerPC? >> >> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and >> certainly all the other architectures. Furthermore, if it is done on >> a partial part of the vDSO it is splitting the vma... > > btw., CRIU's main purpose here is to reconstruct a vDSO that was > originally randomized, but whose address must now be reproduced as-is, > right? You're right, CRIU has to move the vDSO to the same address it has at checkpoint time. > In that sense detecting the 'good' mremap() as your patch does should > do the trick and is certainly not objectionable IMHO - I was just > wondering whether we could make a perfect job very simply. I'd try to address the perfect job, this may complexify the patch, especially because the vdso's size is not recorded in the PowerPC mm_context structure. Not sure it is a good idea to extend that structure.. Thanks, Laurent. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
Re: [uml-user] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap
* 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
> + * current process memory. If there is a call path where mm is not
> + * owned by the current task, then we'll have need to store the
> + * vDSO size in the mm->context.
> + */
> + BUG_ON(current->mm != mm);
> + if (is_32bit_task())
> + vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> + else
> + vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
> +#else
> + vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +#endif
> + vdso_end += (1< +
> + /* Check if the vDSO is in the range of the remapped area */
> + if ((vdso_start <= old_start && old_start < vdso_end) ||
> + (vdso_start < old_end && old_end <= vdso_end) ||
> + (old_start <= vdso_start && vdso_start < old_end)) {
> + /* Update vdso_base if the vDSO is entirely moved. */
> + if (old_start == vdso_start && old_end == vdso_end &&
> + (old_end - old_start) == (new_end - new_start))
> + mm->context.vdso_base = new_start;
> + else
> + mm->context.vdso_base = 0;
> + }
> +}
Oh my, that really looks awfully complex, as you predicted, and right
in every mremap() call.
I'm fine with your original, imperfect, KISS approach. Sorry about
this detour ...
Reviewed-by: Ingo Molnar
Thanks,
Ingo
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
[uml-user] [PATCH 2/4] kbuild: use relative path more to include Makefile
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" target. Signed-off-by: Masahiro Yamada --- Makefile | 22 ++ arch/mips/Makefile | 2 +- arch/um/Makefile | 6 +++--- arch/x86/Makefile| 2 +- arch/x86/Makefile.um | 2 +- 5 files changed, 16 insertions(+), 18 deletions(-) diff --git a/Makefile b/Makefile index cc68048..402ff77 100644 --- a/Makefile +++ b/Makefile @@ -10,9 +10,10 @@ NAME = Hurr durr I'ma sheep # Comments in this file are targeted only to the developer, do not # expect to learn how to build the kernel reading this file. -# Do not use make's built-in rules and variables -# (this increases performance and avoids hard-to-debug behaviour); -MAKEFLAGS += -rR +# o Do not use make's built-in rules and variables +# (this increases performance and avoids hard-to-debug behaviour); +# o Look for make include files relative to root of kernel src +MAKEFLAGS += -rR --include-dir=$(CURDIR) # Avoid funny character set dependencies unexport LC_ALL @@ -344,12 +345,9 @@ endif export COMPILER endif -# Look for make include files relative to root of kernel src -MAKEFLAGS += --include-dir=$(srctree) - # We need some generic definitions (do not try to remake the file). -$(srctree)/scripts/Kbuild.include: ; -include $(srctree)/scripts/Kbuild.include +scripts/Kbuild.include: ; +include scripts/Kbuild.include # Make variables (CC, etc...) AS = $(CROSS_COMPILE)as @@ -533,7 +531,7 @@ ifeq ($(config-targets),1) # Read arch specific Makefile to set KBUILD_DEFCONFIG as needed. # KBUILD_DEFCONFIG may point out an alternative default configuration # used for 'make defconfig' -include $(srctree)/arch/$(SRCARCH)/Makefile +include arch/$(SRCARCH)/Makefile export KBUILD_DEFCONFIG KBUILD_KCONFIG config: scripts_basic outputmakefile FORCE @@ -609,7 +607,7 @@ endif # $(dot-config) # Defaults to vmlinux, but the arch makefile usually adds further targets all: vmlinux -include $(srctree)/arch/$(SRCARCH)/Makefile +include arch/$(SRCARCH)/Makefile KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,) @@ -781,8 +779,8 @@ ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y) KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO endif -include $(srctree)/scripts/Makefile.kasan -include $(srctree)/scripts/Makefile.extrawarn +include scripts/Makefile.kasan +include scripts/Makefile.extrawarn # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments KBUILD_CPPFLAGS += $(KCPPFLAGS) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 8f57fc7..d152dfb 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -225,7 +225,7 @@ endif # # Board-dependent options and extra files # -include $(srctree)/arch/mips/Kbuild.platforms +include arch/mips/Kbuild.platforms ifdef CONFIG_PHYSICAL_START load-y = $(CONFIG_PHYSICAL_START) diff --git a/arch/um/Makefile b/arch/um/Makefile index e4b1a96..17d4460 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -43,8 +43,8 @@ endif HOST_DIR := arch/$(HEADER_ARCH) -include $(srctree)/$(ARCH_DIR)/Makefile-skas -include $(srctree)/$(HOST_DIR)/Makefile.um +include $(ARCH_DIR)/Makefile-skas +include $(HOST_DIR)/Makefile.um core-y += $(HOST_DIR)/um/ @@ -73,7 +73,7 @@ USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\ $(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64 -idirafter include #This will adjust *FLAGS accordingly to the platform. -include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS) +include $(ARCH_DIR)/Makefile-os-$(OS) KBUILD_CPPFLAGS += -I$(srctree)/$(HOST_DIR)/include \ -I$(srctree)/$(HOST_DIR)/include/uapi \ diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 5ba2d9c..2fda005 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -63,7 +63,7 @@ ifeq ($(CONFIG_X86_32),y) $(call cc-option,-fno-unit-at-a-time)) # CPU-specific tuning. Anything which can be shared with UML should go here. -include $(srctree)/arch/x86/Makefile_32.cpu +include arch/x86/Makefile_32.cpu KBUILD_CFLAGS += $(cflags-y) # temporary until string.h is fixed diff --git a/arch/x86/Makefile.um b/arch/x86/Makefile.um index 95eba55..5b7e898 100644 --- a/arch/x86/Makefile.um +++ b/arch/x86/Makefile.um @@ -18,7 +18,7 @@ LDS_EXTRA := -Ui386 export LDS_EXTRA # First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y. -include $(srctree)/arch/x86/Makefile_32.cpu +include arch/x86/Makefile_32.cpu # prevent gcc from keeping the stack 16 byte aligned. Taken from i386. cflags-y += $(call cc-option,-mpreferred-stack-boundary=2) -- 1.9.1 -
