Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-08 Thread lijiang
在 2018年10月08日 21:43, Borislav Petkov 写道:
> On Mon, Oct 08, 2018 at 10:59:09AM +0200, Borislav Petkov wrote:
>> On Mon, Oct 08, 2018 at 04:47:34PM +0800, lijiang wrote:
>>> It looks like a good way to avoid the 'ifdefined', and it's also good 
>>> enough for i386.
>>>
>>> But for other architectures, such as POWERPC/ARM..., we will also have to 
>>> add the same 
>>> function for every architecture. Otherwise, i guess that they also have a 
>>> same compile
>>> error on other architectures.
>>
>> Yap, just realized that and looking at the rest of fs/proc/vmcore.c -
>> such functions are defined with the __weak attribute. Lemme see if that
>> works better.
> 
> Seems so. I'll hammer on it more today:
> 
Great! Thank you, Borislav.

Regards,
Lianbo
> ---
>  fs/proc/vmcore.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index 42c32d06f7da..91ae16fbd7d5 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -187,6 +187,16 @@ int __weak remap_oldmem_pfn_range(struct vm_area_struct 
> *vma,
>   return remap_pfn_range(vma, from, pfn, size, prot);
>  }
>  
> +/*
> + * Architectures which support memory encryption override this.
> + */
> +ssize_t __weak
> +copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
> +unsigned long offset, int userbuf)
> +{
> + return copy_oldmem_page(pfn, buf, csize, offset, userbuf);
> +}
> +
>  /*
>   * Copy to either kernel or user space
>   */
> 


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-08 Thread Borislav Petkov
On Mon, Oct 08, 2018 at 10:59:09AM +0200, Borislav Petkov wrote:
> On Mon, Oct 08, 2018 at 04:47:34PM +0800, lijiang wrote:
> > It looks like a good way to avoid the 'ifdefined', and it's also good 
> > enough for i386.
> > 
> > But for other architectures, such as POWERPC/ARM..., we will also have to 
> > add the same 
> > function for every architecture. Otherwise, i guess that they also have a 
> > same compile
> > error on other architectures.
> 
> Yap, just realized that and looking at the rest of fs/proc/vmcore.c -
> such functions are defined with the __weak attribute. Lemme see if that
> works better.

Seems so. I'll hammer on it more today:

---
 fs/proc/vmcore.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 42c32d06f7da..91ae16fbd7d5 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -187,6 +187,16 @@ int __weak remap_oldmem_pfn_range(struct vm_area_struct 
*vma,
return remap_pfn_range(vma, from, pfn, size, prot);
 }
 
+/*
+ * Architectures which support memory encryption override this.
+ */
+ssize_t __weak
+copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+  unsigned long offset, int userbuf)
+{
+   return copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+}
+
 /*
  * Copy to either kernel or user space
  */
-- 
2.19.0.271.gfe8321ec057f

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-08 Thread Borislav Petkov
On Mon, Oct 08, 2018 at 04:47:34PM +0800, lijiang wrote:
> It looks like a good way to avoid the 'ifdefined', and it's also good enough 
> for i386.
> 
> But for other architectures, such as POWERPC/ARM..., we will also have to add 
> the same 
> function for every architecture. Otherwise, i guess that they also have a 
> same compile
> error on other architectures.

Yap, just realized that and looking at the rest of fs/proc/vmcore.c -
such functions are defined with the __weak attribute. Lemme see if that
works better.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-08 Thread lijiang
在 2018年10月08日 16:00, Borislav Petkov 写道:
> On Mon, Oct 08, 2018 at 03:11:56PM +0800, lijiang wrote:
>> I used this ".config" to compile kernel in the attachment, and got a compile 
>> error.
>> Would you like to have a try?
>>
>> [root@hp-dl385g10-03 linux]# make ARCH=i386 -j32
>>   ..
>>   LD  vmlinux.o
>>   MODPOST vmlinux.o
>> fs/proc/vmcore.o:In function ‘read_from_oldmem’:
>> /home/linux/fs/proc/vmcore.c:127:undefined reference to 
>> ‘copy_oldmem_page_encrypted’
>> make: *** [vmlinux] error 1
> 
> Thanks, that triggered here. Ok, I guess something like this, to avoid
> the ugly ifdeffery:
> 
> ---
> diff --git a/arch/x86/kernel/crash_dump_32.c b/arch/x86/kernel/crash_dump_32.c
> index 33ee47670b99..8696800f2eea 100644
> --- a/arch/x86/kernel/crash_dump_32.c
> +++ b/arch/x86/kernel/crash_dump_32.c
> @@ -80,6 +80,16 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
>   return csize;
>  }
>  
> +/*
> + * 32-bit parrot version to avoid build errors.
> + */
> +ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t 
> csize,
> +unsigned long offset, int userbuf)
> +{
> + WARN_ON_ONCE(1);
> + return copy_oldmem_page(pfn, buf, csize, offset, userbuf);
> +}
> +

It looks like a good way to avoid the 'ifdefined', and it's also good enough 
for i386.

But for other architectures, such as POWERPC/ARM..., we will also have to add 
the same 
function for every architecture. Otherwise, i guess that they also have a same 
compile
error on other architectures.

Sometimes, it's hard to make a choice.

Regards,
Lianbo
>  static int __init kdump_buf_page_init(void)
>  {
>   int ret = 0;
> 
> 
> 


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-08 Thread Borislav Petkov
On Mon, Oct 08, 2018 at 03:11:56PM +0800, lijiang wrote:
> I used this ".config" to compile kernel in the attachment, and got a compile 
> error.
> Would you like to have a try?
> 
> [root@hp-dl385g10-03 linux]# make ARCH=i386 -j32
>   ..
>   LD  vmlinux.o
>   MODPOST vmlinux.o
> fs/proc/vmcore.o:In function ‘read_from_oldmem’:
> /home/linux/fs/proc/vmcore.c:127:undefined reference to 
> ‘copy_oldmem_page_encrypted’
> make: *** [vmlinux] error 1

Thanks, that triggered here. Ok, I guess something like this, to avoid
the ugly ifdeffery:

---
diff --git a/arch/x86/kernel/crash_dump_32.c b/arch/x86/kernel/crash_dump_32.c
index 33ee47670b99..8696800f2eea 100644
--- a/arch/x86/kernel/crash_dump_32.c
+++ b/arch/x86/kernel/crash_dump_32.c
@@ -80,6 +80,16 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
return csize;
 }
 
+/*
+ * 32-bit parrot version to avoid build errors.
+ */
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+  unsigned long offset, int userbuf)
+{
+   WARN_ON_ONCE(1);
+   return copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+}
+
 static int __init kdump_buf_page_init(void)
 {
int ret = 0;



-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-08 Thread lijiang
在 2018年10月08日 13:37, Borislav Petkov 写道:
> On Mon, Oct 08, 2018 at 11:30:56AM +0800, lijiang wrote:
>> Yes. As previously mentioned, the correct patch is this one:
> 
> No, that chunk is not needed and I removed it. But I'd leave it as
> an exercise to you to figure out why... or to prove me wrong with a
> .config.
> 
> :-)
> 

I used this ".config" to compile kernel in the attachment, and got a compile 
error.
Would you like to have a try?

[root@hp-dl385g10-03 linux]# make ARCH=i386 -j32
  ..
  LD  vmlinux.o
  MODPOST vmlinux.o
fs/proc/vmcore.o:In function ‘read_from_oldmem’:
/home/linux/fs/proc/vmcore.c:127:undefined reference to 
‘copy_oldmem_page_encrypted’
make: *** [vmlinux] error 1


Regards,
Lianbo


i386_config.gz
Description: application/gzip


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread Borislav Petkov
On Mon, Oct 08, 2018 at 11:30:56AM +0800, lijiang wrote:
> Yes. As previously mentioned, the correct patch is this one:

No, that chunk is not needed and I removed it. But I'd leave it as
an exercise to you to figure out why... or to prove me wrong with a
.config.

