Re: [PATCH V2 0/2] kexec-tools: arm64: Enable D-cache in purgatory

[Pratyush Anand]

Hi James and all,

Any review comment for patch 2/2?

If no, then I will address comment for 1/2 and will send v3.

~Pratyush

On Tuesday 10 January 2017 07:41 PM, James Morse wrote:

Hi Pratyush,

On 06/01/17 03:31, Pratyush Anand wrote:

Any feedback/review comment on it?


I started going through this last week, I hope to get back to it later this
week. (I also need to learn/remember how some of the kexec-tools stuff works).


Thanks,

James




___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v3] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

[Xunlei Pang]

On 02/23/2017 at 02:50 AM, Luck, Tony wrote:
> On Wed, Feb 22, 2017 at 12:11:14PM +0800, Xunlei Pang wrote:
>> +/*
>> + * Cases to bail out to avoid rendezvous process timeout:
>> + * 1)If this CPU is offline.
>> + * 2)If crashing_cpu was set, e.g. entering kdump,
>> + *   we need to skip cpus remaining in 1st kernel.
>> + */
>> +if (cpu_is_offline(cpu) ||
>> +(crashing_cpu != -1 && crashing_cpu != cpu)) {
>>  u64 mcgstatus;
>>  
>>  mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
>
> I think we should document the remaining race conditions. I don't
> think there is any good way to eliminate them, and they are already
> pretty small windows.
>
> I think the sequence of events looks like:
>
>  1Panic occurs
>  2nmi_shootdown_cpus() sets crashing_cpu
>  3send NMI to everyone else
>  4wait up to a second for other CPUs to take NMI
>  5go to kexec code
>  6start new kernel
>  7new kernel establishes #MC handler
>
> If one of the other cpus triggers a machine check while
> getting to, or in, the NMI handler ... then that cpu will
> skip processing (if RIPV is set).
>
> Between '2' and '5' if crashing_cpu gets a machine check it
> will execute in the old kernel handler, and do the right thing.
>
> There's a fuzzy area between '6' and '7' where a machine check
> might not end up in the right code.
>
> From '7' onwards the kexec kernel will handle and machine
> checks caused by kdump.
>

Agree, will update the comment.

Regards,
Xunlei

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] uapi: fix linux/kexec.h userspace compilation errors

[Eric W. Biederman]

"Dmitry V. Levin"  writes:

> Include  (guarded by #ifndef __KERNEL__) to fix the following
> linux/kexec.h userspace compilation errors:
>
> /usr/include/linux/kexec.h:53:2: error: unknown type name 'size_t'
>   size_t bufsz;
> /usr/include/linux/kexec.h:55:2: error: unknown type name 'size_t'
>   size_t memsz;

Were these failures generated with a static checker?

What changed that you are seeing new failures in old essentially static
headers?

Eric




> Signed-off-by: Dmitry V. Levin 
> ---
>  include/uapi/linux/kexec.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> index aae5ebf..7def5f5 100644
> --- a/include/uapi/linux/kexec.h
> +++ b/include/uapi/linux/kexec.h
> @@ -45,6 +45,9 @@
>  #define KEXEC_SEGMENT_MAX 16
>  
>  #ifndef __KERNEL__
> +
> +#include /* For size_t. */
> +
>  /*
>   * This structure is used to hold the arguments that are used when
>   * loading  kernel binaries.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] uapi: fix linux/kexec.h userspace compilation errors

[Dmitry V. Levin]

Include  (guarded by #ifndef __KERNEL__) to fix the following
linux/kexec.h userspace compilation errors:

/usr/include/linux/kexec.h:53:2: error: unknown type name 'size_t'
  size_t bufsz;
/usr/include/linux/kexec.h:55:2: error: unknown type name 'size_t'
  size_t memsz;

Signed-off-by: Dmitry V. Levin 
---
 include/uapi/linux/kexec.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
index aae5ebf..7def5f5 100644
--- a/include/uapi/linux/kexec.h
+++ b/include/uapi/linux/kexec.h
@@ -45,6 +45,9 @@
 #define KEXEC_SEGMENT_MAX 16
 
 #ifndef __KERNEL__
+
+#include /* For size_t. */
+
 /*
  * This structure is used to hold the arguments that are used when
  * loading  kernel binaries.
-- 
ldv

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v3] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

[Luck, Tony]

On Wed, Feb 22, 2017 at 12:11:14PM +0800, Xunlei Pang wrote:
> + /*
> +  * Cases to bail out to avoid rendezvous process timeout:
> +  * 1)If this CPU is offline.
> +  * 2)If crashing_cpu was set, e.g. entering kdump,
> +  *   we need to skip cpus remaining in 1st kernel.
> +  */
> + if (cpu_is_offline(cpu) ||
> + (crashing_cpu != -1 && crashing_cpu != cpu)) {
>   u64 mcgstatus;
>  
>   mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);


I think we should document the remaining race conditions. I don't
think there is any good way to eliminate them, and they are already
pretty small windows.

I think the sequence of events looks like:

 1  Panic occurs
 2  nmi_shootdown_cpus() sets crashing_cpu
 3  send NMI to everyone else
 4  wait up to a second for other CPUs to take NMI
 5  go to kexec code
 6  start new kernel
 7  new kernel establishes #MC handler

If one of the other cpus triggers a machine check while
getting to, or in, the NMI handler ... then that cpu will
skip processing (if RIPV is set).

Between '2' and '5' if crashing_cpu gets a machine check it
will execute in the old kernel handler, and do the right thing.

There's a fuzzy area between '6' and '7' where a machine check
might not end up in the right code.

>From '7' onwards the kexec kernel will handle and machine
checks caused by kdump.

-Tony

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec