Hi,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Lianbo Jiang
> Sent: Monday, January 7, 2019 10:48 AM
> To: linux-kernel@vger.kernel.org
> Cc: ke...@lists.infradead.org; t...@linutronix.de; mi...@redhat.com;
>
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Tuesday, June 5, 2018 11:03 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebi
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Tuesday, June 5, 2018 11:03 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebi
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 11:45 PM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebi
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 11:45 PM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.kernel.org;
> 'ebi
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of 't...@kernel.org'
> Sent: Saturday, June 2, 2018 2:07 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ; Okajima,
> Toshiyuki ;
> linux-kernel@vger.kernel.org; 'ebied.
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of 't...@kernel.org'
> Sent: Saturday, June 2, 2018 2:07 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ; Okajima,
> Toshiyuki ;
> linux-kernel@vger.kernel.org; 'ebied.
Hello,
Thanks for this patch, Eric.
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 3:51 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-k
Hello,
Thanks for this patch, Eric.
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 3:51 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-k
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of 't...@kernel.org'
> Sent: Wednesday, May 30, 2018 1:26 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ; Okajima,
> Toshiyuki ;
> linux-kernel@vger.kernel.org; 'ebied.
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of 't...@kernel.org'
> Sent: Wednesday, May 30, 2018 1:26 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ; Okajima,
> Toshiyuki ;
> linux-kernel@vger.kernel.org; 'ebied.
/kernfs/dirs.c,
contained in repro.tar.gz like:
# ./kernfshash
AtvbAC0jwH U1cN9ZbARQ 6b2609c5
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hatayama, Daisuke
> Sent: Monday, May 28, 2018 9:54 P
/kernfs/dirs.c,
contained in repro.tar.gz like:
# ./kernfshash
AtvbAC0jwH U1cN9ZbARQ 6b2609c5
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hatayama, Daisuke
> Sent: Monday, May 28, 2018 9:54 P
the case where nodes with the same hash but with the name
larger than the original node could still be skipped. Use
kernfs_sd_compare() to compare kernfs_node objects. Imporove patch
description.
Signed-off-by: HATAYAMA Daisuke <d.hatay...@jp.fujitsu.com>
Suggested-by: Toshiyuki O
the case where nodes with the same hash but with the name
larger than the original node could still be skipped. Use
kernfs_sd_compare() to compare kernfs_node objects. Imporove patch
description.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
---
fs
the case where nodes with the same hash but with the name
larger than the original node could still be skipped. Use
kernfs_sd_compare() to compare kernfs_node objects. Imporove patch
description.
Signed-off-by: HATAYAMA Daisuke <d.hatay...@jp.fujitsu.com>
Suggested-by: Toshiyuki O
the case where nodes with the same hash but with the name
larger than the original node could still be skipped. Use
kernfs_sd_compare() to compare kernfs_node objects. Imporove patch
description.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
---
fs
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hatayama, Daisuke
> Sent: Saturday, May 19, 2018 12:43 AM
> To: 'gre...@linuxfoundation.org' <gre...@linuxfoundation.org>
> Cc: Okajima, Tos
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hatayama, Daisuke
> Sent: Saturday, May 19, 2018 12:43 AM
> To: 'gre...@linuxfoundation.org'
> Cc: Okajima, Toshiyuki/岡嶋 寿行 ;
> linux-kernel@vg
by kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke <d.hatay...@jp.fujitsu.com>
Suggested-by: Tos
by kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
by kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke <d.hatay...@jp.fujitsu.com>
Suggested-by: Tos
by kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
Marc-Andre,
It looks to me that the 4th and 5th patches somehow has not been sent.
Could you send them, too?
I'd like them to actually build and run the kernel for testing.
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On
Marc-Andre,
It looks to me that the 4th and 5th patches somehow has not been sent.
Could you send them, too?
I'd like them to actually build and run the kernel for testing.
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Michael S. Tsirkin
> Sent: Tuesday, October 31, 2017 1:19 AM
> To: Hatayama, Daisuke <d.hatay...@jp.fujitsu.com>
> Cc: 'marcandre.lur...@re
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Michael S. Tsirkin
> Sent: Tuesday, October 31, 2017 1:19 AM
> To: Hatayama, Daisuke
> Cc: 'marcandre.lur...@redhat.com' ;
> 'so...@cm
ct bin_attribute fw_cfg_sysfs_attr_raw = {
> - .attr = { .name = "raw", .mode = S_IRUSR },
> + .attr = { .name = "raw", .mode = S_IRUSR | S_IWUSR },
> .read = fw_cfg_sysfs_read_raw,
> + .write = fw_cfg_sysfs_write_raw,
> };
>
> /*
> --
> 2.14.1.146.gd35faa819
Thanks.
HATAYAMA, Daisuke
= "raw", .mode = S_IRUSR },
> + .attr = { .name = "raw", .mode = S_IRUSR | S_IWUSR },
> .read = fw_cfg_sysfs_read_raw,
> + .write = fw_cfg_sysfs_write_raw,
> };
>
> /*
> --
> 2.14.1.146.gd35faa819
Thanks.
HATAYAMA, Daisuke
From: Baoquan He <b...@redhat.com>
Subject: Re: [PATCH V2] proc-vmcore: wrong data type casting fix
Date: Mon, 14 Mar 2016 11:50:53 +0800
> On 03/14/16 at 11:47am, Baoquan He wrote:
>> On 03/14/16 at 12:25pm, HATAYAMA Daisuke wrote:
>> > From: Dave Young <dyo...@redha
From: Baoquan He
Subject: Re: [PATCH V2] proc-vmcore: wrong data type casting fix
Date: Mon, 14 Mar 2016 11:50:53 +0800
> On 03/14/16 at 11:47am, Baoquan He wrote:
>> On 03/14/16 at 12:25pm, HATAYAMA Daisuke wrote:
>> > From: Dave Young
>> > Subject: [PATCH V2] p
t; - tsz = min_t(size_t, m->offset + m->size - start, size);
> + tsz = (size_t)min_t(unsigned long long,
> + m->offset + m->size - start, size);
> paddr = m->paddr + start - m->offset;
> if (vmcore_remap_oldmem_pfn(vma, vma->vm_start + len,
> paddr >> PAGE_SHIFT, tsz,
>
--
Thanks.
HATAYAMA, Daisuke
ize);
> + tsz = (size_t)min_t(unsigned long long,
> + m->offset + m->size - start, size);
> paddr = m->paddr + start - m->offset;
> if (vmcore_remap_oldmem_pfn(vma, vma->vm_start + len,
> paddr >> PAGE_SHIFT, tsz,
>
--
Thanks.
HATAYAMA, Daisuke
This patch set fixes a bug introduced in the commit
f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45.
For the v2 discussion, please follow the following thread:
http://thread.gmane.org/gmane.linux.kernel/1902488
The v3 patch newly adds a patch suggested by Ingo Molnar.
---
HATAYAMA Daisuke (2
this patch.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Baoquan He
Tested-by: Hidehiro Kawai
Reviewed-by: Masami Hiramatsu
---
include/linux/kernel.h |3 +++
kernel/kexec.c | 11 +++
kernel/panic.c |2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff -
no functionality change,
but the point is to make it explicit, from the caller panic() side,
that the 2nd crash_kexec() does nothing.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Ingo Molnar
---
kernel/panic.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel
no functionality change,
but the point is to make it explicit, from the caller panic() side,
that the 2nd crash_kexec() does nothing.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Suggested-by: Ingo Molnar mi...@kernel.org
---
kernel/panic.c |3 ++-
1 file changed, 2 insertions
-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Baoquan He b...@redhat.com
Tested-by: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
include/linux/kernel.h |3 +++
kernel/kexec.c | 11 +++
kernel/panic.c
This patch set fixes a bug introduced in the commit
f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45.
For the v2 discussion, please follow the following thread:
http://thread.gmane.org/gmane.linux.kernel/1902488
The v3 patch newly adds a patch suggested by Ingo Molnar.
---
HATAYAMA Daisuke (2
this patch.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Baoquan He
Tested-by: Hidehiro Kawai
Reviewed-by: Masami Hiramatsu
---
include/linux/kernel.h | 3 +++
kernel/kexec.c | 11 +++
kernel/panic.c | 2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff -
-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Baoquan He b...@redhat.com
Tested-by: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Reviewed-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
include/linux/kernel.h | 3 +++
kernel/kexec.c | 11 +++
kernel/panic.c
From: Vivek Goyal
Subject: Re: [RESEND PATCH] kernel/panic/kexec: fix
"crash_kexec_post_notifiers" option issue in oops path
Date: Thu, 5 Mar 2015 17:22:04 -0500
> On Thu, Mar 05, 2015 at 05:19:30PM -0500, Vivek Goyal wrote:
>> On Wed, Mar 04, 2015 at 05:56:48PM +0900, HAT
option. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
crash_kexec_post_notifiers in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked
oot
option. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
"crash_kexec_post_notifiers" in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke
Acked-by: Baoquan He
Tested-by: Hidehiro
. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
crash_kexec_post_notifiers in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: Baoquan He b...@redhat.com
Tested
Hello Eric, Vivek,
Do you have any comment to this patch?
On 2015/02/05 17:59, HATAYAMA Daisuke wrote:
The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
"crash_kexec_post_notifiers" kernel boot option, which toggles
wheather panic() calls crash_kexec() befor
Hello Eric, Vivek,
Do you have any comment to this patch?
On 2015/02/05 17:59, HATAYAMA Daisuke wrote:
The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
crash_kexec_post_notifiers kernel boot option, which toggles
wheather panic() calls crash_kexec() before or after
Hello,
From: Baoquan He
Subject: Re: [PATCH] kernel/panic/kexec: fix "crash_kexec_post_notifiers"
option issue in oops path
Date: Mon, 9 Feb 2015 10:40:30 +0800
> On 02/05/15 at 05:59pm, HATAYAMA Daisuke wrote:
>> The commit f06e5153f4ae2e2f3b0300f0e260e40c
Hello,
From: Baoquan He b...@redhat.com
Subject: Re: [PATCH] kernel/panic/kexec: fix crash_kexec_post_notifiers
option issue in oops path
Date: Mon, 9 Feb 2015 10:40:30 +0800
On 02/05/15 at 05:59pm, HATAYAMA Daisuke wrote:
The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
oot
option. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
"crash_kexec_post_notifiers" in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke
---
include/linux/kernel.h | 3 +++
kernel
. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
crash_kexec_post_notifiers in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
include/linux/kernel.h | 3 +++
kernel
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Fri, 14 Nov 2014 13:36:10 +0100
> On Fri, 14 Nov 2014 18:54:23 +0900 (JST)
> HATAYAMA Daisuke wrote:
>
>> From: Petr Tesarik
>> Subject: Re: [PATCH] kdump, x86
From: Petr Tesarik ptesa...@suse.cz
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Fri, 14 Nov 2014 13:36:10 +0100
On Fri, 14 Nov 2014 18:54:23 +0900 (JST)
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
From: Petr Tesarik ptesa...@suse.cz
Subject
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Fri, 14 Nov 2014 09:31:45 +0100
> On Fri, 14 Nov 2014 10:42:35 +0900 (JST)
> HATAYAMA Daisuke wrote:
>
>> From: Petr Tesarik
>> Subject: Re: [PATCH] kdump, x86
From: Petr Tesarik ptesa...@suse.cz
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Fri, 14 Nov 2014 09:31:45 +0100
On Fri, 14 Nov 2014 10:42:35 +0900 (JST)
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
From: Petr Tesarik ptesa...@suse.cz
Subject
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Thu, 13 Nov 2014 15:48:10 +0100
> On Thu, 13 Nov 2014 09:25:48 -0500
> Vivek Goyal wrote:
>
>> On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
>> &
From: Vivek Goyal
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Thu, 13 Nov 2014 09:25:48 -0500
> On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
>>
>>
>> (2014/11/13 17:06), Petr Tesarik wrote:
>> >On T
(2014/11/13 17:06), Petr Tesarik wrote:
On Thu, 13 Nov 2014 09:17:09 +0900 (JST)
HATAYAMA Daisuke wrote:
From: Vivek Goyal
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 17:12:05 -0500
On Wed, Nov 12, 2014 at 03:40:42PM +0900
(2014/11/13 17:06), Petr Tesarik wrote:
On Thu, 13 Nov 2014 09:17:09 +0900 (JST)
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
From: Vivek Goyal vgo...@redhat.com
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 17:12:05 -0500
From: Vivek Goyal vgo...@redhat.com
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Thu, 13 Nov 2014 09:25:48 -0500
On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
(2014/11/13 17:06), Petr Tesarik wrote:
On Thu, 13 Nov 2014 09:17:09
From: Petr Tesarik ptesa...@suse.cz
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Thu, 13 Nov 2014 15:48:10 +0100
On Thu, 13 Nov 2014 09:25:48 -0500
Vivek Goyal vgo...@redhat.com wrote:
On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote
ile refers to it and if removing it, old versions
makedumpfile doesn't work well.
ChangeLog:
v2:
- Introduce VMCOREINFO_PHYS_BASE().
- Correct patch description: this work is primarily for mechanisms
running outside (kdump 1st) Linux kernel.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/machine_
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 09:14:34 +0100
> On Wed, 12 Nov 2014 15:40:42 +0900 (JST)
> HATAYAMA Daisuke wrote:
>
>> Currently, VMCOREINFO note information reports the virtual address
From: Vivek Goyal
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 17:12:05 -0500
> On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote:
>> Currently, VMCOREINFO note information reports the virtual address of
>
From: Vivek Goyal vgo...@redhat.com
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 17:12:05 -0500
On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote:
Currently, VMCOREINFO note information reports the virtual address
From: Petr Tesarik ptesa...@suse.cz
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 09:14:34 +0100
On Wed, 12 Nov 2014 15:40:42 +0900 (JST)
HATAYAMA Daisuke d.hatay...@jp.fujitsu.com wrote:
Currently, VMCOREINFO note information reports
to it and if removing it, old versions
makedumpfile doesn't work well.
ChangeLog:
v2:
- Introduce VMCOREINFO_PHYS_BASE().
- Correct patch description: this work is primarily for mechanisms
running outside (kdump 1st) Linux kernel.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
arch/x86
in vmcore using the above-mentioned external crash
dump mechanism; kdump 2nd kernel is an inherently relocated kernel.
This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because
makedumpfile refers to it and if removing it, old versions
makedumpfile doesn't work well.
Signed-off-by: HATAYA
the above-mentioned external crash
dump mechanism; kdump 2nd kernel is an inherently relocated kernel.
This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because
makedumpfile refers to it and if removing it, old versions
makedumpfile doesn't work well.
Signed-off-by: HATAYAMA Daisuke
vma, vma->vm_start + len,
> - paddr >> PAGE_SHIFT, tsz,
> -vma->vm_page_prot))
> + if (vmcore_remap_oldmem_pfn(vma, vma->vm_start + len,
> +
, tsz,
+ vma-vm_page_prot))
goto fail;
size -= tsz;
start += tsz;
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
- start, size);
> paddr = m->paddr + start - m->offset;
> - if (remap_oldmem_pfn_range(vma, vma->vm_start + len,
> -paddr >> PAGE_SHIFT, tsz,
> -
;
size -= tsz;
start += tsz;
It looks to me good other than the above two comments.
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
Commit-ID: b292d7a10487aee6e74b1c18b8d95b92f40d4a4f
Gitweb: http://git.kernel.org/tip/b292d7a10487aee6e74b1c18b8d95b92f40d4a4f
Author: HATAYAMA Daisuke
AuthorDate: Wed, 25 Jun 2014 10:09:07 +0900
Committer: Ingo Molnar
CommitDate: Wed, 2 Jul 2014 08:35:55 +0200
perf/x86/intel: ignore
Commit-ID: b292d7a10487aee6e74b1c18b8d95b92f40d4a4f
Gitweb: http://git.kernel.org/tip/b292d7a10487aee6e74b1c18b8d95b92f40d4a4f
Author: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
AuthorDate: Wed, 25 Jun 2014 10:09:07 +0900
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 2 Jul
d stop using the PMU, but if some BIOS set it it would
> completely disable perf there. So better to just ignore it.
>
I'll reflect this information in the patch description.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
it it would
completely disable perf there. So better to just ignore it.
I'll reflect this information in the patch description.
--
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
Hello,
(2014/06/17 0:30), Don Zickus wrote:
On Fri, Jun 13, 2014 at 05:44:37PM +0900, HATAYAMA Daisuke wrote:
Currently, a NMI handler for NMI watchdog may falsely handle any NMI
signaled for different purpose if CondChgd bit in
MSR_CORE_PERF_GLOBAL_STATUS MSR is set.
This commit deals
Hello,
(2014/06/17 0:30), Don Zickus wrote:
On Fri, Jun 13, 2014 at 05:44:37PM +0900, HATAYAMA Daisuke wrote:
Currently, a NMI handler for NMI watchdog may falsely handle any NMI
signaled for different purpose if CondChgd bit in
MSR_CORE_PERF_GLOBAL_STATUS MSR is set.
This commit deals
patch description
From 63d6fa2a3dfa9ff7d1710c85d8d020cdc37f3b49 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Wed, 25 Jun 2014 10:09:07 +0900
Subject: [PATCH] perf/x86/intel: ignore CondChgd bit to avoid false NMI
handling
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Tr
description
From 63d6fa2a3dfa9ff7d1710c85d8d020cdc37f3b49 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Date: Wed, 25 Jun 2014 10:09:07 +0900
Subject: [PATCH] perf/x86/intel: ignore CondChgd bit to avoid false NMI
handling
MIME-Version: 1.0
Content-Type: text/plain; charset
tural MSRs
63 CondChg: status bits of this register has changed.
These are different from the bahviour I see on the actual system as I
explained above.
At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/
63 CondChg: status bits of this register has changed.
These are different from the bahviour I see on the actual system as I
explained above.
At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
arch
better
> changelog.
>
I see.
I'll write that the problem is that any NMI could be robbed by NMI
watchdog explicitly. Now only patch title says this explicitly. This
is your first comment.
About CondChgd bit, I cannot write more than I see on actual
system. If it's necessary to describe m
From: Peter Zijlstra
Subject: Re: [PATCH] perf/x86/intel: ignore CondChgd bit to avoid false NMI
handling
Date: Wed, 11 Jun 2014 10:54:48 +0200
> On Wed, Jun 11, 2014 at 04:30:28PM +0900, HATAYAMA Daisuke wrote:
>> Currently, a NMI handler for NMI watchdog may falsely handle any NMI
&g
From: Peter Zijlstra pet...@infradead.org
Subject: Re: [PATCH] perf/x86/intel: ignore CondChgd bit to avoid false NMI
handling
Date: Wed, 11 Jun 2014 10:54:48 +0200
On Wed, Jun 11, 2014 at 04:30:28PM +0900, HATAYAMA Daisuke wrote:
Currently, a NMI handler for NMI watchdog may falsely handle
write more than I see on actual
system. If it's necessary to describe more about CondChgd bit, it
would be appreciated if someone tell me more information about it.
Thanks.
HATAYAMA, Daisuke
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪj:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ
this bit is set. Although I read Intel System Programmer's Manual to
figure out but I have yet completed that. At least, I think ignoring
CondChgd bit should be enough for NMI watchdog perspective.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/cpu/perf_event_intel.c |9 +
1 file
this bit is set. Although I read Intel System Programmer's Manual to
figure out but I have yet completed that. At least, I think ignoring
CondChgd bit should be enough for NMI watchdog perspective.
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
arch/x86/kernel/cpu/perf_event_intel.c
(2014/01/26 13:02), David Rientjes wrote:
> On Thu, 16 Jan 2014, HATAYAMA Daisuke wrote:
>
>> Hello,
>>
>> This patch deals with the issue of handling boot_cpu_physical_apicid
>> in boot process I avoided in disable_cpu_apicid patch because I
>> ca
(2014/01/26 13:02), David Rientjes wrote:
On Thu, 16 Jan 2014, HATAYAMA Daisuke wrote:
Hello,
This patch deals with the issue of handling boot_cpu_physical_apicid
in boot process I avoided in disable_cpu_apicid patch because I
cannot guess how long it needs to take for the review
is 5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
I tested this patch in each combination of the following table:
BIOS tableboot cpu
-+--
ACPI MADT AP
MP Table BSP
>From 10946038252fc91f3ae2740953b2484ea0076ed4 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
D
is 5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
I tested this patch in each combination of the following table:
BIOS tableboot cpu
-+--
ACPI MADT AP
MP Table BSP
From 10946038252fc91f3ae2740953b2484ea0076ed4 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke d.hatay
(2014/01/16 14:53), H. Peter Anvin wrote:
On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:
This is not typo in my intention.
generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with "ACPI" because this
function is called wh
Cc: HATAYAMA Daisuke
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e78ab8c..7f26c9a 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -79,7 +79,7
Commit-ID: 151e0c7de616310f95393d9306903900fcd8b277
Gitweb: http://git.kernel.org/tip/151e0c7de616310f95393d9306903900fcd8b277
Author: HATAYAMA Daisuke
AuthorDate: Wed, 15 Jan 2014 15:44:58 +0900
Committer: H. Peter Anvin
CommitDate: Wed, 15 Jan 2014 09:19:20 -0800
x86, apic, kexec
Commit-ID: 151e0c7de616310f95393d9306903900fcd8b277
Gitweb: http://git.kernel.org/tip/151e0c7de616310f95393d9306903900fcd8b277
Author: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
AuthorDate: Wed, 15 Jan 2014 15:44:58 +0900
Committer: H. Peter Anvin h...@zytor.com
CommitDate: Wed, 15 Jan
...@gmail.com
Signed-off-by: H. Peter Anvin h...@linux.intel.com
Cc: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e78ab8c..7f26c9a
(2014/01/16 14:53), H. Peter Anvin wrote:
On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:
This is not typo in my intention.
generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with ACPI because this
function is called when parsing
, disabled_cpu_apicid kernel
parameter doesn't work well for apicids of APs.
Fixing the wrong handling of boot_cpu_physical_apicid requires some
reviews and tests beyond some platforms and it could take some
time. The fix here is a kind of workaround to focus on the main topic
of this patch.
Signed-off-by: HATAYAMA
1 - 100 of 718 matches
Mail list logo
