All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Simon Horman <horms@verge.net.au>
Cc: kexec@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephen Warren <swarren@nvidia.com>,
	linux-kernel@vger.kernel.org,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH] kexec: return error of machine_kexec() fails
Date: Wed, 10 Jul 2013 07:36:33 -0700	[thread overview]
Message-ID: <87obaaiiry.fsf@xmission.com> (raw)
In-Reply-To: <1373421296-6112-1-git-send-email-horms@verge.net.au> (Simon Horman's message of "Wed, 10 Jul 2013 10:54:56 +0900")

Simon Horman <horms@verge.net.au> writes:

> From: Stephen Warren <swarren@nvidia.com>
>
> Prior to commit 3ab8352 "kexec jump", if machine_kexec() returned,
> sys_reboot() would return -EINVAL. This patch restores this behaviour
> for the non-KEXEC_JUMP case, where machine_kexec() is not expected to
> return.
>
> This situation can occur on ARM, where kexec requires disabling all but
> one CPU using CPU hotplug. However, if hotplug isn't supported by the
> particular HW the kernel is running on, then kexec cannot succeed.

Ugh. This reasoning is nonsense.  Prior to the kexec jump work
machine_kexec could never return and so could never return -EINVAL.

It is not ok to have an image loaded that we can not kexec.  kexec_load
should fail not machine_shutdown or machine_kexec.

The only time that machine_kexec can validly return is in the kexec_jump
case, and that is a successful return.

So formally.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

My apologies for not speaking up sooner the broken ARM mutli-cpu
shutdown architecture hurts my brain to think about

ARM needs to get it's act together and stop modifying the generic code
to deal with it's broken multi-cpu architecture.

Eric

> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Acked-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> Acked-by: Simon Horman <horms@verge.net.au>
> ---
>  kernel/kexec.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> Andrew, could you consider picking up this patch?
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 59f7b55..bde1190 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1702,6 +1702,8 @@ int kernel_kexec(void)
>  		pm_restore_console();
>  		unlock_system_sleep();
>  	}
> +#else
> +	error = -EINVAL;
>  #endif
>  
>   Unlock:

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

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Simon Horman <horms@verge.net.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Stephen Warren <swarren@nvidia.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kexec: return error of machine_kexec() fails
Date: Wed, 10 Jul 2013 07:36:33 -0700	[thread overview]
Message-ID: <87obaaiiry.fsf@xmission.com> (raw)
In-Reply-To: <1373421296-6112-1-git-send-email-horms@verge.net.au> (Simon Horman's message of "Wed, 10 Jul 2013 10:54:56 +0900")

Simon Horman <horms@verge.net.au> writes:

> From: Stephen Warren <swarren@nvidia.com>
>
> Prior to commit 3ab8352 "kexec jump", if machine_kexec() returned,
> sys_reboot() would return -EINVAL. This patch restores this behaviour
> for the non-KEXEC_JUMP case, where machine_kexec() is not expected to
> return.
>
> This situation can occur on ARM, where kexec requires disabling all but
> one CPU using CPU hotplug. However, if hotplug isn't supported by the
> particular HW the kernel is running on, then kexec cannot succeed.

Ugh. This reasoning is nonsense.  Prior to the kexec jump work
machine_kexec could never return and so could never return -EINVAL.

It is not ok to have an image loaded that we can not kexec.  kexec_load
should fail not machine_shutdown or machine_kexec.

The only time that machine_kexec can validly return is in the kexec_jump
case, and that is a successful return.

So formally.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

My apologies for not speaking up sooner the broken ARM mutli-cpu
shutdown architecture hurts my brain to think about

ARM needs to get it's act together and stop modifying the generic code
to deal with it's broken multi-cpu architecture.

Eric

> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Acked-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
> Acked-by: Simon Horman <horms@verge.net.au>
> ---
>  kernel/kexec.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> Andrew, could you consider picking up this patch?
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 59f7b55..bde1190 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1702,6 +1702,8 @@ int kernel_kexec(void)
>  		pm_restore_console();
>  		unlock_system_sleep();
>  	}
> +#else
> +	error = -EINVAL;
>  #endif
>  
>   Unlock:

  reply	other threads:[~2013-07-10 14:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-10  1:54 [PATCH] kexec: return error of machine_kexec() fails Simon Horman
2013-07-10  1:54 ` Simon Horman
2013-07-10 14:36 ` Eric W. Biederman [this message]
2013-07-10 14:36   ` Eric W. Biederman
2013-07-10 19:09   ` Stephen Warren
2013-07-10 19:09     ` Stephen Warren
2013-07-10 19:09     ` Stephen Warren
2013-07-10 20:42     ` Eric W. Biederman
2013-07-10 20:42       ` Eric W. Biederman
2013-07-10 20:42       ` Eric W. Biederman
2013-07-10 23:51       ` Russell King - ARM Linux
2013-07-10 23:51         ` Russell King - ARM Linux
2013-07-10 23:51         ` Russell King - ARM Linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87obaaiiry.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.