(2013/08/07 1:25), Bjorn Helgaas wrote:
On Tue, Aug 6, 2013 at 3:19 AM, HATAYAMA Daisuke
d.hatay...@jp.fujitsu.com wrote:
So, could anyone help testing the idea 2) above if you have which of
the following machines? (or other ones that can lead to the same bug)
- HP Compaq 6910p
- HP Compaq
can see oops on the screen if bug has
successfully been reproduced.
--
Thanks.
HATAYAMA, Daisuke
bsp_flag_modules.tar.gz
Description: application/gzip
. Wait some minutes if necessary.
7. Open the lid and you can see oops on the screen if bug has
successfully been reproduced.
--
Thanks.
HATAYAMA, Daisuke
bsp_flag_modules.tar.gz
Description: application/gzip
(2013/07/16 9:27), HATAYAMA Daisuke wrote:
(2013/07/15 23:20), Vivek Goyal wrote:
On Fri, Jul 12, 2013 at 08:05:31PM +0900, HATAYAMA Daisuke wrote:
[..]
How about
static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
...
char *buf;
int rc
(2013/07/16 9:27), HATAYAMA Daisuke wrote:
(2013/07/15 23:20), Vivek Goyal wrote:
On Fri, Jul 12, 2013 at 08:05:31PM +0900, HATAYAMA Daisuke wrote:
[..]
How about
static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
...
char *buf;
int rc
(2013/07/15 18:21), Martin Schwidefsky wrote:
On Sat, 13 Jul 2013 01:02:50 +0900
HATAYAMA Daisuke wrote:
(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
(2013/07/15 23:20), Vivek Goyal wrote:
On Fri, Jul 12, 2013 at 08:05:31PM +0900, HATAYAMA Daisuke wrote:
[..]
How about
static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
...
char *buf;
int rc;
#ifndef CONFIG_S390
return
(2013/07/15 23:20), Vivek Goyal wrote:
On Fri, Jul 12, 2013 at 08:05:31PM +0900, HATAYAMA Daisuke wrote:
[..]
How about
static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
...
char *buf;
int rc;
#ifndef CONFIG_S390
return
(2013/07/15 18:21), Martin Schwidefsky wrote:
On Sat, 13 Jul 2013 01:02:50 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
(2013/07/10 20:00), Michael Holzheu wrote:
On Wed, 10 Jul 2013 18:50:18 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
[snip]
(2013/07/10 17:42
(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/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 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 d.hatay...@jp.fujitsu.com 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
(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 17:42), Michael Holzheu wrote:
Hello Hatayama,
On Tue, 09 Jul 2013 14:49:48 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com 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
(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 read
(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 have
(2013/07/08 18:28), Michael Holzheu wrote:
On Mon, 08 Jul 2013 14:32:09 +0900
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com 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
(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 d.hatay...@jp.fujitsu.com wrote:
(2013/07/02 4:32), Michael Holzheu wrote:
For zfcpdump we can't map the HSA storage because it is only
gt;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 = _mmap_ops;
len = 0;
--
Thanks.
HATAYAMA, Dais
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;
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line unsubscribe
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/
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/
(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/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 d.hatay...@gmail.com wrote:
2013/6/11 Michael Holzheu holz...@linux.vnet.ibm.com:
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke d.hatay...@gmail.com wrote:
2013/6/8 Michael Holzheu holz
(2013/06/12 18:13), Michael Holzheu wrote:
On Tue, 11 Jun 2013 21:42:15 +0900
HATAYAMA Daisuke d.hatay...@gmail.com wrote:
2013/6/11 Michael Holzheu holz...@linux.vnet.ibm.com:
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke d.hatay...@gmail.com wrote:
2013/6/8 Michael Holzheu holz
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
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
2013/6/11 Michael Holzheu holz...@linux.vnet.ibm.com:
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke d.hatay...@gmail.com wrote:
2013/6/8 Michael Holzheu holz...@linux.vnet.ibm.com:
cut
@@ -225,6 +251,56 @@ static ssize_t read_vmcore(struct file *file, char
__user *buffer
2013/6/11 Michael Holzheu holz...@linux.vnet.ibm.com:
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke d.hatay...@gmail.com wrote:
2013/6/8 Michael Holzheu holz...@linux.vnet.ibm.com:
cut
@@ -225,6 +251,56 @@ static ssize_t read_vmcore(struct file *file, char
__user *buffer
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 the line unsubscribe linux
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
> + 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 "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/
EM_BASE || is_kdump_kernel())
> - return -EINVAL;
> - s390_elf_corehdr_create(, _sz);
> - elfcorehdr_addr = (unsigned long long) elfcorebuf;
> - elfcorehdr_size = elfcorebuf_sz;
> - return 0;
> + if (!elfcorehdr_newmem)
> +
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
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
, elfcorebuf_sz);
- elfcorehdr_addr = (unsigned long long) elfcorebuf;
- elfcorehdr_size = elfcorebuf_sz;
- return 0;
+ if (!elfcorehdr_newmem)
+ return;
+ vfree(elfcorehdr_newmem);
kfree is correct here?
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from
()?
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/
;
+ }
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.kernel.org/majordomo-info.html
Please read the FAQ
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? I w
2013/6/8 Arnd Bergmann a...@arndb.de:
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? I want to use it to detect what
(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 also
(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 also
(2013/05/27 10:54), Zhang Yanfei wrote:
于 2013年05月27日 09:46, HATAYAMA Daisuke 写道:
(2013/05/26 15:36), Zhang Yanfei wrote:
From: Zhang Yanfei
Signed-off-by: Zhang Yanfei
Cc: Dave Jones
---
Documentation/devices.txt |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff
(2013/05/24 18:02), Maxim Uvarov wrote:
2013/5/24 Andrew Morton mailto:a...@linux-foundation.org>>
On Thu, 23 May 2013 14:25:48 +0900 HATAYAMA Daisuke mailto:d.hatay...@jp.fujitsu.com>> wrote:
> This patch introduces mmap_vmcore().
>
> Don't permit wr
memory interface completely in this patch set, so is it better
to add
unused, too?
--
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.
will just keep this and add a note to make people know that
it is removed in the next version.
It looks enough writing "obsolete" according to the other parts of the same
file.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
(2013/05/24 22:12), Vivek Goyal wrote:
On Thu, May 23, 2013 at 02:49:28PM -0700, Andrew Morton wrote:
On Thu, 23 May 2013 14:25:13 +0900 HATAYAMA Daisuke
wrote:
Treat memory chunks referenced by PT_LOAD program header entries in
page-size boundary in vmcore_list. Formally, for each range
(2013/05/24 22:12), Vivek Goyal wrote:
On Thu, May 23, 2013 at 02:49:28PM -0700, Andrew Morton wrote:
On Thu, 23 May 2013 14:25:13 +0900 HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
wrote:
Treat memory chunks referenced by PT_LOAD program header entries in
page-size boundary in vmcore_list
when
upgrading/downgrading kernels?
Ah, yes. I will just keep this and add a note to make people know that
it is removed in the next version.
It looks enough writing obsolete according to the other parts of the same
file.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send
as possible and unused means this is not used at all now.
You remove old memory interface completely in this patch set, so is it better
to add
unused, too?
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
(2013/05/24 18:02), Maxim Uvarov wrote:
2013/5/24 Andrew Morton a...@linux-foundation.org
mailto:a...@linux-foundation.org
On Thu, 23 May 2013 14:25:48 +0900 HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
mailto:d.hatay...@jp.fujitsu.com wrote:
This patch introduces mmap_vmcore
(2013/05/27 10:54), Zhang Yanfei wrote:
于 2013年05月27日 09:46, HATAYAMA Daisuke 写道:
(2013/05/26 15:36), Zhang Yanfei wrote:
From: Zhang Yanfei zhangyan...@cn.fujitsu.com
Signed-off-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Dave Jones da...@redhat.com
---
Documentation/devices.txt
as set_vmcore_list_offsets.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 94 --
1 files changed, 42 insertions(+), 52 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index ab0c92e..80fea97 100644
--- a/fs/proc/vmcore.c
+++ b
segment.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 355 --
1 files changed, 288 insertions(+), 67 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 686068d..937709d 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc
Now ELF note segment has been copied in the buffer on vmalloc
memory. To allow user process to remap the ELF note segment buffer
with remap_vmalloc_page, the corresponding VM area object has to have
VM_USERMAP flag set.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 14
t;size are always page-size aligned.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 30 ++
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 80fea97..686068d 100644
--- a/fs/proc/vmco
remap_vmalloc_range_partial that receives
user-space range as a pair of base address and size and can be used
for mmap on /proc/vmcore case.
remap_vmalloc_range is rewritten using remap_vmalloc_range_partial.
Signed-off-by: HATAYAMA Daisuke
---
include/linux/vmalloc.h |4 +++
mm/vmalloc.c| 63
.
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 Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 86
32} so that it calculates size
in the way of 2).
As a result, both get_vmcore_size_elf{64, 32} have the same
definition. Merge them as get_vmcore_size.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 44 +++-
1 files changed, 11 insertions(+), 33 del
Rewrite part of read_vmcore() that reads objects in vmcore_list in the
same way as part reading ELF headers, by which some duplicated and
redundant codes are removed.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 68
position of kernel VM area as target
address.
This patch changes the condition (addr > va->va_start) to the
equivalent (addr >= va->va_end) by taking advantage of the fact that
each kernel VM area is non-overlapping.
Signed-off-by: HATAYAMA Daisuke
Acked-by: KOSAKI Motohiro
---
sted on x86_64,
x86_32 both with 1GB and with 5GB (over 4GB) memory configurations.
---
HATAYAMA Daisuke (9):
vmcore: support mmap() on /proc/vmcore
vmcore: calculate vmcore file size from buffer size and total size of
vmcore objects
vmcore: Allow user process to remap ELF note s
(over 4GB) memory configurations.
---
HATAYAMA Daisuke (9):
vmcore: support mmap() on /proc/vmcore
vmcore: calculate vmcore file size from buffer size and total size of
vmcore objects
vmcore: Allow user process to remap ELF note segment buffer
vmcore: allocate ELF note
Rewrite part of read_vmcore() that reads objects in vmcore_list in the
same way as part reading ELF headers, by which some duplicated and
redundant codes are removed.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
---
fs/proc/vmcore.c | 68
position of kernel VM area as target
address.
This patch changes the condition (addr va-va_start) to the
equivalent (addr = va-va_end) by taking advantage of the fact that
each kernel VM area is non-overlapping.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: KOSAKI Motohiro
that it calculates size
in the way of 2).
As a result, both get_vmcore_size_elf{64, 32} have the same
definition. Merge them as get_vmcore_size.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
fs/proc/vmcore.c | 44 +++-
1 files changed, 11 insertions
.
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 Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
---
fs/proc/vmcore.c | 30 ++
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 80fea97..686068d 100644
--- a/fs/proc
remap_vmalloc_range_partial that receives
user-space range as a pair of base address and size and can be used
for mmap on /proc/vmcore case.
remap_vmalloc_range is rewritten using remap_vmalloc_range_partial.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
include/linux/vmalloc.h |4 +++
mm
Now ELF note segment has been copied in the buffer on vmalloc
memory. To allow user process to remap the ELF note segment buffer
with remap_vmalloc_page, the corresponding VM area object has to have
VM_USERMAP flag set.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
fs/proc
segment.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
fs/proc/vmcore.c | 355 --
1 files changed, 288 insertions(+), 67 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 686068d..937709d 100644
--- a/fs/proc
as set_vmcore_list_offsets.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
fs/proc/vmcore.c | 94 --
1 files changed, 42 insertions(+), 52 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index ab0c92e..80fea97 100644
Rewrite part of read_vmcore() that reads objects in vmcore_list in the
same way as part reading ELF headers, by which some duplicated and
redundant codes are removed.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 68
32} so that it calculates size
in the way of 2).
Signed-off-by: HATAYAMA Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 40 ++--
1 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index ca55343..9f3e256 100644
--
.
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 Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 86
headers as an initial 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 boundary.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 74
position of kernel VM area as target
address.
This patch changes the condition (addr > va->va_start) to the
equivalent (addr >= va->va_end) by taking advantage of the fact that
each kernel VM area is non-overlapping.
Signed-off-by: HATAYAMA Daisuke
Acked-by: KOSAKI Motohiro
---
remap_vmalloc_range_partial that receives
user-space range as a pair of base address and size and can be used
for mmap on /proc/vmcore case.
remap_vmalloc_range is rewritten using remap_vmalloc_range_partial.
Signed-off-by: HATAYAMA Daisuke
---
include/linux/vmalloc.h |4 +++
mm/vmalloc.c| 63
segment.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 335 --
1 files changed, 275 insertions(+), 60 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index d33b04d..ca55343 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc
t;size are always page-size aligned.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Vivek Goyal
---
fs/proc/vmcore.c | 30 ++
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 0651d98..d33b04d 100644
--- a/fs/proc/vmco
e-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.10-rc2, tested on x86_64,
x86_32 both with 1GB and with 5GB (over 4GB) memory configurations.
---
HATAYAMA Daisuke (8):
vmcore: support mmap() on /pr
of copying them into the buffer on the 2nd kernel.
Test
This patch set is composed based on v3.10-rc2, tested on x86_64,
x86_32 both with 1GB and with 5GB (over 4GB) memory configurations.
---
HATAYAMA Daisuke (8):
vmcore: support mmap() on /proc/vmcore
vmcore: calculate vmcore file
.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
---
fs/proc/vmcore.c | 30 ++
1 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 0651d98..d33b04d 100644
--- a/fs/proc
remap_vmalloc_range_partial that receives
user-space range as a pair of base address and size and can be used
for mmap on /proc/vmcore case.
remap_vmalloc_range is rewritten using remap_vmalloc_range_partial.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
include/linux/vmalloc.h |4 +++
mm
segment.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
fs/proc/vmcore.c | 335 --
1 files changed, 275 insertions(+), 60 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index d33b04d..ca55343 100644
--- a/fs/proc
headers as an initial 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 boundary.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
fs/proc/vmcore.c | 74
position of kernel VM area as target
address.
This patch changes the condition (addr va-va_start) to the
equivalent (addr = va-va_end) by taking advantage of the fact that
each kernel VM area is non-overlapping.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: KOSAKI Motohiro
.
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 Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
that it calculates size
in the way of 2).
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
---
fs/proc/vmcore.c | 40 ++--
1 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc
Rewrite part of read_vmcore() that reads objects in vmcore_list in the
same way as part reading ELF headers, by which some duplicated and
redundant codes are removed.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Vivek Goyal vgo...@redhat.com
---
fs/proc/vmcore.c | 68
(2013/05/17 9:06), H. Peter Anvin wrote:
On 05/15/2013 02:05 AM, HATAYAMA Daisuke wrote:
Currently, read to /proc/vmcore is done by read_oldmem() that uses
ioremap/iounmap per a single page. For example, if memory is 1GB,
ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
times
(2013/05/17 1:51), Vivek Goyal wrote:
On Wed, May 15, 2013 at 06:05:51PM +0900, HATAYAMA Daisuke wrote:
[..]
@@ -398,9 +403,7 @@ static int __init process_ptload_program_headers_elf64(char
*elfptr,
phdr_ptr = (Elf64_Phdr*)(elfptr + sizeof(Elf64_Ehdr)); /* PT_NOTE hdr
(2013/05/17 5:32), Vivek Goyal wrote:
On Wed, May 15, 2013 at 06:06:14PM +0900, HATAYAMA Daisuke wrote:
[..]
+static int __init get_note_number_and_size_elf32(const Elf32_Ehdr *ehdr_ptr,
+int *nr_ptnote, u64 *phdr_sz)
+{
+ return
(2013/05/16 6:37), KOSAKI Motohiro wrote:
On Wed, May 15, 2013 at 5:06 AM, HATAYAMA Daisuke
wrote:
Currently, __find_vmap_area searches for the kernel VM area starting
at a given address. This patch changes this behavior so that it
searches for the kernel VM area to which the address belongs
(2013/05/16 6:37), KOSAKI Motohiro wrote:
On Wed, May 15, 2013 at 5:06 AM, HATAYAMA Daisuke
d.hatay...@jp.fujitsu.com wrote:
Currently, __find_vmap_area searches for the kernel VM area starting
at a given address. This patch changes this behavior so that it
searches for the kernel VM area
(2013/05/17 5:32), Vivek Goyal wrote:
On Wed, May 15, 2013 at 06:06:14PM +0900, HATAYAMA Daisuke wrote:
[..]
+static int __init get_note_number_and_size_elf32(const Elf32_Ehdr *ehdr_ptr,
+int *nr_ptnote, u64 *phdr_sz)
+{
+ return
(2013/05/17 1:51), Vivek Goyal wrote:
On Wed, May 15, 2013 at 06:05:51PM +0900, HATAYAMA Daisuke wrote:
[..]
@@ -398,9 +403,7 @@ static int __init process_ptload_program_headers_elf64(char
*elfptr,
phdr_ptr = (Elf64_Phdr*)(elfptr + sizeof(Elf64_Ehdr)); /* PT_NOTE hdr
301 - 400 of 718 matches
Mail list logo
