> >
> > Dave Young sent the original post, and I just re-post it with commit log
>
> If he sent it, he should be the author I guess.
Just drop the line, but can change the credit to Chao Wang since he did
it initially.
But Chao does not work on kexec/kdump any more, and
97.983035] __x64_sys_kexec_file_load+0x144/0x290
> [ 97.983586] do_syscall_64+0x55/0x1a0
> [ 97.983962] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> When efi runtime is not enabled, efi memmap is not mapped, so just skip
> EFI info setup.
>
> Suggested-by: Dave Young
.h
> +++ b/include/linux/verification.h
> @@ -17,6 +17,7 @@
> * should be used.
> */
> #define VERIFY_USE_SECONDARY_KEYRING ((struct key *)1UL)
> +#define VERIFY_USE_PLATFORM_KEYRING ((struct key *)2UL)
>
> /*
> * The use to which an asymmetric key is being put.
> --
> 2.20.1
>
For kexec_file part
Acked-by: Dave Young
Thanks
Dave
On 01/18/19 at 08:34pm, Dave Young wrote:
> On 01/18/19 at 06:53am, Mimi Zohar wrote:
> > On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > reference to .platform keyring in integri
On 01/18/19 at 06:53am, Mimi Zohar wrote:
> On Fri, 2019-01-18 at 17:17 +0800, Kairui Song wrote:
> > This patch series adds a .platform_trusted_keys in system_keyring as the
> > reference to .platform keyring in integrity subsystem, when platform
> > keyring is being initialized it will be
erve 896 MB;
2) what's wrong with memory region under 4G;
3) why I have to add ',high', I only require 384 MB, not 3840 MB.
This patch tries to get memory region from 896 MB firstly, then [896MB,4G],
finally above 4G.
> Dave Young sent the original post, and I just re-post it with commit log
>
On 01/18/19 at 09:35am, Dave Young wrote:
> On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> > On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > reference to .platform keyring in integri
On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> > This patch series adds a .platform_trusted_keys in system_keyring as the
> > reference to .platform keyring in integrity subsystem, when platform
> > keyring is being initialized it will be
+ linux-acpi list
On 01/17/19 at 03:49pm, Chao Fan wrote:
> On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
> >On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
> >>
> >> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> >> > I didn't see a way to reuse things in
Add linux-acpi list
On 01/17/19 at 03:41pm, Kairui Song wrote:
> On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov wrote:
> >
> > On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> > > I didn't see a way to reuse things in that patch series, situation is
> > > different, in that patch
On 01/16/19 at 01:09pm, Kairui Song wrote:
> On Wed, Jan 16, 2019 at 11:32 AM Dave Young wrote:
> >
> > On 01/16/19 at 12:10am, Borislav Petkov wrote:
> > > On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
> > > > When efi=noruntime or ef
t; > kernel to boot.
> >
> > Tested with an EFI enabled KVM VM with efi=noruntime.
> >
> > Suggested-by: Dave Young
> > Signed-off-by: Kairui Song
> > ---
> > arch/x86/kernel/kexec-bzimage64.c | 21 +
> > drivers/acpi/acpic
Commit-ID: 993a110319a4a60aadbd02f6defdebe048f7773b
Gitweb: https://git.kernel.org/tip/993a110319a4a60aadbd02f6defdebe048f7773b
Author: Dave Young
AuthorDate: Fri, 28 Dec 2018 09:12:47 +0800
Committer: Borislav Petkov
CommitDate: Tue, 15 Jan 2019 12:12:50 +0100
x86/kexec: Fix
acpi_rsdp_addr
> parameter in the boot_params passed to second kernel, this commit make
> use of it, detect and set the RSDP address when it's required for second
> kernel to boot.
>
> Tested with an EFI enabled KVM VM with efi=noruntime.
>
> Suggested-by: Dave Young
> S
On 12/28/18 at 09:12am, Dave Young wrote:
> The code cleanup mentioned in Fixes tag changed the behavior of
> kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> allocate free memory only when kbuf.mem is initialized as zero.
>
> But in x86 kexec_file_load
On 01/14/19 at 11:10am, Mimi Zohar wrote:
> On Sun, 2019-01-13 at 09:39 +0800, Dave Young wrote:
> > Hi,
> >
> > On 01/11/19 at 11:13am, Mimi Zohar wrote:
> > > On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote:
> > > [snip]
> > >
> > >
Hi,
On 01/11/19 at 11:13am, Mimi Zohar wrote:
> On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote:
> [snip]
>
> > Personally I would like to see platform key separated from integrity.
> > But for the kexec_file part I think it is good at least it works with
> &g
+17,7 @@
> * should be used.
> */
> #define VERIFY_USE_SECONDARY_KEYRING ((struct key *)1UL)
> +#define VERIFY_USE_PLATFORM_KEYRING ((struct key *)2UL)
>
> /*
> * The use to which an asymmetric key is being put.
> --
> 2.20.1
>
Personally I would like to see platform key separated from integrity.
But for the kexec_file part I think it is good at least it works with
this fix.
Acked-by: Dave Young
Thanks
Dave
CC kexec list
On 01/08/19 at 10:18am, Mimi Zohar wrote:
> [Cc'ing the LSM and integrity mailing lists]
>
> Repeating my comment on PATCH 0/1 here with the expanded set of
> mailing lists.
>
> The builtin and secondary keyrings have a signature change of trust
> rooted in the signed kernel image.
On 01/08/19 at 04:51pm, Baoquan He wrote:
> On 01/08/19 at 04:46pm, Dave Young wrote:
> > > Wondering why this place doesn't need the initialization assignment.
> > > Isn't it to assign in all places before kexec_add_buffer() calling?
> >
> > C designated initiali
On 01/08/19 at 01:24pm, Baoquan He wrote:
> On 12/28/18 at 09:12am, Dave Young wrote:
> > The code cleanup mentioned in Fixes tag changed the behavior of
> > kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> > allocate free memory only when kbuf.mem i
On 12/28/18 at 09:12am, Dave Young wrote:
> The code cleanup mentioned in Fixes tag changed the behavior of
> kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> allocate free memory only when kbuf.mem is initialized as zero.
>
> But in x86 kexec_file_load
: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
Signed-off-by: Dave Young
Cc:
---
V1 -> V2: use KEXEC_BUF_MEM_UNKNOWN in code.
arch/x86/kernel/crash.c | 1 +
arch/x86/kernel/kexec-bzimage64.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/ker
On 12/27/18 at 01:06pm, Dave Young wrote:
> The code cleanup mentioned in Fixes tag changed the behavior of
> kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> allocate free memory only when kbuf.mem is initialized as zero.
>
> But in x86 kexec_file_load
: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
Signed-off-by: Dave Young
Cc:
---
arch/x86/kernel/crash.c | 1 +
arch/x86/kernel/kexec-bzimage64.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index f6
On 12/26/18 at 11:24am, Dave Young wrote:
> > >> +
> > >> +KERNEL_IMAGE_SIZE
> > >> +=
> > >> +The size of 'KERNEL_IMAGE_SIZE', currently unused.
> > >
> > > So remove?
> > >
> >
> > I'm
Add Kazu and Dave in cc
On 12/20/18 at 01:40pm, Lianbo Jiang wrote:
> This patchset did two things:
> a. add a new document for vmcoreinfo
>
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many
> >> +
> >> +KERNEL_IMAGE_SIZE
> >> +=
> >> +The size of 'KERNEL_IMAGE_SIZE', currently unused.
> >
> > So remove?
> >
>
> I'm not sure whether it should be removed, so i keep it.
Just remove it. It was added by Baoquan for KASLR issues, later
makedumpfile reverted the
d kexec-tools:
> if the reserved region is above 896M, then old tool will fail to load
> bzImage. But without this patch, the old tool also fail since there is no
> memory below 896M can be reserved for crashkernel.
>
> [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.h
d kexec-tools:
> if the reserved region is above 896M, then old tool will fail to load
> bzImage. But without this patch, the old tool also fail since there is no
> memory below 896M can be reserved for crashkernel.
>
> [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.h
> >> +init_uts_ns
> >> +===
> >> +This is the UTS namespace, which is used to isolate two specific elements
> >> +of the system that relate to the uname system call. The UTS namespace is
> >> +named after the data structure used to store information returned by the
> >> +uname system call.
> >> +init_uts_ns
> >> +===
> >> +This is the UTS namespace, which is used to isolate two specific elements
> >> +of the system that relate to the uname system call. The UTS namespace is
> >> +named after the data structure used to store information returned by the
> >> +uname system call.
On 11/15/18 at 11:39am, Borislav Petkov wrote:
> + Bjorn.
>
> On Thu, Nov 15, 2018 at 01:44:07PM +0800, lijiang wrote:
> > At present, the upstream kernel does not pass the e820 reserved ranges to
> > the
> > second kernel, which might cause two problems:
> >
> > The first one is the MMCONFIG
On 11/15/18 at 11:39am, Borislav Petkov wrote:
> + Bjorn.
>
> On Thu, Nov 15, 2018 at 01:44:07PM +0800, lijiang wrote:
> > At present, the upstream kernel does not pass the e820 reserved ranges to
> > the
> > second kernel, which might cause two problems:
> >
> > The first one is the MMCONFIG
On 09/18/18 at 06:20pm, lijiang wrote:
> 在 2018年09月18日 11:20, Dave Young 写道:
> > On 09/18/18 at 10:48am, Lianbo Jiang wrote:
> >> e820 reserved ranges is useful in kdump kernel, we have added this in
> >> kexec-tools code.
> >>
> >> One reason is PCI mm
On 09/18/18 at 06:20pm, lijiang wrote:
> 在 2018年09月18日 11:20, Dave Young 写道:
> > On 09/18/18 at 10:48am, Lianbo Jiang wrote:
> >> e820 reserved ranges is useful in kdump kernel, we have added this in
> >> kexec-tools code.
> >>
> >> One reason is PCI mm
port, it needs to map dmi table area as unencrypted.
> For normal boot these ranges sit in e820 reserved ranges thus the early
> ioremap code naturally map them as unencrypted. So if we have same e820
> reserve setup in kdump kernel then it will just work like normal kernel.
>
> Sig
port, it needs to map dmi table area as unencrypted.
> For normal boot these ranges sit in e820 reserved ranges thus the early
> ioremap code naturally map them as unencrypted. So if we have same e820
> reserve setup in kdump kernel then it will just work like normal kernel.
>
> Sig
On 08/30/18 at 08:55am, Luca Coelho wrote:
> On Thu, 2018-08-30 at 13:06 +0800, Dave Young wrote:
> > On 08/30/18 at 07:15am, Luca Coelho wrote:
> > > On Wed, 2018-08-29 at 14:54 +0800, Dave Young wrote:
> > > > [ 74.123114] wlp61s0: authenticate with 00:1f:c6:
On 08/30/18 at 08:55am, Luca Coelho wrote:
> On Thu, 2018-08-30 at 13:06 +0800, Dave Young wrote:
> > On 08/30/18 at 07:15am, Luca Coelho wrote:
> > > On Wed, 2018-08-29 at 14:54 +0800, Dave Young wrote:
> > > > [ 74.123114] wlp61s0: authenticate with 00:1f:c6:
On 08/22/18 at 06:23pm, Dave Young wrote:
> On 08/21/18 at 03:39pm, Ard Biesheuvel wrote:
> > On 9 August 2018 at 11:13, Dave Young wrote:
> > > On 08/09/18 at 09:33am, Mike Galbraith wrote:
> > >> On Thu, 2018-08-09 at 12:21 +0800, Dave Young wrote:
> > &g
On 08/22/18 at 06:23pm, Dave Young wrote:
> On 08/21/18 at 03:39pm, Ard Biesheuvel wrote:
> > On 9 August 2018 at 11:13, Dave Young wrote:
> > > On 08/09/18 at 09:33am, Mike Galbraith wrote:
> > >> On Thu, 2018-08-09 at 12:21 +0800, Dave Young wrote:
> > &g
On 08/16/18 at 09:43am, Yannik Sembritzki wrote:
> On 16.08.2018 03:11, Dave Young wrote:
> > Instead of fix your 1st patch in 2nd patch, I would suggest to
> > switch the patch order. In 1st patch change the common code to use
> > the new macro and in 2nd patch you can d
On 08/16/18 at 09:43am, Yannik Sembritzki wrote:
> On 16.08.2018 03:11, Dave Young wrote:
> > Instead of fix your 1st patch in 2nd patch, I would suggest to
> > switch the patch order. In 1st patch change the common code to use
> > the new macro and in 2nd patch you can d
On 08/16/18 at 12:07am, Yannik Sembritzki wrote:
> Signed-off-by: Yannik Sembritzki
> ---
> arch/x86/kernel/kexec-bzimage64.c | 2 +-
> certs/system_keyring.c | 3 ++-
> crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
> include/linux/verification.h | 3 +++
> 4
On 08/16/18 at 12:07am, Yannik Sembritzki wrote:
> Signed-off-by: Yannik Sembritzki
> ---
> arch/x86/kernel/kexec-bzimage64.c | 2 +-
> certs/system_keyring.c | 3 ++-
> crypto/asymmetric_keys/pkcs7_key_type.c | 2 +-
> include/linux/verification.h | 3 +++
> 4
On 08/16/18 at 08:52am, Dave Young wrote:
> On 08/15/18 at 01:42pm, Vivek Goyal wrote:
> > On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > > Would this be okay?
> >
> > [ CC dave young, Baoquan, Justin Forbes]
> >
> > Hi Yannik,
&g
On 08/16/18 at 08:52am, Dave Young wrote:
> On 08/15/18 at 01:42pm, Vivek Goyal wrote:
> > On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > > Would this be okay?
> >
> > [ CC dave young, Baoquan, Justin Forbes]
> >
> > Hi Yannik,
&g
On 08/15/18 at 01:42pm, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > Would this be okay?
>
> [ CC dave young, Baoquan, Justin Forbes]
>
> Hi Yannik,
>
> I am reading that bug and wondering that what broke it. It used to w
On 08/15/18 at 01:42pm, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > Would this be okay?
>
> [ CC dave young, Baoquan, Justin Forbes]
>
> Hi Yannik,
>
> I am reading that bug and wondering that what broke it. It used to w
Apologize for late reply, I'm occupied with something else.
On 08/10/18 at 07:39pm, Mike Galbraith wrote:
> On Fri, 2018-08-10 at 18:28 +0800, Dave Young wrote:
> >
> > > @@ -250,8 +253,10 @@ setup_boot_parameters(struct kimage *image, struct
> > > boot_params *pa
Apologize for late reply, I'm occupied with something else.
On 08/10/18 at 07:39pm, Mike Galbraith wrote:
> On Fri, 2018-08-10 at 18:28 +0800, Dave Young wrote:
> >
> > > @@ -250,8 +253,10 @@ setup_boot_parameters(struct kimage *image, struct
> > > boot_params *pa
On 08/10/18 at 04:45pm, Dave Young wrote:
> On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> > When booting with efi=noruntime, we call efi_runtime_map_copy() while
> > loading the kdump kernel, and trip over a NULL efi.memmap.map. Avoid
> > that and a useless allocation whe
On 08/10/18 at 04:45pm, Dave Young wrote:
> On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> > When booting with efi=noruntime, we call efi_runtime_map_copy() while
> > loading the kdump kernel, and trip over a NULL efi.memmap.map. Avoid
> > that and a useless allocation whe
On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> When booting with efi=noruntime, we call efi_runtime_map_copy() while
> loading the kdump kernel, and trip over a NULL efi.memmap.map. Avoid
> that and a useless allocation when the only mapping we can use (1:1)
> is not available.
>
>
On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> When booting with efi=noruntime, we call efi_runtime_map_copy() while
> loading the kdump kernel, and trip over a NULL efi.memmap.map. Avoid
> that and a useless allocation when the only mapping we can use (1:1)
> is not available.
>
>
>
> Signed-off-by: AKASHI Takahiro
> Cc: "Eric W. Biederman"
> Cc: Dave Young
> Cc: Vivek Goyal
> Cc: Baoquan He
> Acked-by: James Morse
> ---
> arch/powerpc/kernel/machine_kexec_file_64.c | 54 ---
> include/linux/kexec.h
>
> Signed-off-by: AKASHI Takahiro
> Cc: "Eric W. Biederman"
> Cc: Dave Young
> Cc: Vivek Goyal
> Cc: Baoquan He
> Acked-by: James Morse
> ---
> arch/powerpc/kernel/machine_kexec_file_64.c | 54 ---
> include/linux/kexec.h
On 05/24/18 at 11:14am, David Hildenbrand wrote:
> On 24.05.2018 10:56, Dave Young wrote:
> > Hi,
> >
> > [snip]
> >>>
> >>>> For kdump and onlining/offlining code, we
> >>>> have to mark pages as offline before a new segment is
On 05/24/18 at 11:14am, David Hildenbrand wrote:
> On 24.05.2018 10:56, Dave Young wrote:
> > Hi,
> >
> > [snip]
> >>>
> >>>> For kdump and onlining/offlining code, we
> >>>> have to mark pages as offline before a new segment is
Hi Eric,
On 05/24/18 at 11:41am, Eric W. Biederman wrote:
> Dave Young <dyo...@redhat.com> writes:
>
> > Hi Eric,
> > On 05/23/18 at 10:53am, Eric W. Biederman wrote:
> >> Dave Young <dyo...@redhat.com> writes:
> >>
&g
Hi Eric,
On 05/24/18 at 11:41am, Eric W. Biederman wrote:
> Dave Young writes:
>
> > Hi Eric,
> > On 05/23/18 at 10:53am, Eric W. Biederman wrote:
> >> Dave Young writes:
> >>
> >> > [snip]
> >> >
> >> >> >
Hi,
[snip]
> >
> >> For kdump and onlining/offlining code, we
> >> have to mark pages as offline before a new segment is visible to the system
> >> (e.g. as these pages might not be backed by real memory in the hypervisor).
> >
> > Please expand on the kdump part. That is really confusing
Hi,
[snip]
> >
> >> For kdump and onlining/offlining code, we
> >> have to mark pages as offline before a new segment is visible to the system
> >> (e.g. as these pages might not be backed by real memory in the hypervisor).
> >
> > Please expand on the kdump part. That is really confusing
> > > Instead of setting aside a significant chunk of memory nobody can use,
> > > [...] reserve a significant chunk of memory that the kernel is prevented
> > > from using [...], but applications are free to use it.
> >
> > That works great, because user space pages are filtered out in the
> >
> > > Instead of setting aside a significant chunk of memory nobody can use,
> > > [...] reserve a significant chunk of memory that the kernel is prevented
> > > from using [...], but applications are free to use it.
> >
> > That works great, because user space pages are filtered out in the
> >
On 05/24/18 at 03:26pm, Dave Young wrote:
> On 05/24/18 at 08:57am, Petr Tesarik wrote:
> > On Thu, 24 May 2018 09:49:05 +0800
> > Dave Young <dyo...@redhat.com> wrote:
> >
> > > Hi Petr,
> > >
> > > On 05/23/18 at 10:22pm, Petr Tesarik wro
On 05/24/18 at 03:26pm, Dave Young wrote:
> On 05/24/18 at 08:57am, Petr Tesarik wrote:
> > On Thu, 24 May 2018 09:49:05 +0800
> > Dave Young wrote:
> >
> > > Hi Petr,
> > >
> > > On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> > >
On 05/24/18 at 08:57am, Petr Tesarik wrote:
> On Thu, 24 May 2018 09:49:05 +0800
> Dave Young <dyo...@redhat.com> wrote:
>
> > Hi Petr,
> >
> > On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> >[...]
> > > In short, if one size fits none,
On 05/24/18 at 08:57am, Petr Tesarik wrote:
> On Thu, 24 May 2018 09:49:05 +0800
> Dave Young wrote:
>
> > Hi Petr,
> >
> > On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> >[...]
> > > In short, if one size fits none, what good is it to hardcode t
Hi Petr,
On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> On Wed, 23 May 2018 10:53:55 -0500
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
> > Dave Young <dyo...@redhat.com> writes:
> >
> > > [snip]
> > >
> > >> >
> >
Hi Petr,
On 05/23/18 at 10:22pm, Petr Tesarik wrote:
> On Wed, 23 May 2018 10:53:55 -0500
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
> > Dave Young writes:
> >
> > > [snip]
> > >
> > >> >
> > >> > +config CRA
Hi Eric,
On 05/23/18 at 10:53am, Eric W. Biederman wrote:
> Dave Young <dyo...@redhat.com> writes:
>
> > [snip]
> >
> >> >
> >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
> >> > +int "System memory size threshold fo
Hi Eric,
On 05/23/18 at 10:53am, Eric W. Biederman wrote:
> Dave Young writes:
>
> > [snip]
> >
> >> >
> >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
> >> > +int "System memory size threshold for kdump memory defau
the old effort:
https://lkml.org/lkml/2009/8/12/61
https://lwn.net/Articles/345344/
I changed the original design, instead of adding the auto reserve logic
in code, in this patch just introduce two kernel config options for
the default crashkernel value in MB and the threshold of system memory
in MB
the old effort:
https://lkml.org/lkml/2009/8/12/61
https://lwn.net/Articles/345344/
I changed the original design, instead of adding the auto reserve logic
in code, in this patch just introduce two kernel config options for
the default crashkernel value in MB and the threshold of system memory
On 05/21/18 at 12:02pm, Andrew Morton wrote:
> On Mon, 21 May 2018 10:53:37 +0800 Dave Young <dyo...@redhat.com> wrote:
>
> > This is a rework of the crashkernel=auto patches back to 2009 although
> > I'm not sure if below is the last version of the old effort:
> > h
On 05/21/18 at 12:02pm, Andrew Morton wrote:
> On Mon, 21 May 2018 10:53:37 +0800 Dave Young wrote:
>
> > This is a rework of the crashkernel=auto patches back to 2009 although
> > I'm not sure if below is the last version of the old effort:
> > https://lkml.org/lkm
On 05/21/18 at 12:02pm, Andrew Morton wrote:
> On Mon, 21 May 2018 10:53:37 +0800 Dave Young <dyo...@redhat.com> wrote:
>
> > This is a rework of the crashkernel=auto patches back to 2009 although
> > I'm not sure if below is the last version of the old effort:
> > h
On 05/21/18 at 12:02pm, Andrew Morton wrote:
> On Mon, 21 May 2018 10:53:37 +0800 Dave Young wrote:
>
> > This is a rework of the crashkernel=auto patches back to 2009 although
> > I'm not sure if below is the last version of the old effort:
> > https://lkml.org/lkm
not need to manually set kernel cmdline
for common use cases and one can still overwrite the default value
with manual setup or disable it by using crashkernel=0
Signed-off-by: Dave Young <dyo...@redhat.com>
---
Another difference is with original design the crashkernel size scales
with system
not need to manually set kernel cmdline
for common use cases and one can still overwrite the default value
with manual setup or disable it by using crashkernel=0
Signed-off-by: Dave Young
---
Another difference is with original design the crashkernel size scales
with system memory, according to test
On 04/27/18 at 05:14pm, Dave Young wrote:
> Hi,
>
> This is a resend of below patches:
> http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
>
> I dropped the original patch 1 since Baoquan is not happy with it.
> For patch 2 (the 1st patch in this s
On 04/27/18 at 05:14pm, Dave Young wrote:
> Hi,
>
> This is a resend of below patches:
> http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
>
> I dropped the original patch 1 since Baoquan is not happy with it.
> For patch 2 (the 1st patch in this s
ic int kexec_image_post_load_cleanup_default(struct kimage *image)
> +int kexec_image_post_load_cleanup_default(struct kimage *image)
> {
> if (!image->fops || !image->fops->cleanup)
> return 0;
> --
> 2.17.0
>
>
> _____
On 04/25/18 at 03:26pm, AKASHI Takahiro wrote:
> Change this function from static to global so that arm64 can implement
> its own arch_kimage_file_post_load_cleanup() later using
> kexec_image_post_load_cleanup_default().
>
> Signed-off-by: AKASHI Takahiro
> Cc: Dave Young
On 04/28/18 at 08:56am, Dave Young wrote:
> On 04/27/18 at 04:12pm, Bjorn Helgaas wrote:
> > [+cc Eric, Vivek, kexec list]
> >
> > On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote:
> > > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote:
> > > > Sinan
On 04/28/18 at 08:56am, Dave Young wrote:
> On 04/27/18 at 04:12pm, Bjorn Helgaas wrote:
> > [+cc Eric, Vivek, kexec list]
> >
> > On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote:
> > > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote:
> > > > Sinan
On 04/27/18 at 04:12pm, Bjorn Helgaas wrote:
> [+cc Eric, Vivek, kexec list]
>
> On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote:
> > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote:
> > > Sinan mooted the idea of using a "no-wait" path of sending the "don't
> > > generate hotplug
On 04/27/18 at 04:12pm, Bjorn Helgaas wrote:
> [+cc Eric, Vivek, kexec list]
>
> On Fri, Apr 27, 2018 at 03:34:30PM -0400, Sinan Kaya wrote:
> > On 4/27/2018 3:22 PM, Bjorn Helgaas wrote:
> > > Sinan mooted the idea of using a "no-wait" path of sending the "don't
> > > generate hotplug
Hi,
This is a resend of below patches:
http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
I dropped the original patch 1 since Baoquan is not happy with it.
For patch 2 (the 1st patch in this series), there is some improvement
comment from Baoquan to create some generic
Hi,
This is a resend of below patches:
http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
I dropped the original patch 1 since Baoquan is not happy with it.
For patch 2 (the 1st patch in this series), there is some improvement
comment from Baoquan to create some generic
On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
> On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> > Hi Rahul,
> > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> > > On production servers running variety of workloads over time, kernel
> > &
On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
> On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> > Hi Rahul,
> > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> > > On production servers running variety of workloads over time, kernel
> > &
Hi Rahul,
On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> On production servers running variety of workloads over time, kernel
> panic can happen sporadically after days or even months. It is
> important to collect as much debug logs as possible to root cause
> and fix the problem, that may not
Hi Rahul,
On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> On production servers running variety of workloads over time, kernel
> panic can happen sporadically after days or even months. It is
> important to collect as much debug logs as possible to root cause
> and fix the problem, that may not
for the kexec buffer internal use
Actually kexec should pass exact size of the efi memmap to 2nd kernel.
Signed-off-by: Dave Young <dyo...@redhat.com>
Reported-by: joeyli <j...@suse.com>
Tested-by: Randy Wright <rwri...@hpe.com>
---
arch/x86/kernel/kexec-bzimage64.c |5 ++---
for the kexec buffer internal use
Actually kexec should pass exact size of the efi memmap to 2nd kernel.
Signed-off-by: Dave Young
Reported-by: joeyli
Tested-by: Randy Wright
---
arch/x86/kernel/kexec-bzimage64.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux.orig/arch/x86
On 04/16/18 at 06:35pm, Randy Wright wrote:
> On Mon, Apr 16, 2018 at 02:37:38PM +0800, joeyli wrote:
> > Hi Randy,
> > ...
> > Randy, do you want to try Dave's kexec patch on your environment? Please
> > remove
> > my patch first.
> >
> > Thanks a lot!
> > Joey Lee
>
> Hi Joey,
>
> I tried
On 04/16/18 at 06:35pm, Randy Wright wrote:
> On Mon, Apr 16, 2018 at 02:37:38PM +0800, joeyli wrote:
> > Hi Randy,
> > ...
> > Randy, do you want to try Dave's kexec patch on your environment? Please
> > remove
> > my patch first.
> >
> > Thanks a lot!
> > Joey Lee
>
> Hi Joey,
>
> I tried
101 - 200 of 2643 matches
Mail list logo
