at we don't
> panic.
>
> Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com>
> Cc: Borislav Petkov <b...@alien8.de>
> Cc: Ricardo Neri <ricardo.n...@intel.com>
> Cc: Matt Fleming <m...@codeblueprint.co.uk>
> Cc: Ard Biesheuvel <a
gt; else is mapped at the virtual address we allocated for runtime service
> regions in the initial boot] - Matt Fleming
>
> Since kexec was never intended to work with efi=old_map, disable
> runtime services in kexec if booted with efi=old_map, so that we don't
> panic.
>
>
On 05/15/17 at 02:23pm, Matt Fleming wrote:
> (Pulling in Dave, Mr. Kexec on EFI)
>
> On Mon, 08 May, at 12:25:23PM, Sai Praneeth Prakhya wrote:
> > From: Sai Praneeth
> >
> > Booting kexec kernel with "efi=old_map" in kernel command line hits
> > kernel panic as
On 05/15/17 at 02:23pm, Matt Fleming wrote:
> (Pulling in Dave, Mr. Kexec on EFI)
>
> On Mon, 08 May, at 12:25:23PM, Sai Praneeth Prakhya wrote:
> > From: Sai Praneeth
> >
> > Booting kexec kernel with "efi=old_map" in kernel command line hits
> > kernel panic as shown below.
> >
> > [
1
---[ end trace f68728a0d3053b52 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Signed-off-by: Dave Young <dyo...@r
1
---[ end trace f68728a0d3053b52 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Signed-off-by: Dave Young
Tested-by: Sab
On 05/15/17 at 01:10pm, Sabrina Dubroca wrote:
> 2017-05-15, 16:37:40 +0800, Dave Young wrote:
> > Hi,
> >
> > Thanks for the report.
> > On 05/14/17 at 01:18am, Sabrina Dubroca wrote:
> > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> &g
On 05/15/17 at 01:10pm, Sabrina Dubroca wrote:
> 2017-05-15, 16:37:40 +0800, Dave Young wrote:
> > Hi,
> >
> > Thanks for the report.
> > On 05/14/17 at 01:18am, Sabrina Dubroca wrote:
> > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> > >
Hi,
Thanks for the report.
On 05/14/17 at 01:18am, Sabrina Dubroca wrote:
> 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> > From: Dave Young <dyo...@redhat.com>
> >
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the giv
Hi,
Thanks for the report.
On 05/14/17 at 01:18am, Sabrina Dubroca wrote:
> 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> > From: Dave Young
> >
> > Before invoking the arch specific handler, efi_mem_reserve() reserves
> > the given memory region through membl
On 04/27/17 at 08:52am, Dave Hansen wrote:
> On 04/27/2017 12:25 AM, Dave Young wrote:
> > On 04/21/17 at 02:55pm, Dave Hansen wrote:
> >> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
&g
On 04/27/17 at 08:52am, Dave Hansen wrote:
> On 04/27/2017 12:25 AM, Dave Young wrote:
> > On 04/21/17 at 02:55pm, Dave Hansen wrote:
> >> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
&g
Correct Vivek's email address
On 04/28/17 at 01:19pm, Dave Young wrote:
> Vivek, can you help to give some comments about the locate hole isssue
> in kexec_file?
>
> On 04/28/17 at 09:51am, AKASHI Takahiro wrote:
> > Thiago,
> >
> > Thank you for the comment.
>
Correct Vivek's email address
On 04/28/17 at 01:19pm, Dave Young wrote:
> Vivek, can you help to give some comments about the locate hole isssue
> in kexec_file?
>
> On 04/28/17 at 09:51am, AKASHI Takahiro wrote:
> > Thiago,
> >
> > Thank you for the comment.
>
Vivek, can you help to give some comments about the locate hole isssue
in kexec_file?
On 04/28/17 at 09:51am, AKASHI Takahiro wrote:
> Thiago,
>
> Thank you for the comment.
>
> On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote:
> > Hello,
> >
> > Am Mittwoch, 26. April
Vivek, can you help to give some comments about the locate hole isssue
in kexec_file?
On 04/28/17 at 09:51am, AKASHI Takahiro wrote:
> Thiago,
>
> Thank you for the comment.
>
> On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote:
> > Hello,
> >
> > Am Mittwoch, 26. April
Hi AKASHI
On 04/26/17 at 05:22pm, AKASHI Takahiro wrote:
> The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at
> the first memory region that has enough space for requested size even if
> some of higher regions may also have.
> This behavior is not consistent with
Hi AKASHI
On 04/26/17 at 05:22pm, AKASHI Takahiro wrote:
> The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at
> the first memory region that has enough space for requested size even if
> some of higher regions may also have.
> This behavior is not consistent with
On 04/21/17 at 02:55pm, Dave Hansen wrote:
> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> >
> > A new directory will be created:
> > /sys/kernel/mm/sme/
> >
> > And two entries within
On 04/21/17 at 02:55pm, Dave Hansen wrote:
> On 04/18/2017 02:22 PM, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> >
> > A new directory will be created:
> > /sys/kernel/mm/sme/
> >
> > And two entries within
Hi Xunlei,
On 04/27/17 at 01:25pm, Xunlei Pang wrote:
> On 04/27/2017 at 11:06 AM, Dave Young wrote:
> > [snip]
> >>>>>
> >>>>> static int __init crash_save_vmcoreinfo_init(void)
> >>>>> {
> >>>>> + /* One
Hi Xunlei,
On 04/27/17 at 01:25pm, Xunlei Pang wrote:
> On 04/27/2017 at 11:06 AM, Dave Young wrote:
> > [snip]
> >>>>>
> >>>>> static int __init crash_save_vmcoreinfo_init(void)
> >>>>> {
> >>>>> + /* One
[snip]
> >>>
> >>> static int __init crash_save_vmcoreinfo_init(void)
> >>> {
> >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */
> >> Can we add a comment in the VMCOREINFO_BYTES header file about the one
> >> page assumption?
> >>
> >> Or just define the
[snip]
> >>>
> >>> static int __init crash_save_vmcoreinfo_init(void)
> >>> {
> >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */
> >> Can we add a comment in the VMCOREINFO_BYTES header file about the one
> >> page assumption?
> >>
> >> Or just define the
[snip]
> >> index 43cdb00..a29e9ad 100644
> >> --- a/kernel/crash_core.c
> >> +++ b/kernel/crash_core.c
> >> @@ -15,9 +15,12 @@
> >>
> >> /* vmcoreinfo stuff */
> >> static unsigned char *vmcoreinfo_data;
> >> -size_t vmcoreinfo_size;
> >> +static size_t vmcoreinfo_size;
> >> u32
[snip]
> >> index 43cdb00..a29e9ad 100644
> >> --- a/kernel/crash_core.c
> >> +++ b/kernel/crash_core.c
> >> @@ -15,9 +15,12 @@
> >>
> >> /* vmcoreinfo stuff */
> >> static unsigned char *vmcoreinfo_data;
> >> -size_t vmcoreinfo_size;
> >> +static size_t vmcoreinfo_size;
> >> u32
On 04/26/17 at 03:28pm, Dave Young wrote:
> On 04/26/17 at 08:22am, Ingo Molnar wrote:
> >
> > * Yinghai Lu <ying...@kernel.org> wrote:
> >
> > > For x86 with recent kernel after
> > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820
On 04/26/17 at 03:28pm, Dave Young wrote:
> On 04/26/17 at 08:22am, Ingo Molnar wrote:
> >
> > * Yinghai Lu wrote:
> >
> > > For x86 with recent kernel after
> > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > &g
On 04/26/17 at 08:22am, Ingo Molnar wrote:
>
> * Yinghai Lu wrote:
>
> > For x86 with recent kernel after
> > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem.
> >
> > So here, we add
On 04/26/17 at 08:22am, Ingo Molnar wrote:
>
> * Yinghai Lu wrote:
>
> > For x86 with recent kernel after
> > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c")
> > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem.
> >
> > So here, we add handling for that
Add ia64i list, and s390 list although Michael has tested it
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> As Eric said,
> "what we need to do is move the variable vmcoreinfo_note out
> of the kernel's .bss section. And modify the code to regenerate
> and keep this information in something like
Add ia64i list, and s390 list although Michael has tested it
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> As Eric said,
> "what we need to do is move the variable vmcoreinfo_note out
> of the kernel's .bss section. And modify the code to regenerate
> and keep this information in something like
..)
> r = vscnprintf(buf, sizeof(buf), fmt, args);
> va_end(args);
>
> - r = min(r, vmcoreinfo_max_size - vmcoreinfo_size);
> + r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>
> memcpy(_data[vmcoreinfo_size], buf, r);
>
> --
> 1.8.3.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Reviewed-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
= min(r, vmcoreinfo_max_size - vmcoreinfo_size);
> + r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>
> memcpy(_data[vmcoreinfo_size], buf, r);
>
> --
> 1.8.3.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Reviewed-by: Dave Young
Thanks
Dave
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
> it has the risk of being modified by some wrong code during system
> is running.
>
> As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
> when using "crash",
On 04/20/17 at 07:39pm, Xunlei Pang wrote:
> Currently vmcoreinfo data is updated at boot time subsys_initcall(),
> it has the risk of being modified by some wrong code during system
> is running.
>
> As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
> when using "crash",
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> >
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> >
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> >
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> >
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
> signatures. The first signature
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
> signatures. The first signature
On 04/07/17 at 04:28am, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote:
> > On 04/07/17 at 08:07am, David Howells wrote:
> > > Dave Young <dyo...@redhat.com> wrote:
> > >
> > > > > > > + /* Don't permit images to
On 04/07/17 at 04:28am, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote:
> > On 04/07/17 at 08:07am, David Howells wrote:
> > > Dave Young wrote:
> > >
> > > > > > > + /* Don't permit images to be loa
On 04/07/17 at 03:45am, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 14:19 +0800, Dave Young wrote:
> > On 04/06/17 at 11:49pm, Mimi Zohar wrote:
> > > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote:
> > > > On 04/05/17 at 09:15pm, David Howells wrote:
> >
On 04/07/17 at 03:45am, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 14:19 +0800, Dave Young wrote:
> > On 04/06/17 at 11:49pm, Mimi Zohar wrote:
> > > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote:
> > > > On 04/05/17 at 09:15pm, David Howells wrot
On 04/07/17 at 08:07am, David Howells wrote:
> Dave Young <dyo...@redhat.com> wrote:
>
> > > > > + /* Don't permit images to be loaded into trusted kernels if
> > > > > we're not
> > > > > + * going to verify the signature on
On 04/07/17 at 08:07am, David Howells wrote:
> Dave Young wrote:
>
> > > > > + /* Don't permit images to be loaded into trusted kernels if
> > > > > we're not
> > > > > + * going to verify the signature on them
> > > > >
On 04/07/17 at 08:05am, David Howells wrote:
> Dave Young <dyo...@redhat.com> wrote:
>
> > > > This option allows userspace to pass the RSDP address to the kernel,
> > > > which
> > > > makes it possible for a user to circumvent any restrict
On 04/07/17 at 08:05am, David Howells wrote:
> Dave Young wrote:
>
> > > > This option allows userspace to pass the RSDP address to the kernel,
> > > > which
> > > > makes it possible for a user to circumvent any restrictions imposed on
> &
On 04/06/17 at 09:43pm, Rafael J. Wysocki wrote:
> On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote:
> > From: Josh Boyer
> >
> > This option allows userspace to pass the RSDP address to the kernel, which
> > makes it possible for a user to circumvent
On 04/06/17 at 09:43pm, Rafael J. Wysocki wrote:
> On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote:
> > From: Josh Boyer
> >
> > This option allows userspace to pass the RSDP address to the kernel, which
> > makes it possible for a user to circumvent any restrictions imposed on
> > loading
On 04/06/17 at 11:49pm, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote:
> > On 04/05/17 at 09:15pm, David Howells wrote:
> > > From: Chun-Yi Lee <joeyli.ker...@gmail.com>
> > >
> > > When KEXEC_VERIFY_SIG is not enabled, k
On 04/06/17 at 11:49pm, Mimi Zohar wrote:
> On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote:
> > On 04/05/17 at 09:15pm, David Howells wrote:
> > > From: Chun-Yi Lee
> > >
> > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
return -EPERM;
> +
> + /*
>* Verify we have a legal set of flags
>* This leaves us room for future extensions.
>*/
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
>* Verify we have a legal set of flags
>* This leaves us room for future extensions.
>*/
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young
Thanks
Dave
ABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
> + return -EPERM;
> +
> /* Make sure we have a legal set of flags */
> if (flags != (flags & KEXEC_FILE_FLAGS))
> return -EINVAL;
>
>
> _____
t; +
> /* Make sure we have a legal set of flags */
> if (flags != (flags & KEXEC_FILE_FLAGS))
> return -EINVAL;
>
>
> _______
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young
Thanks
Dave
On 04/04/17 at 02:37pm, Matt Fleming wrote:
> On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
> >
> > Matt, I'm fine if you prefer to capture the range checking errors.
> > Would you like me to post it or just you send it out?
>
> Can you please send out the pa
On 04/04/17 at 02:37pm, Matt Fleming wrote:
> On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote:
> >
> > Matt, I'm fine if you prefer to capture the range checking errors.
> > Would you like me to post it or just you send it out?
>
> Can you please send out the pa
.c fixes this problem.
> >
> > Cc: <sta...@vger.kernel.org> #4.8+
> > Signed-off-by: Baoquan He <b...@redhat.com>
> > Acked-by: Dave Young <dyo...@redhat.com>
> > Reviewed-by: Bhupesh Sharma <bhsha...@redhat.com>
> > Acked-by: Thomas Garnie
ffef - fffe (=64 GB) EFI region mapping space
> > EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END,
> > Here EFI_VA_START = -4G, and EFI_VA_END = -64G.
> >
> > Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this probl
On 03/24/17 at 04:34pm, Baoquan He wrote:
> On 03/24/17 at 09:08am, Ingo Molnar wrote:
> > > Cc: <sta...@vger.kernel.org> #4.8+
> > > Signed-off-by: Baoquan He <b...@redhat.com>
> > > Acked-by: Dave Young <dyo...@redhat.com>
> > > Revi
On 03/24/17 at 04:34pm, Baoquan He wrote:
> On 03/24/17 at 09:08am, Ingo Molnar wrote:
> > > Cc: #4.8+
> > > Signed-off-by: Baoquan He
> > > Acked-by: Dave Young
> > > Reviewed-by: Bhupesh Sharma
> > > Acked-by: Thomas Garnier
> > >
This should also cc linux-efi
On 03/24/17 at 10:29am, Dave Young wrote:
> Hi, Baoquan
>
> On 03/23/17 at 11:27am, Baoquan He wrote:
> > Currently KASLR is enabled on three regions: the direct mapping of physical
> > memory, vamlloc and vmemmap. However EFI region is als
This should also cc linux-efi
On 03/24/17 at 10:29am, Dave Young wrote:
> Hi, Baoquan
>
> On 03/23/17 at 11:27am, Baoquan He wrote:
> > Currently KASLR is enabled on three regions: the direct mapping of physical
> > memory, vamlloc and vmemmap. However EFI region is als
ping space
> EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END
> Here EFI_VA_START = -4G, and EFI_VA_END = -64G
>
> Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
>
> Cc: <sta...@vger.kernel.org> #4.8+
> Signed-off-by: B
ping space
> EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END
> Here EFI_VA_START = -4G, and EFI_VA_END = -64G
>
> Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.
>
> Cc: #4.8+
> Signed-off-by: Baoquan He
> Acked-by: Dave Youn
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young <dyo...@redhat.com> wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wr
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> >
On 03/21/17 at 10:18pm, Eric W. Biederman wrote:
> Dave Young <dyo...@redhat.com> writes:
>
> > On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
> >> Xunlei Pang <xlp...@redhat.com> writes:
> >>
> >> > As Eric said,
> >>
On 03/21/17 at 10:18pm, Eric W. Biederman wrote:
> Dave Young writes:
>
> > On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
> >> Xunlei Pang writes:
> >>
> >> > As Eric said,
> >> > "what we need to do is move the variable vmcoreinf
On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
> Xunlei Pang writes:
>
> > As Eric said,
> > "what we need to do is move the variable vmcoreinfo_note out
> > of the kernel's .bss section. And modify the code to regenerate
> > and keep this information in something like the
On 03/20/17 at 10:33pm, Eric W. Biederman wrote:
> Xunlei Pang writes:
>
> > As Eric said,
> > "what we need to do is move the variable vmcoreinfo_note out
> > of the kernel's .bss section. And modify the code to regenerate
> > and keep this information in something like the control page.
> >
>
On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > >
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup
On 03/20/17 at 10:14am, Dave Young wrote:
> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> > >
> > > Matt, I think it should be fine although I think the md type checking in
> > > efi_mem_desc_lookup
On 03/17/17 at 01:32pm, Matt Fleming wrote:
> On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >
> > Matt, I think it should be fine although I think the md type checking in
> > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> Could you
On 03/17/17 at 01:32pm, Matt Fleming wrote:
> On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >
> > Matt, I think it should be fine although I think the md type checking in
> > efi_mem_desc_lookup() is causing confusion and not easy to understand..
>
> Could you
On 03/16/17 at 12:41pm, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is
> > not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> >
On 03/16/17 at 12:41pm, Matt Fleming wrote:
> On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote:
> >
> > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is
> > not
> > correct to be used in efi_arch_mem_reserve, if it passed your test, I
> >
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, bu
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, bu
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, bu
On 03/09/17 at 01:54am, Omar Sandoval wrote:
> On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> > Add efi/kexec list.
> >
> > On 03/08/17 at 12:16pm, Omar Sandoval wrote:
>
> [snip]
>
> > I have no more clue yet from your provided log, bu
On 03/09/17 at 12:53pm, Ard Biesheuvel wrote:
> On 9 March 2017 at 10:54, Omar Sandoval <osan...@osandov.com> wrote:
> > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> >> Add efi/kexec list.
> >>
> >> On 03/08/17 at 12:16pm, Omar Sand
On 03/09/17 at 12:53pm, Ard Biesheuvel wrote:
> On 9 March 2017 at 10:54, Omar Sandoval wrote:
> > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote:
> >> Add efi/kexec list.
> >>
> >> On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> >
> > [
Add efi/kexec list.
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [0.001000] general protection fault: [#1] SMP
> [0.001000] Modules linked in:
> [0.001000] CPU: 0 PID: 0 Comm:
Add efi/kexec list.
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [0.001000] general protection fault: [#1] SMP
> [0.001000] Modules linked in:
> [0.001000] CPU: 0 PID: 0 Comm:
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [0.001000] general protection fault: [#1] SMP
> [0.001000] Modules linked in:
> [0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
On 03/08/17 at 12:16pm, Omar Sandoval wrote:
> Hi, everyone,
>
> Since 4.9, kexec results in the following panic on some of our servers:
>
> [0.001000] general protection fault: [#1] SMP
> [0.001000] Modules linked in:
> [0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
Hi,
On 03/08/17 at 04:45pm, Baoquan He wrote:
> Forgot cc to Boris, add him.
>
> On 03/08/17 at 04:18pm, Dave Young wrote:
> > On 03/08/17 at 03:47pm, Baoquan He wrote:
> > > EFI allocate runtime services regions down from EFI_VA_START, -4G.
> > &g
Hi,
On 03/08/17 at 04:45pm, Baoquan He wrote:
> Forgot cc to Boris, add him.
>
> On 03/08/17 at 04:18pm, Dave Young wrote:
> > On 03/08/17 at 03:47pm, Baoquan He wrote:
> > > EFI allocate runtime services regions down from EFI_VA_START, -4G.
> > &g
On 03/08/17 at 11:50am, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 06:17:50PM +0800, Baoquan He wrote:
> > All right, I will just update the code comment. Just back ported kaslr
> > to our OS product, people reviewed and found the upper boundary of kaslr
> > mm region is EFI_VA_START, that's
On 03/08/17 at 11:50am, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 06:17:50PM +0800, Baoquan He wrote:
> > All right, I will just update the code comment. Just back ported kaslr
> > to our OS product, people reviewed and found the upper boundary of kaslr
> > mm region is EFI_VA_START, that's
_X86_ESPFIX64) ||
> IS_ENABLED(CONFIG_EFI)) &&
>vaddr_end >= __START_KERNEL_map);
> --
> 2.5.5
>
Acked-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
IS_ENABLED(CONFIG_EFI)) &&
>vaddr_end >= __START_KERNEL_map);
> --
> 2.5.5
>
Acked-by: Dave Young
Thanks
Dave
On 03/08/17 at 03:47pm, Baoquan He wrote:
> EFI allocate runtime services regions down from EFI_VA_START, -4G.
> It should be top-down handling.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/platform/efi/efi_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On 03/08/17 at 03:47pm, Baoquan He wrote:
> EFI allocate runtime services regions down from EFI_VA_START, -4G.
> It should be top-down handling.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/platform/efi/efi_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 03/06/17 at 11:58am, Tom Lendacky wrote:
> On 3/1/2017 3:25 AM, Dave Young wrote:
> > Hi Tom,
>
> Hi Dave,
>
> >
> > On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, F
On 03/06/17 at 11:58am, Tom Lendacky wrote:
> On 3/1/2017 3:25 AM, Dave Young wrote:
> > Hi Tom,
>
> Hi Dave,
>
> >
> > On 02/17/17 at 10:43am, Tom Lendacky wrote:
> > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, F
501 - 600 of 2643 matches
Mail list logo