ow to reach point for comprimise of this issue?
I think there's no method to work well on every environment. So
setting kernel parameter on each specific environemnt seems
preferable.
>From abf3c7525dd31bae77435c652037d5b65c645b2f Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Da
interpreted as NT_VMCORE_DEBUGINFO.
Test
This patch set is composed based on v3.9-rc3.
Done on x86-64, x86-32 both with 1GB and over 4GB memory environments.
---
HATAYAMA Daisuke (21):
vmcore: introduce mmap_vmcore()
vmcore: count holes generated by round-up operation for vmcore si
: Zhang Yanfei
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 56 +++---
1 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index b870f74..163281e 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc
patch adds one exceptional case where the number of PT_NOTE
entries is somehow 0. Then, immediately go out of the function.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 92 +++---
1 files changed, 74 insertions(+), 18 deletions(-)
diff
nto buffer on the 2nd kernel.
Signed-off-by: HATAYAMA Daisuke
---
include/linux/proc_fs.h |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 8307f2f..11dd592 100644
--- a/include/linux/proc_fs.h
+++ b/inc
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 68 --
1 files changed, 20 insertions(+), 48 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index b85ba32..7e21d64 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
To satisfy mmap()'s page-size boundary requirement, specify aligned
attribute to vmcoreinfo_note objects to allocate it on page-size
boundary.
Signed-off-by: HATAYAMA Daisuke
---
include/linux/kexec.h |6 --
kernel/kexec.c|2 +-
2 files changed, 5 insertions(+), 3 dele
This patch introduces NT_VMCORE_DEBUGINFO to a unique note type in
VMCOREINFO name, which has had no name so far. The name means that
it's a kind of note type in vmcoreinfo that contains system kernel's
debug information.
Signed-off-by: HATAYAMA Daisuke
---
include/uapi/linux/el
nservative viewpoint.
By this change, gdb and binutils work well without any change, but
makedumpfile and crash utility need their changes to distinguish two
note types in "VMCOREINFO" name space.
Signed-off-by: HATAYAMA Daisuke
---
include/uapi/linux/elf.h |1 +
1 files change
Modern kernel marks the end of ELF note buffer with NT_VMCORE_PAD type
note in order to make the buffer satisfy mmap()'s page-size boundary
requirement. This patch makes finishing reading each buffer if the
note type now being read is NT_VMCORE_PAD type.
Signed-off-by: HATAYAMA Daisuke
---
86_64 is 5120, where note
segments exceed 1MB with NT_PRSTATUS only.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 2a0f885..0077a9a 100644
--- a/fs/proc/vm
To satisfy mmap()'s page-size bounary requirement, round-up offset of
each vmcore objects in page-size boundary; each offset is connected to
user-space virtual address through mapping of mmap().
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 18 --
1 files chang
The previous patch changed offsets of each vmcore objects by round-up
operation. vmcore size must count the holes.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 72 ++
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index dd1d601..bc4848c 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -185,9
l the offset on page-size boundary.
Also, old kernel can treat the ELF segments created without null
header because it stops reading ELF segments if real size it reads
reachs p_memsz.
Signed-off-by: HATAYAMA Daisuke
---
arch/s390/include/asm/kexec.h |8 ---
include/linux/kexec.h |
roc/vmcore doesn't provide
mmap() interface.
Signed-off-by: HATAYAMA Daisuke
---
kernel/kexec.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index bddd3d7..d1f365e 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1234,7
If flag MEM_TYPE_CURRENT_KERNEL is set, the object is copied in the
buffer on the 2nd kernel, then read_vmcore() reads the buffer. If the
flag is not set, read_vmcore() reads old memory as usual.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 15 +++
1 files changed, 11
ew rounded-up value.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 17e2501..dd9769d 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -339,7 +339,7 @@
The variable j has int type but it's compared with u64 type.
Also, the purpose of the variable j is exactly what the variable
real_sz is used for now. Replace the variable j by the variable
real_sz and remove the variable j.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c |
uffer size separately. elfcorebuf_sz_orig keeps the original one
and elfcorebuf_sz the actually used one.
Reviewed-by: Zhang Yanfei
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 30 +-
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/fs
memsz position, failing to read a whole ELF segment.
Note: kexec-tools assigns PAGE_SIZE to p_memsz for other ELF note
types. Due to the above reason, the same issue occurs if actual ELF
note data exceeds (PAGE_SIZE - 2 * KEXEC_NOTE_HEAD_BYTES).
Signed-off-by: HATAYAMA Daisuke
---
kernel/ksysfs.c |
From: "Eric W. Biederman"
Subject: Re: [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to
get position of program header table
Date: Tue, 19 Mar 2013 14:44:16 -0700
> HATAYAMA Daisuke writes:
>
>> Currently, the code assumes that position of program header t
From: "Eric W. Biederman"
Subject: Re: [PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark indicating
the end of ELF note buffer
Date: Tue, 19 Mar 2013 14:11:51 -0700
> HATAYAMA Daisuke writes:
>
>> Modern kernel marks the end of ELF note buffer with NT_VMCORE_PAD ty
From: "Eric W. Biederman"
Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s
page-size boundary requirement
Date: Wed, 20 Mar 2013 13:55:55 -0700
> Vivek Goyal writes:
>
>> On Tue, Mar 19, 2013 at 03:38:45PM -0700, Eric W. Biederman
From: Andrew Morton
Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
Date: Tue, 19 Mar 2013 12:30:05 -0700
> On Sat, 16 Mar 2013 13:00:47 +0900 HATAYAMA Daisuke
> wrote:
>
>> Currently, read to /proc/vmcore is done by read_oldmem() that uses
>>
From: "Eric W. Biederman"
Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s
page-size boundary requirement
Date: Wed, 20 Mar 2013 21:18:37 -0700
> HATAYAMA Daisuke writes:
>
>> From: "Eric W. Biederman"
>> Subject: R
From: "Eric W. Biederman"
Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
Date: Wed, 20 Mar 2013 23:16:20 -0700
> HATAYAMA Daisuke writes:
>
>> From: Andrew Morton
>> Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc
From: "Eric W. Biederman"
Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s
page-size boundary requirement
Date: Wed, 20 Mar 2013 23:29:05 -0700
> HATAYAMA Daisuke writes:
>>
>> Do you mean for each range represented by each PT_LOA
pping them so
/proc/vmcore appears consequtive using existing remap_pfn_range() needs
some complicated work.
TODO
- fix makedumpfile to use mmap() on /dev/oldmem and benchmark it to
confirm whether we can see enough performance improvement.
Test
====
Tested an
ent end address now and
this should be done as an insurance when map passed from firmware is
inclusive, for which I'll post a patch later.
---
HATAYAMA Daisuke (4):
kdump, oldmem: compare with saved_max_pfn exclusively
kdump, s390: make saved_max_pfn exclusive
kdump,
Signed-off-by: HATAYAMA Daisuke
---
arch/s390/kernel/setup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index a5360de..3357566 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -729,9
very architectures; it's possible to make
saved_max_pfn exclusive now.
However, ppc and ppc64 on kexec doesn't increment end address now and
this should be done as an insurance when map passed from firmware is
inclusive, for which I'll post a patch later.
---
HATAYAMA Daisuke (4):
Signed-off-by: HATAYAMA Daisuke
---
arch/mips/kernel/crash_dump.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips/kernel/crash_dump.c b/arch/mips/kernel/crash_dump.c
index 35bed0d..6621211 100644
--- a/arch/mips/kernel/crash_dump.c
+++ b/arch/mips/kernel
Signed-off-by: HATAYAMA Daisuke
---
arch/powerpc/kernel/crash_dump.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index b3ba516..fa64170 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch
Signed-off-by: HATAYAMA Daisuke
---
arch/s390/kernel/setup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index a5360de..3357566 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -729,9
Signed-off-by: HATAYAMA Daisuke
---
drivers/char/mem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index c6fa3bc..5da737c 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -369,7 +369,7 @@ static ssize_t read_oldmem
From: Vivek Goyal
Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
Date: Tue, 5 Feb 2013 10:12:56 -0500
> On Mon, Feb 04, 2013 at 04:59:35AM +0000, Hatayama, Daisuke wrote:
> [..]
>> For design decision, I didn't support mmap() on /proc/vmcore because
>>
> From: Vivek Goyal [mailto:vgo...@redhat.com]
> Sent: Friday, February 08, 2013 12:06 AM
> On Wed, Feb 06, 2013 at 07:24:46AM +, Hatayama, Daisuke wrote:
> > From: Vivek Goyal
> > Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
> > Date: Tue
> From: kexec-boun...@lists.infradead.org
> Sent: Friday, February 08, 2013 9:26 AM
> > From: Vivek Goyal [mailto:vgo...@redhat.com]
> > Sent: Friday, February 08, 2013 12:06 AM
>
> > On Wed, Feb 06, 2013 at 07:24:46AM +, Hatayama, Daisuke wrote:
> > >
goto whole;
> if (!(vma->vm_flags & VM_SHARED) && FILTER(HUGETLB_PRIVATE))
> goto whole;
> + return 0;
> }
>
> /* Do not dump I/O mapped devices or special mappings */
>
Thanks for splitting th
s name suggests. It
seems to me enough to get the last occurence of "crashkernel=" and to leave the "" unknown for now.
The current code of yours checks if each "crashkernel="
detected by strstr() ends with each of ";high" or ";low", but doesn'
require some amount of
low memory, e.g. swiotlb that requires at least 72MB low memory at
default. Kernel would ...
> + 0: to disable low allocation on systems that do not
> + need swiotlb, that will save 72M low ram in first
> + kernel.
> +
radation in case of free list with large map size, to be
honest, I have yet to investigate why precisely now... I guess it's
caused by the fact that elements linked in free list is not sorted
increasing order with regard to pfn, so the degradation comes from
the many calls of mmap() wit
think.
Considering these, I'll make a patch to clear BSP flag at appropreate
position in kernel boot-up code. OTOH, according to the discussion, it
was reported that clearing BSP flag affected some BIOSes. To deal with
this, I'll prepare a kernel option to decide whethe
KERNEL_GS_BASE, true);
> @@ -7265,6 +7270,10 @@ static void __exit vmx_exit(void)
> free_page((unsigned long)vmx_io_bitmap_b);
> free_page((unsigned long)vmx_io_bitmap_a);
>
> +#ifdef CONFIG_KEXEC
> + crash_clear_loaded_vmcss = NULL;
> +#endif
> +
>
s, only assigning false for all the
entries, keeping interface uniform.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/include/asm/mpspec.h |2 +-
arch/x86/kernel/acpi/boot.c | 11 ++-
arch/x86/kernel/apic/apic.c | 18 +-
arch/x86/kernel/devicetree.c |1 +
arch/
system and for the latter I did
acpi=off. I crashed the system both on BSP and AP by taskset -c {0,1}
sh -c "echo c > /proc/sysrq-trigger".
---
HATAYAMA Daisuke (2):
x86, apic: Add boot_cpu_is_bsp() to check if boot cpu is BSP
x86, apic: Disable BSP if boot cpu is A
Kexec can enter the kdump 2nd kernel on AP if crash happens on AP. To
check if boot cpu is BSP, introduce a helper function
boot_cpu_is_bsp().
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/include/asm/mpspec.h |3 +++
arch/x86/kernel/apic/apic.c | 14 ++
arch/x86/kernel
, it's simpler to export
phys_base information
as its value, not the assigned address. Then, as a side-effect, we can check
phys_base value
using strings command to crash dump and this is a little handy.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(2013/10/02 9:38), HATAYAMA Daisuke wrote:
> (2013/10/02 4:37), Kees Cook wrote:
>> @@ -1242,3 +1256,15 @@ void __init i386_reserve_resources(void)
>>}
>>
>>#endif /* CONFIG_X86_32 */
>> +
>> +static struct notifier_block kernel_off
(2013/10/02 16:48), Kees Cook wrote:
On Tue, Oct 1, 2013 at 5:38 PM, HATAYAMA Daisuke
wrote:
(2013/10/02 4:37), Kees Cook wrote:
When the system panics, include the kernel offset in the report to assist
in debugging.
Signed-off-by: Kees Cook
---
arch/x86/kernel/setup.c | 26
(2013/10/02 18:13), HATAYAMA Daisuke wrote:
(2013/10/02 16:48), Kees Cook wrote:
+
+ return 0;
+}
+
+/*
* Determine if we were loaded by an EFI loader. If so, then we have also
been
* passed the efi memmap, systab, etc., so we should use these data
structures
* for
n_end: 88
Kernel can't mmap vmcore, using reads.
STEP [Excluding unnecessary pages] : 1.268799 seconds
STEP [Excluding unnecessary pages] : 1.268756 seconds
STEP [Copying data ] : 44.847924 seconds
Writing erase info...
I'll post a patch later.
--
Thanks.
HATAYAMA,
(2013/10/03 22:47), Dave Anderson wrote:
- Original Message -
(2013/10/02 18:13), HATAYAMA Daisuke wrote:
(2013/10/02 16:48), Kees Cook wrote:
+
+ return 0;
+}
+
+/*
* Determine if we were loaded by an EFI loader. If so, then we have also
been
* passed the efi
(2013/10/03 15:12), HATAYAMA Daisuke wrote:
(2013/10/02 21:03), Michael Holzheu wrote:
Hello Alexey,
Looks like the following commit broke mmap for /proc/vmcore:
commit c4fe24485729fc2cbff324c111e67a1cc2f9adea
Author: Alexey Dobriyan
Date: Tue Aug 20 22:17:24 2013 +0300
sparc: fix
(2013/07/08 18:28), Michael Holzheu wrote:
On Mon, 08 Jul 2013 14:32:09 +0900
HATAYAMA Daisuke wrote:
(2013/07/02 4:32), Michael Holzheu wrote:
For zfcpdump we can't map the HSA storage because it is only available
via a read interface. Therefore, for the new vmcore mmap feature we
(2013/07/08 23:28), Vivek Goyal wrote:
On Mon, Jul 08, 2013 at 11:28:39AM +0200, Michael Holzheu wrote:
On Mon, 08 Jul 2013 14:32:09 +0900
HATAYAMA Daisuke wrote:
(2013/07/02 4:32), Michael Holzheu wrote:
For zfcpdump we can't map the HSA storage because it is only available
via a
(2013/07/10 17:42), Michael Holzheu wrote:
Hello Hatayama,
On Tue, 09 Jul 2013 14:49:48 +0900
HATAYAMA Daisuke wrote:
(2013/07/08 23:28), Vivek Goyal wrote:
On Mon, Jul 08, 2013 at 11:28:39AM +0200, Michael Holzheu wrote:
On Mon, 08 Jul 2013 14:32:09 +0900
HATAYAMA Daisuke wrote:
[snip
(2013/07/10 23:33), Vivek Goyal wrote:
On Wed, Jul 10, 2013 at 06:50:18PM +0900, HATAYAMA Daisuke wrote:
[..]
If you want to avoid looking up vmcore_list that takes linear time w.r.t. the
number
of the elements, you can still calculate the range of offsets in /proc/vmcore
corresponding to HSA
(2013/07/10 20:00), Michael Holzheu wrote:
On Wed, 10 Jul 2013 18:50:18 +0900
HATAYAMA Daisuke wrote:
[snip]
(2013/07/10 17:42), Michael Holzheu wrote:
My suggestion is to add the WARN_ONCE() for #ifndef CONFIG_S390. This has the
same
effect as your suggestion for all architectures besides
(2013/09/04 15:12), Borislav Petkov wrote:
On Mon, Sep 02, 2013 at 06:42:44PM +0900, HATAYAMA Daisuke wrote:
The reason why I don't lookup BSP flag in MSR is that it's impossible.
To read MSR of some CPU, we need to use rdmsr instruction on the CPU.
However, in case of this issue,
(2013/10/07 22:21), Dave Anderson wrote:
- Original Message -
(2013/10/03 22:47), Dave Anderson wrote:
- Original Message -
(2013/10/02 18:13), HATAYAMA Daisuke wrote:
(2013/10/02 16:48), Kees Cook wrote:
Thanks for detailed explanation. So, there's already a fe
(2013/10/08 22:38), Dave Anderson wrote:
- Original Message -
(2013/10/07 22:21), Dave Anderson wrote:
- Original Message -
(2013/10/03 22:47), Dave Anderson wrote:
- Original Message -
(2013/10/02 18:13), HATAYAMA Daisuke wrote:
(2013/10/02 16:48), Kees Cook
Hello,
(2013/10/08 21:49), Alexey Dobriyan wrote:
On Mon, Oct 7, 2013 at 5:42 AM, HATAYAMA Daisuke
wrote:
+static unsigned long
+get_unmapped_area_vmcore(struct file *filp, unsigned long addr,
+unsigned long len, unsigned long pgoff,
+unsigned
(2013/08/29 22:54), H. Peter Anvin wrote:
On 08/29/2013 02:27 AM, HATAYAMA Daisuke wrote:
This is the patch series to address the issue that kdump 2nd kernel
now fails to wake up multiple CPUs.
Please explain the "now" in the above sentence. Is this a regression?
If so, what is
(2013/08/31 14:22), Borislav Petkov wrote:
On Thu, Aug 29, 2013 at 06:28:04PM +0900, HATAYAMA Daisuke wrote:
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 66cab35..fd969d1 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2113,13
(2013/09/02 16:13), Borislav Petkov wrote:
On Mon, Sep 02, 2013 at 11:32:59AM +0900, HATAYAMA Daisuke wrote:
As you suggest, boot_cpu seems more understandable also to me. BTW,
please notice that it doesn't denote that the CPU we're booting on
currently, but that the CPU with BS
From: Vivek Goyal
Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Thu, 18 Oct 2012 10:14:49 -0400
> On Thu, Oct 18, 2012 at 12:08:05PM +0900, HATAYAMA Daisuke wrote:
>
> [..]
>> > Do you have any rough numbers on what kind of speed up we are looking
From: Vivek Goyal
Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Fri, 19 Oct 2012 11:17:53 -0400
> On Fri, Oct 19, 2012 at 12:20:54PM +0900, HATAYAMA Daisuke wrote:
>
> [..]
>> > Instead of capturing the dump of whole memory, isn't it more ef
emap issue,
there is secondary one to consider in memory consumption on the 2nd kernel.
Also, I have one question. Can we always think of 1st and 2nd kernels are same?
If I understand correctly, kexec/kdump can use the 2nd kernel different
from the 1st's. So, differnet kernels need to do the sa
From: Cliff Wickman
Subject: Re: [PATCH] makedumpfile: request the kernel do page scans
Date: Mon, 10 Dec 2012 09:36:14 -0600
> On Mon, Dec 10, 2012 at 09:59:29AM +0900, HATAYAMA Daisuke wrote:
>> From: Cliff Wickman
>> Subject: Re: [PATCH] makedumpfile: request the kernel do pag
From: Cliff Wickman
Subject: Re: [PATCH] makedumpfile: request the kernel do page scans
Date: Thu, 20 Dec 2012 09:51:47 -0600
> On Thu, Dec 20, 2012 at 12:22:14PM +0900, HATAYAMA Daisuke wrote:
>> From: Cliff Wickman
>> Subject: Re: [PATCH] makedumpfile: request the kernel do pag
mary
code change.
- Put ELF note segments in page-size boundary on the 1st kernel
instead of copying them into the buffer on the 2nd kernel.
Test
This patch set is composed based on v3.9-rc7.
Done on x86-64, x86-32 both with 1GB and over 4GB memory environments.
---
HATAYAMA Daisuke (
headers as an inital offset value in
set_vmcore_list_offsets_elf{64,32} and
process_ptload_program_headers_elf{64,32} in order to indicate that
the offset includes the holes towards the page boudary.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 80
.
Signed-off-by: HATAYAMA Daisuke
---
include/linux/proc_fs.h |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 94dfb2a..fefead4 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -97,11 +97,17
Later patch will introduce a helper function, vmcore_add_per_unit, to
add memory chunks per a given size in vmcore_list. As a preparation
this patch introduces a helper function that adds a given memory chunk
in vmcore_list in a simple manner.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index e27da40..029bdc0 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -266,7 +266,7 @@ static u64 __init
/vmcore. The gaps generated by the
rearrangement are newly made visible to applications as
holes. Concretely, they are two ranges [rounddown(start, PAGE_SIZE),
start] and [end, roundup(end, PAGE_SIZE)].
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 26 --
1 files
mapping linear pages on non-consequtive
physical pages; see is_cow_mapping().
On x86-32 PAE kernels, mmap() supports at most 16TB memory only. This
limitation comes from the fact that the third argument of
remap_pfn_range(), pfn, is of 32-bit length on x86-32: unsigned long.
Signed-off-by: HATAYAMA
te that we cannot use remap_vmalloc_range here since the vma passed
to it as the first argument needs to cover a full range of memory. We
need to be able to specify where to map in pages, but we cannot do it
by remap_vmalloc_range.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcor
the 1st kernel (old memory) or the 2nd kernel. Then, this function
will be modified so as to decide where to read according to the flag
of a given vmcore object. This cleanup will also be useful to make the
change clearer.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 68
(2013/04/18 20:41), Petr Tesarik wrote:
On Mon, 16 Apr 2012 11:21:28 +0900
HATAYAMA Daisuke wrote:
Currently, booting up 2nd kernel with multiple CPUs fails in most
cases since it enters 2nd kernel with AP if the crash happens on the
AP. The problem is to signal startup IPI from AP to BSP
(2013/06/12 18:13), Michael Holzheu wrote:
On Tue, 11 Jun 2013 21:42:15 +0900
HATAYAMA Daisuke wrote:
2013/6/11 Michael Holzheu :
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke wrote:
2013/6/8 Michael Holzheu :
static int mmap_vmcore_fault(struct vm_area_struct *vma
(2013/06/12 18:13), Michael Holzheu wrote:
On Tue, 11 Jun 2013 21:42:15 +0900
HATAYAMA Daisuke wrote:
2013/6/11 Michael Holzheu :
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke wrote:
2013/6/8 Michael Holzheu :
Thanks for that hint! So together with your other comment regarding
(2013/06/07 6:31), Arnd Bergmann wrote:
On Thursday 23 May 2013 14:25:48 HATAYAMA Daisuke wrote:
This patch introduces mmap_vmcore().
Don't permit writable nor executable mapping even with mprotect()
because this mmap() is aimed at reading crash dump memory.
Non-writable mapping is
2013/6/8 Arnd Bergmann :
> On Friday 07 June 2013, HATAYAMA Daisuke wrote:
>> Thanks for trying the build and your report!
>>
>> OTOH, I don't have no-MMU architectures; x86 box only. I cannot reproduce
>> this build error.
>> Could you give me your build log
Hello,
This patch fixes the issue reported by Amd on an overlook of no-MMU
configuration.
This patch is made on top of v3.10-rc4-mmotm-2013-06-06-16-19.
I tested this on x86_64 and x86 with 1GB and 5GB memory.
I build this on arm without CONFIG_MMU configuration.
Thanks.
HATAYAMA, Daisuke
(!OLDMEM_BASE || is_kdump_kernel())
> - return -EINVAL;
> - s390_elf_corehdr_create(&elfcorebuf, &elfcorebuf_sz);
> - elfcorehdr_addr = (unsigned long long) elfcorebuf;
> - elfcorehdr_size = elfcorebuf_sz;
> - return 0;
> + if (!elfcoreh
0);
> + unlock_page(page);
> + rc = VM_FAULT_MAJOR;
> + }
> + vmf->page = page;
> + return rc;
> +}
How about reusing find_or_create_page()?
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubs
return rc;
> + }
Here you removed comment in the 1st path. Please keep it.
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.k
2013/6/11 Michael Holzheu :
> On Mon, 10 Jun 2013 22:40:24 +0900
> HATAYAMA Daisuke wrote:
>
>> 2013/6/8 Michael Holzheu :
>>
>> > @@ -225,6 +251,56 @@ static ssize_t read_vmcore(struct file *file, char
>> > __user *buffer,
>> > return ac
2013/6/11 Michael Holzheu :
> On Mon, 10 Jun 2013 22:40:24 +0900
> HATAYAMA Daisuke wrote:
>
>> 2013/6/8 Michael Holzheu :
>>
>> > @@ -225,6 +251,56 @@ static ssize_t read_vmcore(struct file *file, char
>> > __user *buffer,
>> > return ac
igned long size, pgprot_t prot)
+{
+ unsigned long size_hsa;
+
+ if (pfn < ZFCPDUMP_HSA_SIZE >> PAGE_SHIFT) {
+ size_hsa = min(size, OLDMEM_SIZE - (pfn << PAGE_SHIFT));
ZFCPDUMP_HSA_SIZE?
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send th
ze_t size = vma->vm_end - vma->vm_start;
@@ -242,6 +309,7 @@ static int mmap_vmcore(struct file *file, struct
vm_area_struct *vma)
vma->vm_flags &= ~(VM_MAYWRITE | VM_MAYEXEC);
vma->vm_flags |= VM_MIXEDMAP;
+ vma->vm_ops = &vmcore_mmap_ops;
len = 0;
confirmed the result.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Vivek Goyal
Subject: Re: [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to
get position of program header table
Date: Thu, 21 Mar 2013 10:12:02 -0400
> On Thu, Mar 21, 2013 at 11:50:41AM +0900, HATAYAMA Daisuke wrote:
>> From: "Eric W. Biederman"
>&g
/sys/devices/system/cpu/cpu/crash_notes_size
>
> and let kexec-tools parse it.
Anyway, I think of this issue as beyond the scope of what I'm working
here...
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
e prefetch performed by creation of page table to
the poisoned pages. Or MCE disables the prefetch? I'm not sure but
I'll investigate this. makedumpfile might also take care of calling
mmap.
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux
p sins elsewhere
> in the system.
>
> At the level of /proc/vmcore we may want to do something about ensuring
> MCE's don't kill us. But that is an orthogonal problem.
This is the part of old memory /proc/vmcore must read at its
initialization to generate its meta data, i.e.
From: Vivek Goyal
Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s
page-size boundary requirement
Date: Thu, 21 Mar 2013 10:49:29 -0400
> On Thu, Mar 21, 2013 at 12:22:59AM -0700, Eric W. Biederman wrote:
>> HATAYAMA Daisuke writes:
>>
>>
1 - 100 of 360 matches
Mail list logo
