Ccing efi people.
On 12/16/16 at 02:33pm, Jean Delvare wrote:
> On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote:
> > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > > I am no kexec expert b
Ccing efi people.
On 12/16/16 at 02:33pm, Jean Delvare wrote:
> On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote:
> > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > > I am no kexec expert b
On 12/16/16 at 02:18pm, Andy Shevchenko wrote:
> On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > Hi Andy,
> > >
> > > On Fri, 2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > > > Unt
On 12/16/16 at 02:18pm, Andy Shevchenko wrote:
> On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > Hi Andy,
> > >
> > > On Fri, 2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > > > Unt
On 12/15/16 at 12:28pm, Jean Delvare wrote:
> Hi Andy,
>
> On Fri, 2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > Until now kexec'ed kernel has no clue where to look for DMI entry point.
> >
> > Pass it via kernel command line parameter in the same way as it's done for
> > ACPI
> >
On 12/15/16 at 12:28pm, Jean Delvare wrote:
> Hi Andy,
>
> On Fri, 2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > Until now kexec'ed kernel has no clue where to look for DMI entry point.
> >
> > Pass it via kernel command line parameter in the same way as it's done for
> > ACPI
> >
Hi Hari
Personally I like V1 more, but split the patch 2 is easier for ia64
people to reivew. I did basic x86 testing, it runs ok.
On 11/25/16 at 05:24pm, Hari Bathini wrote:
> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under
Hi Hari
Personally I like V1 more, but split the patch 2 is easier for ia64
people to reivew. I did basic x86 testing, it runs ok.
On 11/25/16 at 05:24pm, Hari Bathini wrote:
> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under
On 11/30/16 at 09:13pm, Eric W. Biederman wrote:
> Dave Young <dyo...@redhat.com> writes:
>
> > Hi, Laura
> > On 11/29/16 at 10:55am, Laura Abbott wrote:
> >>
> >> __pa_symbol is the correct api to get the physical address of kernel
> >> symbo
On 11/30/16 at 09:13pm, Eric W. Biederman wrote:
> Dave Young writes:
>
> > Hi, Laura
> > On 11/29/16 at 10:55am, Laura Abbott wrote:
> >>
> >> __pa_symbol is the correct api to get the physical address of kernel
> >> symbols. Switch to it to all
Hi, Laura
On 11/29/16 at 10:55am, Laura Abbott wrote:
>
> __pa_symbol is the correct api to get the physical address of kernel
> symbols. Switch to it to allow for better debug checking.
>
I assume __pa_symbol is faster than __pa, but it still need some testing
on all arches which support
Hi, Laura
On 11/29/16 at 10:55am, Laura Abbott wrote:
>
> __pa_symbol is the correct api to get the physical address of kernel
> symbols. Switch to it to allow for better debug checking.
>
I assume __pa_symbol is faster than __pa, but it still need some testing
on all arches which support
On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote:
> Hello Dave,
>
> Thanks for your review.
>
> Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> > > powerpc's purgatory.ro has
On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote:
> Hello Dave,
>
> Thanks for your review.
>
> Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> > > powerpc's purgatory.ro has
On 11/22/16 at 11:44am, Thiago Jung Bauermann wrote:
> Am Dienstag, 22. November 2016, 17:01:10 BRST schrieb Michael Ellerman:
> > Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes:
> > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
>
On 11/22/16 at 11:44am, Thiago Jung Bauermann wrote:
> Am Dienstag, 22. November 2016, 17:01:10 BRST schrieb Michael Ellerman:
> > Thiago Jung Bauermann writes:
> > > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> > >> On 11/10/16 at 01:27a
Hi Michael
On 11/22/16 at 05:01pm, Michael Ellerman wrote:
> Thiago Jung Bauermann <bauer...@linux.vnet.ibm.com> writes:
> > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> >> On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> >> > powe
Hi Michael
On 11/22/16 at 05:01pm, Michael Ellerman wrote:
> Thiago Jung Bauermann writes:
> > Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> >> On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> >> > powerpc's purgatory.ro has
On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote:
> Hello Dave,
>
> Thanks for your review.
>
> Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> > > powerpc's purgatory.ro has
On 11/21/16 at 09:49pm, Thiago Jung Bauermann wrote:
> Hello Dave,
>
> Thanks for your review.
>
> Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young:
> > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> > > powerpc's purgatory.ro has
On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> powerpc's purgatory.ro has 12 relocation types when built as
> a relocatable object. To implement support for them requires
> arch_kexec_apply_relocations_add to duplicate a lot of code with
> module_64.c:apply_relocate_add.
>
> When built as
On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote:
> powerpc's purgatory.ro has 12 relocation types when built as
> a relocatable object. To implement support for them requires
> arch_kexec_apply_relocations_add to duplicate a lot of code with
> module_64.c:apply_relocate_add.
>
> When built as
On 10/06/16 at 04:46pm, Baoquan He wrote:
> KASLR memory randomization can randomize the base of the physical memory
> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> utility, mainly makedumpfile can use them
On 10/06/16 at 04:46pm, Baoquan He wrote:
> KASLR memory randomization can randomize the base of the physical memory
> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> utility, mainly makedumpfile can use them
On 10/13/16 at 04:53pm, Baoquan He wrote:
> Hi Pratyush,
>
> On 10/12/16 at 02:39pm, Pratyush Anand wrote:
> >
> >
> > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote:
> > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
> > > > > VMALLOC_BASE and VMEMMAP_BASE is
On 10/13/16 at 04:53pm, Baoquan He wrote:
> Hi Pratyush,
>
> On 10/12/16 at 02:39pm, Pratyush Anand wrote:
> >
> >
> > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote:
> > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
> > > > > VMALLOC_BASE and VMEMMAP_BASE is
On 10/11/16 at 04:19pm, Dave Young wrote:
> On 10/11/16 at 03:41pm, Baoquan He wrote:
> > Hi Eric,
> >
> > Thanks a lot for your reviewing! Sorry for late reply.
> >
> > On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > > Baoquan He <b...@re
On 10/11/16 at 04:19pm, Dave Young wrote:
> On 10/11/16 at 03:41pm, Baoquan He wrote:
> > Hi Eric,
> >
> > Thanks a lot for your reviewing! Sorry for late reply.
> >
> > On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > > Baoquan He writes:
>
On 10/11/16 at 03:41pm, Baoquan He wrote:
> Hi Eric,
>
> Thanks a lot for your reviewing! Sorry for late reply.
>
> On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > Baoquan He writes:
> >
> > > KASLR memory randomization can randomize the base of the physical memory
> > >
On 10/11/16 at 03:41pm, Baoquan He wrote:
> Hi Eric,
>
> Thanks a lot for your reviewing! Sorry for late reply.
>
> On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > Baoquan He writes:
> >
> > > KASLR memory randomization can randomize the base of the physical memory
> > > mapping
On 10/10/16 at 07:12am, Greg Kroah-Hartman wrote:
> On Mon, Oct 10, 2016 at 10:50:50AM +0800, Dave Young wrote:
> > On 10/10/16 at 10:44am, Dave Young wrote:
> > > On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote:
> > > > On Fri, Oct 07, 2016 at 10:0
On 10/10/16 at 07:12am, Greg Kroah-Hartman wrote:
> On Mon, Oct 10, 2016 at 10:50:50AM +0800, Dave Young wrote:
> > On 10/10/16 at 10:44am, Dave Young wrote:
> > > On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote:
> > > > On Fri, Oct 07, 2016 at 10:0
Kconfig comment suggests setting it as "n" if in doubt thus move the
default value to 'n'.
Signed-off-by: Dave Young <dyo...@redhat.com>
Suggested-by: Kees Cook <keesc...@chromium.org>
---
Greg: drop the "default" line will set the default as n
drivers/char/Kco
Kconfig comment suggests setting it as "n" if in doubt thus move the
default value to 'n'.
Signed-off-by: Dave Young
Suggested-by: Kees Cook
---
Greg: drop the "default" line will set the default as n
drivers/char/Kconfig |1 -
1 file changed, 1 deletion(-)
--- linux-x
On 10/10/16 at 10:44am, Dave Young wrote:
> On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote:
> > On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote:
> > > Kconfig comment suggests setting it as "n" if in doubt thus move the
> > > default value to
On 10/10/16 at 10:44am, Dave Young wrote:
> On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote:
> > On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote:
> > > Kconfig comment suggests setting it as "n" if in doubt thus move the
> > > default value to
On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote:
> On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote:
> > Kconfig comment suggests setting it as "n" if in doubt thus move the
> > default value to 'n'.
> >
> > Signed-off-by: Dave Young <dyo...
On 10/07/16 at 05:57am, Greg Kroah-Hartman wrote:
> On Fri, Oct 07, 2016 at 10:04:11AM +0800, Dave Young wrote:
> > Kconfig comment suggests setting it as "n" if in doubt thus move the
> > default value to 'n'.
> >
> > Signed-off-by: Dave Young
> > Su
Hi,
Below bug happened to me while loop mount a file image after stopping a
kvm guest. But it only happend once til now..
[ 4761.031686] [ cut here ]
[ 4761.075984] kernel BUG at lib/percpu-refcount.c:231!
[ 4761.120184] invalid opcode: [#1] SMP
[ 4761.164307]
Hi,
Below bug happened to me while loop mount a file image after stopping a
kvm guest. But it only happend once til now..
[ 4761.031686] [ cut here ]
[ 4761.075984] kernel BUG at lib/percpu-refcount.c:231!
[ 4761.120184] invalid opcode: [#1] SMP
[ 4761.164307]
Kconfig comment suggests setting it as "n" if in doubt thus move the
default value to 'n'.
Signed-off-by: Dave Young <dyo...@redhat.com>
Suggested-by: Kees Cook <keesc...@chromium.org>
---
drivers/char/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
Kconfig comment suggests setting it as "n" if in doubt thus move the
default value to 'n'.
Signed-off-by: Dave Young
Suggested-by: Kees Cook
---
drivers/char/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-x86.orig/drivers/char/Kconfig
+++ linux-x86/dr
On 10/06/16 at 02:39pm, Kees Cook wrote:
> On Wed, Oct 5, 2016 at 10:12 PM, Dave Young <dyo...@redhat.com> wrote:
> > With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless
> > even if it is set =y, thus let's update the dependency in Kconfig.
> >
> &g
On 10/06/16 at 02:39pm, Kees Cook wrote:
> On Wed, Oct 5, 2016 at 10:12 PM, Dave Young wrote:
> > With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless
> > even if it is set =y, thus let's update the dependency in Kconfig.
> >
> > Signed-off-by: Dave Youn
With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless
even if it is set =y, thus let's update the dependency in Kconfig.
Signed-off-by: Dave Young <dyo...@redhat.com>
---
lib/Kconfig.debug |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-x86.orig/lib/Kconfig
With CONFIG_DEVMEM not set, CONFIG_STRICT_DEVMEM will be useless
even if it is set =y, thus let's update the dependency in Kconfig.
Signed-off-by: Dave Young
---
lib/Kconfig.debug |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-x86.orig/lib/Kconfig.debug
+++ linux-x86/lib
Hi, 河合英宏
Thanks for the patch log update, it looks good to me.
Acked-by: Dave Young <dyo...@redhat.com>
On 09/20/16 at 11:22am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> Here is the revised commit description reflecting Dave's
> comment. Cc list was copied from -mm version.
>
> Fr
Hi, 河合英宏
Thanks for the patch log update, it looks good to me.
Acked-by: Dave Young
On 09/20/16 at 11:22am, 河合英宏 / KAWAI,HIDEHIRO wrote:
> Here is the revised commit description reflecting Dave's
> comment. Cc list was copied from -mm version.
>
> From: Hidehiro Kawai
> Sub
Hi, Mimi
On 08/30/16 at 06:40pm, Mimi Zohar wrote:
> From: Thiago Jung Bauermann
>
> This patch uses the kexec buffer passing mechanism to pass the
> serialized IMA binary_runtime_measurements to the next kernel.
>
> Changelog v2:
> - Fix build issue by defining a
Hi, Mimi
On 08/30/16 at 06:40pm, Mimi Zohar wrote:
> From: Thiago Jung Bauermann
>
> This patch uses the kexec buffer passing mechanism to pass the
> serialized IMA binary_runtime_measurements to the next kernel.
>
> Changelog v2:
> - Fix build issue by defining a stub ima_add_kexec_buffer and
Hi Dave,
>
> On 30/08/2016:04:22:30 PM, Dave Young wrote:
> > Hi, Pratyush
> >
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt() is called just after irq regist
Hi Dave,
>
> On 30/08/2016:04:22:30 PM, Dave Young wrote:
> > Hi, Pratyush
> >
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt() is called just after irq regist
On 08/30/16 at 04:38pm, Dave Young wrote:
> On 08/30/16 at 04:22pm, Dave Young wrote:
> > Hi, Pratyush
> >
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt(
On 08/30/16 at 04:38pm, Dave Young wrote:
> On 08/30/16 at 04:22pm, Dave Young wrote:
> > Hi, Pratyush
> >
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt(
On 08/30/16 at 04:22pm, Dave Young wrote:
> Hi, Pratyush
>
> On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > We have observed on few x86 machines with rtc-cmos device that
> > hpet_rtc_interrupt() is called just after irq registration and before
> >
On 08/30/16 at 04:22pm, Dave Young wrote:
> Hi, Pratyush
>
> On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > We have observed on few x86 machines with rtc-cmos device that
> > hpet_rtc_interrupt() is called just after irq registration and before
> >
Hi, Pratyush
On 08/16/16 at 08:55am, Pratyush Anand wrote:
> We have observed on few x86 machines with rtc-cmos device that
> hpet_rtc_interrupt() is called just after irq registration and before
> cmos_do_probe() could call hpet_rtc_timer_init().
>
> So, neither hpet_default_delta nor
Hi, Pratyush
On 08/16/16 at 08:55am, Pratyush Anand wrote:
> We have observed on few x86 machines with rtc-cmos device that
> hpet_rtc_interrupt() is called just after irq registration and before
> cmos_do_probe() could call hpet_rtc_timer_init().
>
> So, neither hpet_default_delta nor
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
>
> On 8/25/16, 1:10 AM, "Michal Hocko" wrote:
>
> >[Let's add kdump people]
> >
> >On Wed 24-08-16 16:38:56, Himanshu Madhani wrote:
> >> Hello list,
> >>
> >> I am wondering if anybody has issue capturing crash dump with
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
>
> On 8/25/16, 1:10 AM, "Michal Hocko" wrote:
>
> >[Let's add kdump people]
> >
> >On Wed 24-08-16 16:38:56, Himanshu Madhani wrote:
> >> Hello list,
> >>
> >> I am wondering if anybody has issue capturing crash dump with the 4.6.0
> >> and
On 08/25/16 at 11:00pm, Hari Bathini wrote:
>
>
> On Thursday 25 August 2016 12:31 PM, Dave Young wrote:
> > On 08/10/16 at 03:35pm, Hari Bathini wrote:
> > > When fadump is enabled, by default 5% of system RAM is reserved for
> > > fadump kernel. While that wor
On 08/25/16 at 11:00pm, Hari Bathini wrote:
>
>
> On Thursday 25 August 2016 12:31 PM, Dave Young wrote:
> > On 08/10/16 at 03:35pm, Hari Bathini wrote:
> > > When fadump is enabled, by default 5% of system RAM is reserved for
> > > fadump kernel. While that wor
On 08/10/16 at 03:35pm, Hari Bathini wrote:
> When fadump is enabled, by default 5% of system RAM is reserved for
> fadump kernel. While that works for most cases, it is not good enough
> for every case.
>
> Currently, to override the default value, fadump supports specifying
> memory to reserve
On 08/10/16 at 03:35pm, Hari Bathini wrote:
> When fadump is enabled, by default 5% of system RAM is reserved for
> fadump kernel. While that works for most cases, it is not good enough
> for every case.
>
> Currently, to override the default value, fadump supports specifying
> memory to reserve
On 08/23/16 at 06:11pm, Yinghai Lu wrote:
> On Wed, Aug 17, 2016 at 1:20 AM, Dave Young <dyo...@redhat.com> wrote:
> > On 08/17/16 at 09:50am, Xunlei Pang wrote:
> >> "/sys/kernel/kexec_crash_size" only handles crashk_res, it
> >> is fine in most
On 08/23/16 at 06:11pm, Yinghai Lu wrote:
> On Wed, Aug 17, 2016 at 1:20 AM, Dave Young wrote:
> > On 08/17/16 at 09:50am, Xunlei Pang wrote:
> >> "/sys/kernel/kexec_crash_size" only handles crashk_res, it
> >> is fine in most cases, but sometimes we have c
On 08/22/16 at 04:49pm, Icenowy Zheng wrote:
>
>
> 22.08.2016, 15:28, "Dave Young" <dyo...@redhat.com>:
> > On 08/18/16 at 09:41pm, Matt Fleming wrote:
> >> On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> >> >
> >> > Could
On 08/22/16 at 04:49pm, Icenowy Zheng wrote:
>
>
> 22.08.2016, 15:28, "Dave Young" :
> > On 08/18/16 at 09:41pm, Matt Fleming wrote:
> >> On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> >> >
> >> > Could we add some quirk for th
On 08/18/16 at 09:41pm, Matt Fleming wrote:
> On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> >
> > Could we add some quirk for these broken hardware instead of changing
> > the normal code?
>
> I'd prefer not to do that if possible. Due to the way that the BIOS
&
On 08/18/16 at 09:41pm, Matt Fleming wrote:
> On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> >
> > Could we add some quirk for these broken hardware instead of changing
> > the normal code?
>
> I'd prefer not to do that if possible. Due to the way that the BIOS
&
On 08/22/16 at 12:38am, Thiago Jung Bauermann wrote:
> Am Montag, 22 August 2016, 11:21:35 schrieb Dave Young:
> > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > > diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> > > b/arch/powerpc/kernel/machine_kexec_64
On 08/22/16 at 12:38am, Thiago Jung Bauermann wrote:
> Am Montag, 22 August 2016, 11:21:35 schrieb Dave Young:
> > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > > diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> > > b/arch/powerpc/kernel/machine_kexec_64
On 08/22/16 at 12:25am, Thiago Jung Bauermann wrote:
> Am Montag, 22 August 2016, 11:17:45 schrieb Dave Young:
> > On 08/18/16 at 06:09pm, Thiago Jung Bauermann wrote:
> > > Hello Dave,
> > >
> > > Thanks for your review!
> > >
> > > [ Tr
On 08/22/16 at 12:25am, Thiago Jung Bauermann wrote:
> Am Montag, 22 August 2016, 11:17:45 schrieb Dave Young:
> > On 08/18/16 at 06:09pm, Thiago Jung Bauermann wrote:
> > > Hello Dave,
> > >
> > > Thanks for your review!
> > >
> > > [ Tr
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> The buffer hand-over mechanism allows the currently running kernel to pass
> data to kernel that will be kexec'd via a kexec segment. The second kernel
> can check whether the previous kernel sent data and retrieve it.
>
> This is the
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> The buffer hand-over mechanism allows the currently running kernel to pass
> data to kernel that will be kexec'd via a kexec segment. The second kernel
> can check whether the previous kernel sent data and retrieve it.
>
> This is the
the trimming.
>
> Am Donnerstag, 18 August 2016, 17:03:30 schrieb Dave Young:
> > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > > Adds checksum argument to kexec_add_buffer specifying whether the given
> > > segment should be part of the checksum calcu
the trimming.
>
> Am Donnerstag, 18 August 2016, 17:03:30 schrieb Dave Young:
> > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > > Adds checksum argument to kexec_add_buffer specifying whether the given
> > > segment should be part of the checksum calcu
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> Adds checksum argument to kexec_add_buffer specifying whether the given
> segment should be part of the checksum calculation.
>
Since it is used with add buffer, could it be added to kbuf as a new
field?
Like kbuf.no_checksum, default value
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> Adds checksum argument to kexec_add_buffer specifying whether the given
> segment should be part of the checksum calculation.
>
Since it is used with add buffer, could it be added to kbuf as a new
field?
Like kbuf.no_checksum, default value
);
> image->initrd_buf = NULL;
>
> + vfree(image->dtb_buf);
> + image->dtb_buf = NULL;
> +
> kfree(image->cmdline_buf);
> image->cmdline_buf = NULL;
>
> --
> 1.9.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young <dyo...@redhat.com>
Thanks
Dave
vfree(image->dtb_buf);
> + image->dtb_buf = NULL;
> +
> kfree(image->cmdline_buf);
> image->cmdline_buf = NULL;
>
> --
> 1.9.1
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young
Thanks
Dave
Since Eric was objecting the extension, I think you should convince him,
but I will review from code point of view.
On 08/11/16 at 08:03pm, Thiago Jung Bauermann wrote:
> From: AKASHI Takahiro
>
> Device tree blob must be passed to a second kernel on DTB-capable
>
Since Eric was objecting the extension, I think you should convince him,
but I will review from code point of view.
On 08/11/16 at 08:03pm, Thiago Jung Bauermann wrote:
> From: AKASHI Takahiro
>
> Device tree blob must be passed to a second kernel on DTB-capable
> archs, like powerpc and arm64,
On 08/17/16 at 07:36pm, Joe Perches wrote:
> On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote:
> > nr_cpus can help to save memory. So we should remind user of it.
>
> trivia:
> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> []
> > @@ -390,9 +390,11 @@ Notes
On 08/17/16 at 07:36pm, Joe Perches wrote:
> On Thu, 2016-08-18 at 10:31 +0800, Zhou Wenjian wrote:
> > nr_cpus can help to save memory. So we should remind user of it.
>
> trivia:
> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> []
> > @@ -390,9 +390,11 @@ Notes
On 08/17/16 at 11:00am, Alex Thorlton wrote:
> On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > > Why do you guys need the physical mapping all of a sudden?
> > >
> > > It's not that we need it all of the sudden, necessarily, it's just that
>
On 08/17/16 at 11:00am, Alex Thorlton wrote:
> On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > > Why do you guys need the physical mapping all of a sudden?
> > >
> > > It's not that we need it all of the sudden, necessarily, it's just that
>
rface,
> and users should be aware of what they are doing.
Cc Yinghai Lu for review since he introduced the ,high and ,low logic.
>
> Suggested-by: Dave Young <dyo...@redhat.com>
> Signed-off-by: Xunlei Pang <xlp...@redhat.com>
> ---
> include/linu
rface,
> and users should be aware of what they are doing.
Cc Yinghai Lu for review since he introduced the ,high and ,low logic.
>
> Suggested-by: Dave Young
> Signed-off-by: Xunlei Pang
> ---
> include/linux/kexec.h | 4 ++--
> kernel/kexec_core.c | 23
Hi, Xunlei,
On 08/17/16 at 09:50am, Xunlei Pang wrote:
> We have crashk_res only in most cases, but sometimes we have
> crashk_low_res.
>
> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
> combined with "crashkernel=128M,low" is used, so some segments
> may have the chance to be
Hi, Xunlei,
On 08/17/16 at 09:50am, Xunlei Pang wrote:
> We have crashk_res only in most cases, but sometimes we have
> crashk_low_res.
>
> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
> combined with "crashkernel=128M,low" is used, so some segments
> may have the chance to be
> > Why do you guys need the physical mapping all of a sudden?
>
> It's not that we need it all of the sudden, necessarily, it's just that
> we've had to make other changes to make things work with the new,
> (almost) completely isolated, EFI page tables. We ended up choosing the
> lesser of two
> > Why do you guys need the physical mapping all of a sudden?
>
> It's not that we need it all of the sudden, necessarily, it's just that
> we've had to make other changes to make things work with the new,
> (almost) completely isolated, EFI page tables. We ended up choosing the
> lesser of two
On 08/15/16 at 01:56pm, Matt Fleming wrote:
> On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> > Some broken firmwares have a wrongly filled version field in BGRT table.
> > (See http://wiki.osdev.org/Broken_UEFI_implementations )
> >
> > As we know, these firmwares can also provide correct
On 08/15/16 at 01:56pm, Matt Fleming wrote:
> On Tue, 09 Aug, at 01:25:46PM, Icenowy Zheng wrote:
> > Some broken firmwares have a wrongly filled version field in BGRT table.
> > (See http://wiki.osdev.org/Broken_UEFI_implementations )
> >
> > As we know, these firmwares can also provide correct
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> Hello,
>
> This patch series implements a mechanism which allows the kernel to pass
> on a buffer to the kernel that will be kexec'd. This buffer is passed
> as a segment which is added to the kimage when it is being prepared
> by
On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> Hello,
>
> This patch series implements a mechanism which allows the kernel to pass
> on a buffer to the kernel that will be kexec'd. This buffer is passed
> as a segment which is added to the kimage when it is being prepared
> by
Hi,
On 08/15/16 at 04:05pm, Xunlei Pang wrote:
> On 2016/08/15 at 15:17, Dave Young wrote:
> > Hi Xunlei,
> >
> > On 08/13/16 at 04:26pm, Xunlei Pang wrote:
> >> "/sys/kernel/kexec_crash_size" only includes crashk_res, it
> >> is fine in
Hi,
On 08/15/16 at 04:05pm, Xunlei Pang wrote:
> On 2016/08/15 at 15:17, Dave Young wrote:
> > Hi Xunlei,
> >
> > On 08/13/16 at 04:26pm, Xunlei Pang wrote:
> >> "/sys/kernel/kexec_crash_size" only includes crashk_res, it
> >> is fine in
701 - 800 of 2643 matches
Mail list logo