mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	ebiederm@xmission.com, hpa@zytor.com, mjg59@srcf.ucam.org,
	greg@kroah.com, jkosina@suse.cz, dyoung@redhat.com,
	chaowang@redhat.com, bhe@redhat.com, akpm@linux-foundation.org
Subject: Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load
Date: Fri, 6 Jun 2014 04:11:33 +0200	[thread overview]
Message-ID: <20140606021133.GB27257@pd.tnic> (raw)
In-Reply-To: <20140605201732.GF14083@redhat.com>

On Thu, Jun 05, 2014 at 04:17:32PM -0400, Vivek Goyal wrote:
> I think everything is already available in "struct kimage *image". So
> I don't have to pass all these separately. I think I will remove all
> these extra parameters and expect arch function to retrieve all that
> from "struct kimage *image".

Sounds good.

> I guess I was trying to make "struct kimage" mostly opaque to arch
> functions.

Sure, of course. The question is, is it really worth it at the price
of having a lot of args. And you're passing struct kimage to arch_*
functions anyway.

...

> It is obivious that we are freeing memory but what was not obivious to
> me that I already copied contents of these buffers in a seaparate memory
> region (segment), hence I am able to free it. So I would like to keep
> comment there.

Ok.

> > > +
> > > +	result = -ENOMEM;
> > > +	image->control_code_page = kimage_alloc_control_pages(image,
> > > +					   get_order(KEXEC_CONTROL_PAGE_SIZE));
> > > +	if (!image->control_code_page) {
> > > +		pr_err("Could not allocate control_code_buffer\n");
> > 
> > Might wanna define pr_fmt when using the pr_* things fo the first time
> > in this file.
> 
> Hmm....
> 
> I see that printk.h already provides a definition is pr_fmt is not
> defined. So that means I shouldn't have to define pr_fmt() before I
> use pr_*?
> 
> #ifndef pr_fmt
> #define pr_fmt(fmt) fmt
> #endif

Yep, so you could do

#undef pr_fmt
#define pr_fmt(fmt) "kexec: "

or you can do the standard

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Just look around the tree for examples, there's plenty.

> > This test looks strange: according to it, kexec_file_load has to always
> > be called with both KEXEC_FILE_UNLOAD and KEXEC_FILE_ON_CRASH set.
> 
> I think this test says that "flags" has to be some combination of valid
> flags and superset is in KEXEC_FILE_FLAGS.
> 
> So user can pass only KEXEC_FILE_ON_CRASH.
> flags = 0x00000002
> KEXEC_FILE_FLAGS = 0x0x00000003
> flags & KEXEC_FILE_FLAGS = 0x00000002 = flags.

Bah, ignore me - I got confused, sorry.

> > > +	kbuf->buf_align = max(buf_align, PAGE_SIZE);
> > > +	kbuf->buf_min = buf_min;
> > > +	kbuf->buf_max = buf_max;
> > > +	kbuf->top_down = top_down;
> > > +
> > > +	/* Walk the RAM ranges and allocate a suitable range for the buffer */
> > > +	walk_system_ram_res(0, -1, kbuf, walk_ram_range_callback);
> > > +
> > > +	/*
> > > +	 * If range could be found successfully, it would have incremented
> > > +	 * the nr_segments value.
> > > +	 */
> > > +	new_nr_segments = image->nr_segments;
> > > +
> > > +	/* A suitable memory range could not be found for buffer */
> > > +	if (new_nr_segments == nr_segments)
> > > +		return -EADDRNOTAVAIL;
> > 
> > Right, why don't you check walk_system_ram_res's retval? If it is != 0,
> > i.e. walk_ram_range_callback gives a 1 on "success", you can drop this
> > way of checking whether finding a new range succeeded.
> 
> In last version when I had ELF header support, I was checking for return
> code 1 at one place and you had not liked that.
> 
> Anyway, I am thinking that problem here is that walk_* variants use
> return code of called function to decide whether to continue looping
> or not. I think these are two independent activities.  Pass a boolean
> to called function which should be set to false if callee wants to
> stop the loop.
> 
> That way, callee can pass both errors and success without having to
> worry about loop. And callee can return 0 to represent success and
> negative error code to represent error.

But why? It should be caller's responsibility to deal with the errors.
If it encounters one, it either decides to stop looping or not.

In any case, you don't need a second bool arg to pass around.

If you want to make it more explicit, you could do

#define RES_OK		0
#define RES_ERR		1
#define RES_STOP	2

("RES" for resource :-)) and signal what to do by returning one of those
return values. Or?

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-06-06  2:14 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 13:06 [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading Vivek Goyal
2014-06-03 13:06 ` [PATCH 01/13] bin2c: Move bin2c in scripts/basic Vivek Goyal
2014-06-03 16:01   ` Borislav Petkov
2014-06-03 17:13     ` Vivek Goyal
2014-06-03 13:06 ` [PATCH 02/13] kernel: Build bin2c based on config option CONFIG_BUILD_BIN2C Vivek Goyal
2014-06-04  9:13   ` Borislav Petkov
2014-06-03 13:06 ` [PATCH 03/13] kexec: Move segment verification code in a separate function Vivek Goyal
2014-06-04  9:32   ` Borislav Petkov
2014-06-04 18:47     ` Vivek Goyal
2014-06-04 20:30       ` Borislav Petkov
2014-06-05 14:05         ` Vivek Goyal
2014-06-05 14:07           ` Borislav Petkov
2014-06-03 13:06 ` [PATCH 04/13] resource: Provide new functions to walk through resources Vivek Goyal
2014-06-04 10:24   ` Borislav Petkov
2014-06-05 13:58     ` Vivek Goyal
2014-06-03 13:06 ` [PATCH 05/13] kexec: Make kexec_segment user buffer pointer a union Vivek Goyal
2014-06-04 10:34   ` Borislav Petkov
2014-06-03 13:06 ` [PATCH 06/13] kexec: New syscall kexec_file_load() declaration Vivek Goyal
2014-06-04 15:18   ` Borislav Petkov
2014-06-05  9:56   ` WANG Chao
2014-06-05 15:16     ` Vivek Goyal
2014-06-05 15:22       ` Vivek Goyal
2014-06-06  6:34         ` WANG Chao
2014-06-03 13:06 ` [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load Vivek Goyal
2014-06-05 11:15   ` Borislav Petkov
2014-06-05 20:17     ` Vivek Goyal
2014-06-06  2:11       ` Borislav Petkov [this message]
2014-06-06 18:02         ` Vivek Goyal
2014-06-11 14:13           ` Borislav Petkov
2014-06-11 17:04             ` Vivek Goyal
2014-06-06  6:56   ` WANG Chao
2014-06-06 18:19     ` Vivek Goyal
2014-06-09  2:11       ` Dave Young
2014-06-09  5:35         ` WANG Chao
2014-06-09 15:41           ` Vivek Goyal
2014-06-13  7:50             ` Borislav Petkov
2014-06-13  8:00               ` WANG Chao
2014-06-13  8:10                 ` Borislav Petkov
2014-06-13  8:24                   ` WANG Chao
2014-06-13  8:30                     ` Borislav Petkov
2014-06-13 12:49                 ` Vivek Goyal
2014-06-13 12:46               ` Vivek Goyal
2014-06-13 15:36                 ` Borislav Petkov
2014-06-16 17:38                   ` Vivek Goyal
2014-06-16 20:05                     ` Borislav Petkov
2014-06-16 20:53                       ` Vivek Goyal
2014-06-16 21:09                         ` Borislav Petkov
2014-06-16 21:25                           ` H. Peter Anvin
2014-06-16 21:43                             ` Vivek Goyal
2014-06-16 22:10                               ` Borislav Petkov
2014-06-16 22:49                               ` H. Peter Anvin
2014-06-09 15:30         ` Vivek Goyal
2014-06-03 13:06 ` [PATCH 08/13] purgatory/sha256: Provide implementation of sha256 in purgaotory context Vivek Goyal
2014-06-03 13:06 ` [PATCH 09/13] purgatory: Core purgatory functionality Vivek Goyal
2014-06-05 20:05   ` Borislav Petkov
2014-06-06 19:51     ` Vivek Goyal
2014-06-13 10:17       ` Borislav Petkov
2014-06-16 17:25         ` Vivek Goyal
2014-06-16 20:10           ` Borislav Petkov
2014-06-03 13:06 ` [PATCH 10/13] kexec: Load and Relocate purgatory at kernel load time Vivek Goyal
2014-06-10 16:31   ` Borislav Petkov
2014-06-11 19:24     ` Vivek Goyal
2014-06-13 16:14       ` Borislav Petkov
2014-06-03 13:07 ` [PATCH 11/13] kexec-bzImage: Support for loading bzImage using 64bit entry Vivek Goyal
2014-06-15 16:35   ` Borislav Petkov
2014-06-15 16:56     ` H. Peter Anvin
2014-06-16 20:06     ` Vivek Goyal
2014-06-16 20:57       ` Borislav Petkov
2014-06-16 21:15         ` Vivek Goyal
2014-06-16 21:27           ` Borislav Petkov
2014-06-16 21:45             ` Vivek Goyal
2014-06-24 17:31     ` Vivek Goyal
2014-06-24 18:23       ` Borislav Petkov
2014-06-03 13:07 ` [PATCH 12/13] kexec: Support for Kexec on panic using new system call Vivek Goyal
2014-06-17 21:43   ` Borislav Petkov
2014-06-18 14:20     ` Vivek Goyal
2014-06-03 13:07 ` [PATCH 13/13] kexec: Support kexec/kdump on EFI systems Vivek Goyal
2014-06-18 15:43   ` Borislav Petkov
2014-06-18 16:06   ` Borislav Petkov
2014-06-18 17:39     ` Vivek Goyal
2014-06-03 13:12 ` [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading Vivek Goyal
2014-06-04  9:22   ` WANG Chao
2014-06-04 17:50     ` Vivek Goyal
2014-06-04 19:39       ` Michael Kerrisk
2014-06-05 14:04         ` Vivek Goyal
2014-06-06  5:45           ` Michael Kerrisk (man-pages)
2014-06-06 18:04             ` Vivek Goyal
2014-06-05  8:31   ` Dave Young
2014-06-05 15:01     ` Vivek Goyal
2014-06-06  7:37       ` Dave Young
2014-06-06 20:04         ` Vivek Goyal
2014-06-09  1:57           ` Dave Young
2014-06-06 20:37         ` H. Peter Anvin
2014-06-06 20:58           ` Matt Fleming
2014-06-06 21:00             ` H. Peter Anvin
2014-06-06 21:02               ` Matt Fleming
2014-06-12  5:42 ` Dave Young
2014-06-12 12:36   ` Vivek Goyal
2014-06-17 14:24   ` Vivek Goyal
2014-06-18  1:45     ` Dave Young
2014-06-18  1:52       ` Dave Young
2014-06-18 12:40         ` Vivek Goyal
2014-06-16 21:13 ` Borislav Petkov
2014-06-17 13:24   ` Vivek Goyal

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=20140606021133.GB27257@pd.tnic \
    --to=bp@alien8.de \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®