All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: linux-s390@vger.kernel.org, kexec@lists.infradead.org,
	heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org,
	Minfei Huang <mnfhuang@gmail.com>,
	schwidefsky@de.ibm.com, linux390@de.ibm.com,
	ebiederm@xmission.com
Subject: Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start
Date: Tue, 14 Jul 2015 10:09:20 -0400	[thread overview]
Message-ID: <20150714140920.GA10792@redhat.com> (raw)
In-Reply-To: <20150710111406.279dba14@holzheu>

On Fri, Jul 10, 2015 at 11:14:06AM +0200, Michael Holzheu wrote:

[..]
> What about the following patch:
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 7a36fdc..7837c4e 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1236,10 +1236,68 @@ int kexec_load_disabled;
>  
>  static DEFINE_MUTEX(kexec_mutex);
>  
> +static int __kexec_load(unsigned long entry, unsigned long nr_segments,

How about renaming the function to do_kexec_load()?

We also need to cleanup the description of commit. One needs to explain
problem better and what's the solution this patch is implemeting.

> +			struct kexec_segment __user *segments,
> +			unsigned long flags)
> +{
> +	struct kimage **dest_image, *image;
> +	unsigned long i;
> +	int result;
> +
> +	if (flags & KEXEC_ON_CRASH)
> +		dest_image = &kexec_crash_image;
> +	else
> +		dest_image = &kexec_image;
> +
> +	if (nr_segments == 0) {
> +		/* Uninstall image */
> +		kfree(xchg(dest_image, NULL));

kimage_free(), as you have already noted in a follow up mail.

> +		return 0;
> +	}
> +	if (flags & KEXEC_ON_CRASH) {
> +		/*
> +		 * Loading another kernel to switch to if this one
> +		 * crashes.  Free any current crash dump kernel before
> +		 * we corrupt it.
> +		 */
> +		kimage_free(xchg(&kexec_crash_image, NULL));
> +	}
> +
> +	result = kimage_alloc_init(&image, entry, nr_segments, segments, flags);
> +	if (result)
> +		return result;
> +
> +	if (flags & KEXEC_ON_CRASH)
> +		crash_map_reserved_pages();
> +
> +	if (flags & KEXEC_PRESERVE_CONTEXT)
> +		image->preserve_context = 1;
> +
> +	result = machine_kexec_prepare(image);
> +	if (result)
> +		goto failure_unmap_mem;
> +
> +	for (i = 0; i < nr_segments; i++) {
> +		result = kimage_load_segment(image, &image->segment[i]);
> +		if (result)
> +			goto failure_unmap_mem;
> +	}
> +
> +	kimage_terminate(image);
> +
> +	/* Install the new kernel and uninstall the old */
> +	image = xchg(dest_image, image);
> +
> +failure_unmap_mem:

I don't like this tag "failure_unmap_mem". We are calling this both
in success path as well as failure path. So why not simply call it "out".

> +	if (flags & KEXEC_ON_CRASH)
> +		crash_unmap_reserved_pages();
> +	kimage_free(image);

Now kimage_free() is called with kexec_mutex held. Previously that was
not the case. I hope that's not a problem.

> +	return result;
> +}
> +

Thanks
Vivek

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Minfei Huang <mnfhuang@gmail.com>,
	ebiederm@xmission.com, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, linux390@de.ibm.com,
	linux-s390@vger.kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start
Date: Tue, 14 Jul 2015 10:09:20 -0400	[thread overview]
Message-ID: <20150714140920.GA10792@redhat.com> (raw)
In-Reply-To: <20150710111406.279dba14@holzheu>

On Fri, Jul 10, 2015 at 11:14:06AM +0200, Michael Holzheu wrote:

[..]
> What about the following patch:
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 7a36fdc..7837c4e 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1236,10 +1236,68 @@ int kexec_load_disabled;
>  
>  static DEFINE_MUTEX(kexec_mutex);
>  
> +static int __kexec_load(unsigned long entry, unsigned long nr_segments,

How about renaming the function to do_kexec_load()?

We also need to cleanup the description of commit. One needs to explain
problem better and what's the solution this patch is implemeting.

> +			struct kexec_segment __user *segments,
> +			unsigned long flags)
> +{
> +	struct kimage **dest_image, *image;
> +	unsigned long i;
> +	int result;
> +
> +	if (flags & KEXEC_ON_CRASH)
> +		dest_image = &kexec_crash_image;
> +	else
> +		dest_image = &kexec_image;
> +
> +	if (nr_segments == 0) {
> +		/* Uninstall image */
> +		kfree(xchg(dest_image, NULL));

kimage_free(), as you have already noted in a follow up mail.

> +		return 0;
> +	}
> +	if (flags & KEXEC_ON_CRASH) {
> +		/*
> +		 * Loading another kernel to switch to if this one
> +		 * crashes.  Free any current crash dump kernel before
> +		 * we corrupt it.
> +		 */
> +		kimage_free(xchg(&kexec_crash_image, NULL));
> +	}
> +
> +	result = kimage_alloc_init(&image, entry, nr_segments, segments, flags);
> +	if (result)
> +		return result;
> +
> +	if (flags & KEXEC_ON_CRASH)
> +		crash_map_reserved_pages();
> +
> +	if (flags & KEXEC_PRESERVE_CONTEXT)
> +		image->preserve_context = 1;
> +
> +	result = machine_kexec_prepare(image);
> +	if (result)
> +		goto failure_unmap_mem;
> +
> +	for (i = 0; i < nr_segments; i++) {
> +		result = kimage_load_segment(image, &image->segment[i]);
> +		if (result)
> +			goto failure_unmap_mem;
> +	}
> +
> +	kimage_terminate(image);
> +
> +	/* Install the new kernel and uninstall the old */
> +	image = xchg(dest_image, image);
> +
> +failure_unmap_mem:

I don't like this tag "failure_unmap_mem". We are calling this both
in success path as well as failure path. So why not simply call it "out".

> +	if (flags & KEXEC_ON_CRASH)
> +		crash_unmap_reserved_pages();
> +	kimage_free(image);

Now kimage_free() is called with kexec_mutex held. Previously that was
not the case. I hope that's not a problem.

> +	return result;
> +}
> +

Thanks
Vivek

  parent reply	other threads:[~2015-07-14 14:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10  5:12 [PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start Minfei Huang
2015-07-10  5:12 ` Minfei Huang
2015-07-10  8:54 ` Michael Holzheu
2015-07-10  8:54   ` Michael Holzheu
2015-07-10  9:03   ` Minfei Huang
2015-07-10  9:03     ` Minfei Huang
2015-07-10  9:14     ` Michael Holzheu
2015-07-10  9:14       ` Michael Holzheu
2015-07-10  9:29       ` Michael Holzheu
2015-07-10  9:29         ` Michael Holzheu
2015-07-14 14:09       ` Vivek Goyal [this message]
2015-07-14 14:09         ` Vivek Goyal
2015-07-14 18:10         ` Michael Holzheu
2015-07-14 18:10           ` Michael Holzheu

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=20150714140920.GA10792@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=mnfhuang@gmail.com \
    --cc=schwidefsky@de.ibm.com \
    /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.