On 04/16/21 at 01:28pm, Mike Galbraith wrote:
> On Fri, 2021-04-16 at 19:07 +0800, Dave Young wrote:
> >
> > > We're excluding two ranges, allocate the scratch space we need to do that.
> >
> > I think 1 range should be fine, have you tested 1?
>
> Have now,
Hi Mike,
Thanks for the patch! I suggest always cc kexec list for kexec/kdump
patches.
On 04/15/21 at 07:56pm, Mike Galbraith wrote:
> x86/crash: fix crash_setup_memmap_entries() KASAN vmalloc-out-of-bounds gripe
>
> [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
>
_cmdline, "auto", 4) == 0) {
> + ck_cmdline = CONFIG_CRASH_AUTO_STR;
> + pr_info("Using crashkernel=auto, the size chosen is a best
> effort estimation.\n");
> + }
> +#endif
> /*
>* if the commandline contains a ':', then that's the extended
>* syntax -- if not, it must be the classic syntax
> --
> 2.27.0
>
Acked-by: Dave Young
Thanks
Dave
> Can we get this reviewed and staged ?
> > >
> > > Thank you.
> >
> > Andrew,
> >
> > Seems you are the only one pushing patches in for kexec/crash. Is this
> > maintained by anyone?
>
> Dave Young and Baoquan He still maintain k
ifdef CONFIG_CRASH_AUTO_STR
> + if (strncmp(ck_cmdline, "auto", 4) == 0) {
> + ck_cmdline = CONFIG_CRASH_AUTO_STR;
> + pr_info("Using crashkernel=auto, the size chosen is a best
> effort estimation.\n");
> + }
> +#endif
> /*
>* if the commandline contains a ':', then that's the extended
>* syntax -- if not, it must be the classic syntax
> --
> 2.27.0
>
Acked-by: Dave Young
Thanks
Dave
Hi Saeed,
On 02/03/21 at 04:43pm, Saeed Mirzamohammadi wrote:
> This adds crashkernel=auto feature to configure reserved memory for
> vmcore creation. CONFIG_CRASH_AUTO_STR is defined to be set for
> different kernel distributions and different archs based on their
> needs.
>
> Signed-off-by:
On 01/23/21 at 11:51am, Dave Young wrote:
> Hi Saeed,
> On 01/22/21 at 05:14pm, Saeed Mirzamohammadi wrote:
> > Hi,
> >
> > > On Jan 21, 2021, at 7:12 PM, Dave Young wrote:
> > >
> > > On 01/22/21 at 09:22am, Dave Young wrote:
> > >> Hi
Hi Saeed,
On 01/22/21 at 05:14pm, Saeed Mirzamohammadi wrote:
> Hi,
>
> > On Jan 21, 2021, at 7:12 PM, Dave Young wrote:
> >
> > On 01/22/21 at 09:22am, Dave Young wrote:
> >> Hi John,
> >>
> >> On 01/21/21 at 09:32am, john.p.donne...@orac
On 01/22/21 at 09:22am, Dave Young wrote:
> Hi John,
>
> On 01/21/21 at 09:32am, john.p.donne...@oracle.com wrote:
> > On 11/22/20 9:47 PM, Dave Young wrote:
> > > Hi Guilherme,
> > > On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
> > > > Hi D
Hi John,
On 01/21/21 at 09:32am, john.p.donne...@oracle.com wrote:
> On 11/22/20 9:47 PM, Dave Young wrote:
> > Hi Guilherme,
> > On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
> > > Hi Dave and Kairui, thanks for your responses! OK, if that makes sense
> > >
}
>
> desc->tfm = tfm;
>
> --
> 2.29.2
>
Good catch, thanks!
Acked-by: Dave Young
Thanks
Dave
Hi Guilherme,
On 11/22/20 at 12:32pm, Guilherme Piccoli wrote:
> Hi Dave and Kairui, thanks for your responses! OK, if that makes sense
> to you I'm fine with it. I'd just recommend to test recent kernels in
> multiple distros with the minimum "range" to see if 64M is enough for
> crashkernel,
Hi Guilherme,
On 11/19/20 at 06:56pm, Guilherme Piccoli wrote:
> Hi Saeed, thanks for your patch/idea! Comments inline, below.
>
> On Wed, Nov 18, 2020 at 8:29 PM Saeed Mirzamohammadi
> wrote:
> >
> > This adds crashkernel=auto feature to configure reserved memory for
> > vmcore creation to both
Hi,
On 09/25/20 at 10:56am, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 25, 2020 at 11:05:58AM +0800, Dave Young wrote:
> > Hi,
> >
> > On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote:
> > >
> > > On 9/24/20 12:43 PM, Michael Kelley wrote:
> >
Hi,
On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote:
>
> On 9/24/20 12:43 PM, Michael Kelley wrote:
> > From: Eric W. Biederman Sent: Thursday, September
> > 24, 2020 9:26 AM
> >> Michael Kelley writes:
> >>
> > Added Hyper-V people and people who created the param, it is below
>
+ more people who may care about this param
On 09/21/20 at 08:45pm, Eric W. Biederman wrote:
> Konrad Rzeszutek Wilk writes:
>
> > On Fri, Sep 18, 2020 at 05:47:43PM -0700, Andrew Morton wrote:
> >> On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
> >>
>
On 09/21/20 at 04:18pm, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 18, 2020 at 05:47:43PM -0700, Andrew Morton wrote:
> > On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
> >
> > > crash_kexec_post_notifiers enables running various panic notifier
> >
On 09/18/20 at 05:47pm, Andrew Morton wrote:
> On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
>
> > crash_kexec_post_notifiers enables running various panic notifier
> > before kdump kernel booting. This increases risks of kdump failure.
> > It is well documented
On 09/18/20 at 11:57am, chenzhou wrote:
> Hi Dave,
>
>
> On 2020/9/18 11:01, Dave Young wrote:
> > On 09/07/20 at 09:47pm, Chen Zhou wrote:
> >> To make the functions reserve_crashkernel[_low]() as generic,
> >> replace some hard-coded numbers with macro CRAS
permission in sysfs.
Signed-off-by: Dave Young
---
kernel/panic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index aef8872ba843..bea44fc4eb3b 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -695,7 +695,7 @@ core_param(panic, panic_timeout
On 09/07/20 at 09:47pm, Chen Zhou wrote:
> To make the functions reserve_crashkernel[_low]() as generic,
> replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
>
> Signed-off-by: Chen Zhou
> ---
> arch/x86/kernel/setup.c | 11 ++-
> 1 file changed, 6 insertions(+), 5
t with macro CRASH_ALIGN in function
> reserve_crashkernel().
>
> Suggested-by: Dave Young
> Signed-off-by: Chen Zhou
> ---
> arch/x86/include/asm/kexec.h | 3 +++
> arch/x86/kernel/setup.c | 5 +
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff -
On 09/04/20 at 12:02pm, chenzhou wrote:
>
>
> On 2020/9/4 11:10, Dave Young wrote:
> > On 09/04/20 at 11:04am, Dave Young wrote:
> >> On 09/03/20 at 07:26pm, chenzhou wrote:
> >>> Hi Catalin,
> >>>
> >>>
> >>> On 2020/9/
On 09/04/20 at 11:04am, Dave Young wrote:
> On 09/03/20 at 07:26pm, chenzhou wrote:
> > Hi Catalin,
> >
> >
> > On 2020/9/3 1:09, Catalin Marinas wrote:
> > > On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:
> > >> There are following iss
On 09/03/20 at 07:26pm, chenzhou wrote:
> Hi Catalin,
>
>
> On 2020/9/3 1:09, Catalin Marinas wrote:
> > On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:
> >> There are following issues in arm64 kdump:
> >> 1. We use crashkernel=X to reserve crashkernel below 4G, which
> >> will fail
On 08/17/20 at 01:14pm, James Morse wrote:
> Hi guys,
>
> On 14/08/2020 20:22, Pavel Tatashin wrote:
> > On Fri, Aug 14, 2020 at 7:24 AM Dave Young wrote:
> >> On 08/14/20 at 04:21pm, Sang Yan wrote:
> >>> On 08/14/20 14:58, Dave Young wrote:
> >
On 08/18/20 at 03:07pm, chenzhou wrote:
>
>
> On 2020/8/10 14:03, Dave Young wrote:
> > Hi,
> >
> >>> Previously I remember we talked about to use similar logic as X86, but I
> >>> remember you mentioned on some arm64 platform there could be no low
&g
Hi,
On 08/14/20 at 04:21pm, Sang Yan wrote:
>
>
> On 08/14/20 14:58, Dave Young wrote:
> > On 08/14/20 at 01:52am, Sang Yan wrote:
> >> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> >> copy all segments from vmalloced memory to kernel boot mem
On 08/14/20 at 01:52am, Sang Yan wrote:
> In normal kexec, relocating kernel may cost 5 ~ 10 seconds, to
> copy all segments from vmalloced memory to kernel boot memory,
> because of disabled mmu.
It is not the case on all archs, I assume your case is arm64, please
describe it in patch log :)
On 08/11/20 at 12:40pm, Orson Zhai wrote:
> From: Thomas Gleixner
>
> Timestamps printed in kernel log are retrieved by local_clock which reads
> jiffies as a referrence clock source.
> But it is diffcult to be synchronized with logs generated out of kernel,
> say some remote processors (Modem)
ret = kexec_purgatory_get_set_symbol(image,
> "purgatory_sha256_digest",
>digest,
> SHA256_DIGEST_SIZE, 0);
> - if (ret)
> - goto out_free_digest;
> }
>
> out_free_digest:
> --
> 2.1.0
>
Acked-by: Dave Young
Thanks
Dave
Hi,
> > Previously I remember we talked about to use similar logic as X86, but I
> > remember you mentioned on some arm64 platform there could be no low
> > memory at all. Is this not a problem now for the fallback? Just be
> > curious, thanks for the update, for the common part looks good.
>
On 08/10/20 at 11:28am, chenzhou wrote:
> On 2020/8/8 18:02, Dave Young wrote:
> > On 08/01/20 at 09:08pm, Chen Zhou wrote:
> >> Now the behavior of crashkernel=X has been changed, which tries low
> >> allocation in ZONE_DMA, and fall back to high allocation if it fails.
emory reserved is below 4G.
> -
> + [KNL, arm64] range under 4G.
> + This one let user to specify a low range in ZONE_DMA for
> + crash dump kernel. For non-RPi4 platforms, change
> ZONE_DMA
> + to Z
start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> +#endif
> + return 0;
> +}
> +
> Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
> void *data, size_t data_len)
> {
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c19c0dad1ebe..db66bbabfff3 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -53,23 +53,6 @@ note_buf_t __percpu *crash_notes;
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> -
> -/* Location of the reserved area for the crash kernel */
> -struct resource crashk_res = {
> - .name = "Crash kernel",
> - .start = 0,
> - .end = 0,
> - .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> - .desc = IORES_DESC_CRASH_KERNEL
> -};
> -struct resource crashk_low_res = {
> - .name = "Crash kernel",
> - .start = 0,
> - .end = 0,
> - .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> - .desc = IORES_DESC_CRASH_KERNEL
> -};
> -
> int kexec_should_crash(struct task_struct *p)
> {
> /*
> --
> 2.20.1
>
Acked-by: Dave Young
Thanks
Dave
FORCE
> $(call if_changed,ld)
>
> --
> 2.7.5
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
Hi Pingfan,
Looks good, thanks for the patch.
Acked-by: Dave Young
Thanks
Dave
Hi Chen,
Thanks for the update. I was busy on other things, I will review your
x86/common changes
this weekend or early next week.
On 08/01/20 at 09:08pm, Chen Zhou wrote:
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which
> will fail
---
> 2 files changed, 23 insertions(+), 12 deletions(-)
>
> --
> 2.17.1
Looks good, thanks for the patches
Acked-by: Dave Young
Thanks
Dave
On 07/08/20 at 05:20am, Alexander A. Klimov wrote:
>
>
> Am 08.07.20 um 05:17 schrieb Dave Young:
> > On 07/01/20 at 07:33pm, Alexander A. Klimov wrote:
> > >
> > >
> > > Am 01.07.20 um 09:58 schrieb Dave Young:
> > > > On 06/27/20 at 1
On 07/01/20 at 07:33pm, Alexander A. Klimov wrote:
>
>
> Am 01.07.20 um 09:58 schrieb Dave Young:
> > On 06/27/20 at 12:31pm, Alexander A. Klimov wrote:
> > > Rationale:
> > > Reduces attack surface on kernel devs opening the links for MITM
> > > as
; @@ -675,7 +687,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
> kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
>
> /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - ret = kexec_locate_mem_hole(kbuf);
> + ret = arch_kexec_locate_mem_hole(kbuf);
> if (ret)
> return ret;
>
>
Acked-by: Dave Young
Thanks
Dave
On 07/03/20 at 12:50pm, Dave Young wrote:
> On 07/03/20 at 12:46pm, Dave Young wrote:
> > Hi,
> >
> > Thanks for the update, but still some nitpicks :(
> >
> > I'm sorry I did not catch them previously, but maybe it is not worth to
> > repost the
On 07/03/20 at 12:46pm, Dave Young wrote:
> Hi,
>
> Thanks for the update, but still some nitpicks :(
>
> I'm sorry I did not catch them previously, but maybe it is not worth to
> repost the whole series if no other changes needed.
Feel free to add my acks for the common
Hi,
Thanks for the update, but still some nitpicks :(
I'm sorry I did not catch them previously, but maybe it is not worth to
repost the whole series if no other changes needed.
On 07/03/20 at 11:58am, Chen Zhou wrote:
> Now we support crashkernel=X,[low] on arm64, update the Documentation.
>
n't
> seem to have been cc'ed either (only the kexec list).
For the VMCOREINFO part, I'm fine with the changes, but since I do not
understand the arm64 pieces so I would like to leave to arm64 people to
review. If arm64 bits are good enough, feel free to add:
Acked-by: Dave Young
Thanks
Dave
> > I'm confused about the "overlap with crashkernel memory", does that mean
> > those normal kernel used memory could be put in crashkernel reserved
> > memory range? If so why can't just skip those areas while crashkernel
> > doing the reservation?
> I raised the same question in another mail.
On 07/01/20 at 11:48pm, Hari Bathini wrote:
>
>
> On 01/07/20 1:10 pm, Dave Young wrote:
> > Hi Hari,
> > On 06/27/20 at 12:35am, Hari Bathini wrote:
> >> crashkernel region could have an overlap with special memory regions
> >> like opal, rtas, tce-t
On 07/02/20 at 12:01am, Hari Bathini wrote:
>
>
> On 01/07/20 1:16 pm, Dave Young wrote:
> > On 06/29/20 at 05:26pm, Hari Bathini wrote:
> >> Hi Petr,
> >>
> >> On 29/06/20 5:09 pm, Petr Tesarik wrote:
> >>> Hi Hari,
> >>>
&g
Hi Chen,
On 06/28/20 at 04:34pm, Chen Zhou wrote:
> Now we support crashkernel=X,[low] on arm64, update the Documentation.
> We could use parameters "crashkernel=X crashkernel=Y,low" to reserve
> memory above 4G.
>
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> Tested-by: Prabhakar
> Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
> void *data, size_t data_len)
> {
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c19c0dad1ebe..db66bbabfff3 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -53,23 +53,6 @@ note_buf_t __percpu *crash_notes;
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> -
> -/* Location of the reserved area for the crash kernel */
> -struct resource crashk_res = {
> - .name = "Crash kernel",
> - .start = 0,
> - .end = 0,
> - .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> - .desc = IORES_DESC_CRASH_KERNEL
> -};
> -struct resource crashk_low_res = {
> - .name = "Crash kernel",
> - .start = 0,
> - .end = 0,
> - .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> - .desc = IORES_DESC_CRASH_KERNEL
> -};
> -
> int kexec_should_crash(struct task_struct *p)
> {
> /*
> --
> 2.20.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
Acked-by: Dave Young
Thanks
Dave
Hi,
On 06/26/20 at 05:39pm, Tyler Hicks wrote:
> Take the properties of the kexec kernel's inode and the current task
> ownership into consideration when matching a KEXEC_CMDLINE operation to
> the rules in the IMA policy. This allows for some uniformity when
> writing IMA policy rules for
On 06/27/20 at 12:31pm, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain
On 06/29/20 at 05:26pm, Hari Bathini wrote:
> Hi Petr,
>
> On 29/06/20 5:09 pm, Petr Tesarik wrote:
> > Hi Hari,
> >
> > is there any good reason to add two more functions with a very similar
> > name to an existing function? AFAICS all you need is a way to call a
> > PPC64-specific function
Hi Hari,
On 06/27/20 at 12:35am, Hari Bathini wrote:
> crashkernel region could have an overlap with special memory regions
> like opal, rtas, tce-table & such. These regions are referred to as
> exclude memory ranges. Setup this ranges during image probe in order
> to avoid them while finding
Hi John,
On 06/18/20 at 04:55pm, John Ogness wrote:
> Hello,
>
> Here is a v3 for the first series to rework the printk
> subsystem. The v2 and history are here [0]. This first series
> only replaces the existing ringbuffer implementation. No locking
> is removed. No semantics/behavior of printk
Hi,
This warning exists for long time, I did not find time to report, here
is the latest kernel logs, can you please to have a look?
hardware: Thinkpad T480s
lspci: 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620
(rev 07)
--
[0.00] Linux version 5.8.0-rc1+
Cc kexec list in case people may missed the pieces.
On 06/01/20 at 04:27pm, Łukasz Stelmach wrote:
> The following series of patches provides implementation of the
> kexec_file_load() system call form the arm architecture. zImage and uImage
> (legacy format) files are supported. Like on arm64,
able
> - * signatures and signature check failures - even if signatures
> - * aren't required.
> - */
> - default:
> - pr_notice("kernel signature verification failed (%d).\n", ret);
> + pr_debug("kernel signature verification failed (%d).\n", ret);
> }
>
> - return ret;
> + return 0;
> }
> #endif
>
> --
> 2.17.1
>
Acked-by: Dave Young
Thanks
Dave
mp;&
> security_locked_down(LOCKDOWN_KEXEC))
> return -EPERM;
> -
> - return 0;
> -
> - /* All other errors are fatal, including nomem, unparseable
> - * signatures and signature check failures - even if signatures
> - * aren't required.
> - */
> - default:
> - pr_notice("kernel signature verification failed (%d).\n", ret);
> }
>
> - return ret;
> + return 0;
> }
> #endif
>
> --
> 2.17.1
>
Acked-by: Dave Young
Thanks
Dave
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 8f592ada59b321d248391bae175cd78a12972223
Gitweb:
https://git.kernel.org/tip/8f592ada59b321d248391bae175cd78a12972223
Author:Dave Young
AuthorDate:Sun, 12 Apr 2020 10:49:27 +08:00
Committer
On 05/20/20 at 05:43pm, Baoquan He wrote:
> On 05/20/20 at 05:14pm, Dave Young wrote:
> > Hi Baoquan,
> > On 05/20/20 at 04:05pm, Baoquan He wrote:
> > > Kdump is implemented based on kexec, however some files are only
> > > related to crash dumping and
Hi Baoquan,
On 05/20/20 at 04:05pm, Baoquan He wrote:
> Kdump is implemented based on kexec, however some files are only
> related to crash dumping and missing, add them to KDUMP entry.
>
> Signed-off-by: Baoquan He
> ---
> MAINTAINERS | 5 +
> 1 file changed, 5 insertions(+)
>
> diff
Hi Lianbo,
On 10/07/19 at 03:08pm, Lianbo Jiang wrote:
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204793
>
> Kdump kernel will reuse the first 640k region because of some reasons,
> for example: the trampline and conventional PC system BIOS region may
> require to allocate memory in
l code execution)
> and will be ignored in the rest of the kernel.
>
> (Modified by Matthew Garrett in order to handle the early boot RSDP
> environment)
>
> Signed-off-by: Josh Boyer
> Signed-off-by: David Howells
> Signed-off-by: Matthew Garrett
> Reviewed-by: Kees Cook
&g
; Signed-off-by: Josh Boyer
> Signed-off-by: David Howells
> Signed-off-by: Matthew Garrett
> Reviewed-by: Kees Cook
> cc: Dave Young
> cc: linux-a...@vger.kernel.org
> ---
> drivers/acpi/osl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --gi
On 06/24/19 at 09:35am, Dave Young wrote:
> On 06/23/19 at 06:24am, Tiezhu Yang wrote:
> > Fix the following sparse warning:
> >
> > arch/x86/kernel/crash.c:59:15:
> > warning: symbol 'crash_zero_bytes' was not declared. Should it be static?
> >
> &
> EXPORT_SYMBOL_GPL(crash_vmclear_loaded_vmcss);
> -unsigned long crash_zero_bytes;
> +#ifdef CONFIG_KEXEC_FILE
> +static unsigned long crash_zero_bytes;
> +#endif
>
> static inline void cpu_crash_vmclear_loaded_vmcss(void)
> {
> --
> 1.8.3.1
Acked-by: Dave Young
Thanks
Dave
t; >
> > - call ima_kexec_cmdline from kexec_file_load.
> > - move the call ima_add_kexec_buffer after the cmdline
> > args have been measured.
> >
> > Signed-off-by: Prakhar Srivastava
> Cc: Eric W. Biederman
> Cc: Dave Young
>
> Any chance we could get so
KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer();
> if (ret)
> goto out;
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Reviewed-by: Dave Young
Thanks
Dave
On 05/22/19 at 11:20am, Dave Young wrote:
> On 05/09/19 at 09:36am, Baoquan He wrote:
> > If the running kernel has 5-level paging activated, the 5-level paging
> > mode is preserved across kexec. If the kexec'ed kernel does not contain
> > support for handling activ
On 05/09/19 at 09:36am, Baoquan He wrote:
> If the running kernel has 5-level paging activated, the 5-level paging
> mode is preserved across kexec. If the kexec'ed kernel does not contain
> support for handling active 5-level paging mode in the decompressor, the
> decompressor will crash with
Hi Baoquan,
A few nitpicks, otherwise
Acked-by: Dave Young
On 05/09/19 at 09:36am, Baoquan He wrote:
> Restrict kdump to only reserve crashkernel below 64TB.
>
> The reaons is that the kdump may jump from 5-level to 4-level, and if
> the kdump kernel is put above 64TB, then
On 04/24/19 at 01:41pm, Baoquan He wrote:
> On 04/24/19 at 02:47am, Junichi Nomura wrote:
> > On 4/24/19 2:15 AM, Kairui Song wrote:
> > > On Mon, Apr 22, 2019 at 11:21 PM Junichi Nomura
> > > wrote:
> > >> Is the mapping of ACPI tables just by luck, too?
> > >
> > > Good question, they should
On 04/23/19 at 06:20am, Junichi Nomura wrote:
> On 4/22/19 6:28 PM, Kairui Song wrote:
> > The reason is the systab region is not mapped by the identity mapping
> > provided by kexec. Currently kexec only create identity mapping for
> > mem regions, wihch won't cover the systab. So second kernel
Commit-ID: 9ca5c8e632ce8f144ec6d00da2dc5e16b41d593c
Gitweb: https://git.kernel.org/tip/9ca5c8e632ce8f144ec6d00da2dc5e16b41d593c
Author: Dave Young
AuthorDate: Sun, 21 Apr 2019 11:50:59 +0800
Committer: Borislav Petkov
CommitDate: Mon, 22 Apr 2019 10:15:16 +0200
x86/kdump: Have
Commit-ID: b9ac3849af412fd3887d7652bdbabf29d2aecc16
Gitweb: https://git.kernel.org/tip/b9ac3849af412fd3887d7652bdbabf29d2aecc16
Author: Dave Young
AuthorDate: Mon, 22 Apr 2019 11:19:05 +0800
Committer: Borislav Petkov
CommitDate: Mon, 22 Apr 2019 10:23:05 +0200
x86/kdump: Fall back
a suitable low range. Do not set the ,high as default
because it allocates extra low memory for DMA buffers and swiotlb, this is
not always necessary for all machines. Typically like crashkernel=128M
usually work with low reservation under 4G, so still keep <4G as default.
Signed-off-by: Dave Yo
On 04/21/19 at 08:26pm, Ingo Molnar wrote:
>
> * Dave Young wrote:
>
> > crashkernel=xM tries to reserve crashkernel memory under 4G, which
> > is enough for usual cases. But this could fail sometimes, for example
> > one tries to reserve a big chunk like
a suitable low range. Do not set the ,high as default
because it allocs extra low memory for DMA buffers and swiotlb, this is
not always necessary for all machines. Typically like crashkernel=128M
usually work with low reservation under 4G, so still keep <4G as default.
Signed-off-by: Dave Yo
shkernel=X@Y
* people have reported bugs crashkernel=384M failed because kaslr makes
the 0-896M space sparse,
* crashkernel can reserve in low or high area, it is natural to understand
low as memory under 4G
Hence drop the 896M limitation, and change crashkernel low reservation to
reserve under 4
saved mail format patch.
But the warning is boring for people who do not use git formated patch.
Change the script only print warning in case "From:" line exists.
Signed-off-by: Dave Young
---
scripts/checkpatch.pl |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- li
On 04/17/19 at 02:00pm, Kairui Song wrote:
> On Wed, Apr 17, 2019 at 12:57 PM Dave Young wrote:
> >
> > On 04/17/19 at 09:38am, Dave Young wrote:
> > > On 04/16/19 at 03:22pm, Borislav Petkov wrote:
> > > > On Tue, Apr 16, 2019 at 07:41:33PM +0800, Dave Youn
On 04/03/19 at 04:23pm, Dave Young wrote:
> On 04/03/19 at 03:50pm, Baoquan He wrote:
> > On 04/03/19 at 03:30pm, Chao Fan wrote:
> > > On Wed, Apr 03, 2019 at 02:39:11PM +0800, Dave Young wrote:
> > > >> Actually I got some different kexec test results.
>
On 04/03/19 at 01:53pm, Dave Young wrote:
> On 04/03/19 at 01:35pm, Chao Fan wrote:
> > On Tue, Apr 02, 2019 at 08:03:19PM +0800, Dave Young wrote:
> > >On 04/01/19 at 12:08am, Junichi Nomura wrote:
> > >> Commit 3a63f70bf4c3a ("x86/boot: Early parse RSDP and sa
ending
> on whether the kernel is booted by kexec or not.
>
> Fixes: 3a63f70bf4c3a ("x86/boot: Early parse RSDP and save it in boot_params")
> Signed-off-by: Jun'ichi Nomura
> Acked-by: Baoquan He
> Cc: Chao Fan
> Cc: Borislav Petkov
> Cc: Dave Young
>
On 03/25/19 at 09:54am, Boris Petkov wrote:
> On March 25, 2019 9:27:21 AM GMT+01:00, Junichi Nomura
> wrote:
> >On 3/25/19 3:59 PM, Dave Young wrote:
> >> On 03/25/19 at 06:47am, Junichi Nomura wrote:
> >>> On 3/25/19 3:19 PM, Dave Young wrote:
> >>&
Hi Mimi
On 03/22/19 at 03:35pm, Mimi Zohar wrote:
> Verify IMA is enabled before failing tests or emitting irrelevant
> messages. Also, don't skip the test if signatures are not required.
>
> Suggested-by: Dave Young
> Signed-off-by: Mimi Zohar
> ---
> Dave, i
On 02/28/19 at 10:05am, Mimi Zohar wrote:
> Hi Dave,
>
> On Thu, 2019-02-28 at 21:41 +0800, Dave Young wrote:
> > Hi Mimi,
> >
> > Sorry for jumping in late, just noticed this kexec selftests, I think we
> > also need a kexec load test not only for ima, b
Hi Mimi,
Sorry for jumping in late, just noticed this kexec selftests, I think we
also need a kexec load test not only for ima, but for general kexec
On 01/31/19 at 01:55pm, Mimi Zohar wrote:
> Define and move get_secureboot_mode() to a common file for use by other
> tests.
>
> Signed-off-by:
On 02/25/19 at 09:05pm, Baoquan He wrote:
> On 02/25/19 at 10:45am, Borislav Petkov wrote:
> > On Mon, Feb 25, 2019 at 03:59:56PM +0800, Pingfan Liu wrote:
> > > crashkernel=x@y option may fail to reserve the required memory region if
> > > KASLR puts kernel into the region. To avoid this
On 02/25/19 at 12:00pm, Joerg Roedel wrote:
> On Fri, Feb 22, 2019 at 02:00:26PM +0100, Borislav Petkov wrote:
> > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > > The current default of 256MB was found by experiments on a bigger
> > > number of machines, to create a reasonable
On 02/24/19 at 09:25pm, Pingfan Liu wrote:
> On Fri, Feb 22, 2019 at 9:00 PM Borislav Petkov wrote:
> >
> > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote:
> > > The current default of 256MB was found by experiments on a bigger
> > > number of machines, to create a reasonable
On 02/21/19 at 06:13pm, Borislav Petkov wrote:
> On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote:
> > Previously Joerg posted below patch, maybe he has some idea. Joerg?
>
> Isn't it clear from the commit message?
Then, does it answered your question?
256M is set as
On 02/20/19 at 09:32am, Borislav Petkov wrote:
> On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote:
> > It is ideal if kernel can do it automatically, but I'm not sure if
> > kernel can predict the swiotlb reserved size automatically.
>
> Do you see how even
On 02/15/19 at 11:24am, Borislav Petkov wrote:
> On Tue, Feb 12, 2019 at 04:48:16AM +0800, Dave Young wrote:
> > Even we make it automatic in kernel, but we have to have some default
> > value for swiotlb in case crashkernel can not find a free region under 4G.
> > So t
On 02/06/19 at 08:08pm, Dave Young wrote:
> On 02/05/19 at 09:15am, Borislav Petkov wrote:
> > On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote:
> > > Is your objection only to the second fallback of allocating
> > > memory above >= 4GB? Or are yo
On 02/05/19 at 09:15am, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote:
> > Is your objection only to the second fallback of allocating
> > memory above >= 4GB? Or are you objecting to allocating from
> > (896 .. 4GB) as well?
>
> My problem is why should
On 01/25/19 at 03:08pm, Borislav Petkov wrote:
> On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote:
> > AFAIK, some people prefer to explictly reserve crash memory at high
> > region even if it is possible to reserve at low area. May because
> > <4G memory is
On 01/29/19 at 01:25pm, Pingfan Liu wrote:
> On Fri, Jan 25, 2019 at 10:08 PM Borislav Petkov wrote:
> >
> > On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote:
> > > AFAIK, some people prefer to explictly reserve crash memory at high
> > > region even if
On 01/25/19 at 03:08pm, Borislav Petkov wrote:
> On Fri, Jan 25, 2019 at 09:45:18PM +0800, Dave Young wrote:
> > AFAIK, some people prefer to explictly reserve crash memory at high
> > region even if it is possible to reserve at low area. May because
> > <4G memory is
1 - 100 of 2643 matches
Mail list logo