:-)

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread lijiang
在 2018年10月07日 16:47, Borislav Petkov 写道:
> On Sun, Oct 07, 2018 at 01:55:33PM +0800, lijiang wrote:
>> Here, it may be have a compile error.
> 
> Are you sure? The configs I tried worked fine but I'm open to being
> shown configs which fail the build.
> 

Yes. As previously mentioned, the correct patch is this one:

diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 3e4ba9d753c8..84d8ddcb818e 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -26,6 +26,19 @@ extern int remap_oldmem_pfn_range(struct vm_area_struct *vma,
 
 extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
+#if defined(CONFIG_AMD_MEM_ENCRYPT) || defined(CONFIG_X86_64)
+extern ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf,
+ size_t csize, unsigned long offset,
+ int userbuf);
+#else
+static inline
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+  unsigned long offset, int userbuf)
+{
+   return 0;
+}
+#endif
+

I used the patch above to test six compile cases. All of them passed, there
was no compile error.

I'm not sure whether the kernel options or compile environment are different.
Would you like to share your kernel options(.config)? I will use your kernel
options to compile, and check whether i might also reproduce your compile 
error. 

1. x86_64 (CONFIG_X86_64=y)
   a. 
  CONFIG_AMD_MEM_ENCRYPT=y
  CONFIG_CRASH_DUMP=y

   b.
  # CONFIG_AMD_MEM_ENCRYPT is not set
  # CONFIG_CRASH_DUMP is not set

   c. 
  # CONFIG_AMD_MEM_ENCRYPT is not set
  CONFIG_CRASH_DUMP=y

   d. 
  CONFIG_AMD_MEM_ENCRYPT=y
  # CONFIG_CRASH_DUMP is not set

Compile command:
#make clean
#make ARCH=x86_64 -j32

2. i386 (CONFIG_X86_32=y)
   a. 
   CONFIG_CRASH_DUMP=y

   b.
   # CONFIG_CRASH_DUMP is not set

Compile command:
#make clean
#make ARCH=i386 -j32

Thanks.
Lianbo


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-07 Thread Borislav Petkov
On Sun, Oct 07, 2018 at 01:55:33PM +0800, lijiang wrote:
> Here, it may be have a compile error.

Are you sure? The configs I tried worked fine but I'm open to being
shown configs which fail the build.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-06 Thread lijiang
在 2018年10月06日 19:47, tip-bot for Lianbo Jiang 写道:
> Commit-ID:  992b649a3f013465d8128da02e5449def662a4c3
> Gitweb: 
> https://git.kernel.org/tip/992b649a3f013465d8128da02e5449def662a4c3
> Author: Lianbo Jiang 
> AuthorDate: Sun, 30 Sep 2018 16:37:41 +0800
> Committer:  Borislav Petkov 
> CommitDate: Sat, 6 Oct 2018 12:09:26 +0200
> 
> kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled
> 
> In the kdump kernel, the memory of the first kernel needs to be dumped
> into the vmcore file.
> 
> If SME is enabled in the first kernel, the old memory has to be remapped
> with the memory encryption mask in order to access it properly.
> 
> Split copy_oldmem_page() functionality to handle encrypted memory
> properly.
> 
>  [ bp: Heavily massage everything. ]
> 
> Signed-off-by: Lianbo Jiang 
> Signed-off-by: Borislav Petkov 
> Cc: ke...@lists.infradead.org
> Cc: t...@linutronix.de
> Cc: mi...@redhat.com
> Cc: h...@zytor.com
> Cc: a...@linux-foundation.org
> Cc: dan.j.willi...@intel.com
> Cc: bhelg...@google.com
> Cc: baiyao...@cmss.chinamobile.com
> Cc: ti...@suse.de
> Cc: brijesh.si...@amd.com
> Cc: dyo...@redhat.com
> Cc: b...@redhat.com
> Cc: jroe...@suse.de
> Link: 
> https://lkml.kernel.org/r/be7b47f9-6be6-e0d1-2c2a-9125bc74b...@redhat.com
> ---
>  arch/x86/kernel/crash_dump_64.c | 60 
> -
>  fs/proc/vmcore.c| 24 -
>  include/linux/crash_dump.h  |  4 +++
>  3 files changed, 63 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
> index 4f2e0778feac..eb8ab3915268 100644
> --- a/arch/x86/kernel/crash_dump_64.c
> +++ b/arch/x86/kernel/crash_dump_64.c
> @@ -11,40 +11,62 @@
>  #include 
>  #include 
>  
> -/**
> - * copy_oldmem_page - copy one page from "oldmem"
> - * @pfn: page frame number to be copied
> - * @buf: target memory address for the copy; this can be in kernel address
> - *   space or user address space (see @userbuf)
> - * @csize: number of bytes to copy
> - * @offset: offset in bytes into the page (based on pfn) to begin the copy
> - * @userbuf: if set, @buf is in user address space, use copy_to_user(),
> - *   otherwise @buf is in kernel address space, use memcpy().
> - *
> - * Copy a page from "oldmem". For this page, there is no pte mapped
> - * in the current kernel. We stitch up a pte, similar to kmap_atomic.
> - */
> -ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
> - size_t csize, unsigned long offset, int userbuf)
> +static ssize_t __copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
> +   unsigned long offset, int userbuf,
> +   bool encrypted)
>  {
>   void  *vaddr;
>  
>   if (!csize)
>   return 0;
>  
> - vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
> + if (encrypted)
> + vaddr = (__force void *)ioremap_encrypted(pfn << PAGE_SHIFT, 
> PAGE_SIZE);
> + else
> + vaddr = (__force void *)ioremap_cache(pfn << PAGE_SHIFT, 
> PAGE_SIZE);
> +
>   if (!vaddr)
>   return -ENOMEM;
>  
>   if (userbuf) {
> - if (copy_to_user(buf, vaddr + offset, csize)) {
> - iounmap(vaddr);
> + if (copy_to_user((void __user *)buf, vaddr + offset, csize)) {
> + iounmap((void __iomem *)vaddr);
>   return -EFAULT;
>   }
>   } else
>   memcpy(buf, vaddr + offset, csize);
>  
>   set_iounmap_nonlazy();
> - iounmap(vaddr);
> + iounmap((void __iomem *)vaddr);
>   return csize;
>  }
> +
> +/**
> + * copy_oldmem_page - copy one page of memory
> + * @pfn: page frame number to be copied
> + * @buf: target memory address for the copy; this can be in kernel address
> + *   space or user address space (see @userbuf)
> + * @csize: number of bytes to copy
> + * @offset: offset in bytes into the page (based on pfn) to begin the copy
> + * @userbuf: if set, @buf is in user address space, use copy_to_user(),
> + *   otherwise @buf is in kernel address space, use memcpy().
> + *
> + * Copy a page from the old kernel's memory. For this page, there is no pte
> + * mapped in the current kernel. We stitch up a pte, similar to kmap_atomic.
> + */
> +ssize_t copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
> +  unsigned long offset, int userbuf)
> +{
> + return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, false);
> +}
> +
> +/**
> + * copy_oldmem_page_encrypted - same as copy_oldmem_page() above but ioremap 
> the
> + * memory with the encryption mask set to accomodate kdump on SME-enabled
> + * machines.
> + */
> +ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t 
> csize,
> +unsigned long offset, int userbuf)
> +{
> + return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, true);
> +}

[tip:x86/mm] kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

2018-10-06 Thread tip-bot for Lianbo Jiang
Commit-ID:  992b649a3f013465d8128da02e5449def662a4c3
Gitweb: https://git.kernel.org/tip/992b649a3f013465d8128da02e5449def662a4c3
Author: Lianbo Jiang 
AuthorDate: Sun, 30 Sep 2018 16:37:41 +0800
Committer:  Borislav Petkov 
CommitDate: Sat, 6 Oct 2018 12:09:26 +0200

kdump, proc/vmcore: Enable kdumping encrypted memory with SME enabled

In the kdump kernel, the memory of the first kernel needs to be dumped
into the vmcore file.

If SME is enabled in the first kernel, the old memory has to be remapped
with the memory encryption mask in order to access it properly.

Split copy_oldmem_page() functionality to handle encrypted memory
properly.

 [ bp: Heavily massage everything. ]

Signed-off-by: Lianbo Jiang 
Signed-off-by: Borislav Petkov 
Cc: ke...@lists.infradead.org
Cc: t...@linutronix.de
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc: a...@linux-foundation.org
Cc: dan.j.willi...@intel.com
Cc: bhelg...@google.com
Cc: baiyao...@cmss.chinamobile.com
Cc: ti...@suse.de
Cc: brijesh.si...@amd.com
Cc: dyo...@redhat.com
Cc: b...@redhat.com
Cc: jroe...@suse.de
Link: https://lkml.kernel.org/r/be7b47f9-6be6-e0d1-2c2a-9125bc74b...@redhat.com
---
 arch/x86/kernel/crash_dump_64.c | 60 -
 fs/proc/vmcore.c| 24 -
 include/linux/crash_dump.h  |  4 +++
 3 files changed, 63 insertions(+), 25 deletions(-)

diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index 4f2e0778feac..eb8ab3915268 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -11,40 +11,62 @@
 #include 
 #include 
 
-/**
- * copy_oldmem_page - copy one page from "oldmem"
- * @pfn: page frame number to be copied
- * @buf: target memory address for the copy; this can be in kernel address
- * space or user address space (see @userbuf)
- * @csize: number of bytes to copy
- * @offset: offset in bytes into the page (based on pfn) to begin the copy
- * @userbuf: if set, @buf is in user address space, use copy_to_user(),
- * otherwise @buf is in kernel address space, use memcpy().
- *
- * Copy a page from "oldmem". For this page, there is no pte mapped
- * in the current kernel. We stitch up a pte, similar to kmap_atomic.
- */
-ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
-   size_t csize, unsigned long offset, int userbuf)
+static ssize_t __copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
+ unsigned long offset, int userbuf,
+ bool encrypted)
 {
void  *vaddr;
 
if (!csize)
return 0;
 
-   vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
+   if (encrypted)
+   vaddr = (__force void *)ioremap_encrypted(pfn << PAGE_SHIFT, 
PAGE_SIZE);
+   else
+   vaddr = (__force void *)ioremap_cache(pfn << PAGE_SHIFT, 
PAGE_SIZE);
+
if (!vaddr)
return -ENOMEM;
 
if (userbuf) {
-   if (copy_to_user(buf, vaddr + offset, csize)) {
-   iounmap(vaddr);
+   if (copy_to_user((void __user *)buf, vaddr + offset, csize)) {
+   iounmap((void __iomem *)vaddr);
return -EFAULT;
}
} else
memcpy(buf, vaddr + offset, csize);
 
set_iounmap_nonlazy();
-   iounmap(vaddr);
+   iounmap((void __iomem *)vaddr);
return csize;
 }
+
+/**
+ * copy_oldmem_page - copy one page of memory
+ * @pfn: page frame number to be copied
+ * @buf: target memory address for the copy; this can be in kernel address
+ * space or user address space (see @userbuf)
+ * @csize: number of bytes to copy
+ * @offset: offset in bytes into the page (based on pfn) to begin the copy
+ * @userbuf: if set, @buf is in user address space, use copy_to_user(),
+ * otherwise @buf is in kernel address space, use memcpy().
+ *
+ * Copy a page from the old kernel's memory. For this page, there is no pte
+ * mapped in the current kernel. We stitch up a pte, similar to kmap_atomic.
+ */
+ssize_t copy_oldmem_page(unsigned long pfn, char *buf, size_t csize,
+unsigned long offset, int userbuf)
+{
+   return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, false);
+}
+
+/**
+ * copy_oldmem_page_encrypted - same as copy_oldmem_page() above but ioremap 
the
+ * memory with the encryption mask set to accomodate kdump on SME-enabled
+ * machines.
+ */
+ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
+  unsigned long offset, int userbuf)
+{
+   return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, true);
+}
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index cbde728f8ac6..42c32d06f7da 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "internal.h"
 
@@ -98,7 +1