All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Trammell Hudson <hudson@trmm.net>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"wl@xen.org" <wl@xen.org>
Subject: Re: [PATCH v4 3/4] efi: Enable booting unified hypervisor/kernel/initrd images
Date: Wed, 16 Sep 2020 12:15:34 +0200	[thread overview]
Message-ID: <20200916101020.GU753@Air-de-Roger> (raw)
In-Reply-To: <vJMfvKtNZyMgJ7EsE4gKz79cATC-4xxU3hrAkz1PlvmArEQJ_jcXR61uiCggcKjISspFs2h4CrL1M9uLGM1kI25UmudG9YueJY1af6VPDmY=@trmm.net>

On Wed, Sep 16, 2020 at 08:37:44AM +0000, Trammell Hudson wrote:
> On Wednesday, September 16, 2020 3:32 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> > On Mon, Sep 14, 2020 at 07:50:12AM -0400, Trammell Hudson wrote:
> > > -   s2w(&name_string);
> >
> > Don't you need to check that s2w succeed, so that name_string.w is not
> > a random pointer from stack garbage?
> 
> Maybe? I don't see anywhere else in the code that s2w() is
> ever checked for a NULL return.

I see some callers pass the return of s2w() straight into read_file
which will check that's not NULL before proceeding, or else call
PrintErrMesg which won't return.

> Perhaps a better fix would
> be to modify the function to panic if it is unable
> to allocate.

Just doing what read_file does and use PrintErrMesg seems fine to me.

Roger.


  parent reply	other threads:[~2020-09-16 10:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 11:50 [PATCH v4 0/4] efi: Unified Xen hypervisor/kernel/initrd images Trammell Hudson
2020-09-14 11:50 ` [PATCH v4 1/4] efi/boot.c: add file.need_to_free Trammell Hudson
2020-09-16  6:43   ` Roger Pau Monné
2020-09-17 11:06     ` Jan Beulich
2020-09-14 11:50 ` [PATCH v4 2/4] efi/boot.c: add handle_file_info() Trammell Hudson
2020-09-16  6:46   ` Roger Pau Monné
2020-09-17 11:29   ` Jan Beulich
2020-09-14 11:50 ` [PATCH v4 3/4] efi: Enable booting unified hypervisor/kernel/initrd images Trammell Hudson
2020-09-16  7:32   ` Roger Pau Monné
2020-09-16  8:37     ` Trammell Hudson
2020-09-16  9:47       ` Jan Beulich
2020-09-16 10:15       ` Roger Pau Monné [this message]
2020-09-17 12:33   ` Jan Beulich
2020-09-17 13:04     ` Trammell Hudson
2020-09-17 13:33       ` Trammell Hudson
2020-09-17 15:10         ` Jan Beulich
2020-09-17 15:21       ` Jan Beulich
2020-09-14 11:50 ` [PATCH v4 4/4] efi: Do not use command line if secure boot is enabled Trammell Hudson
2020-09-16  7:45   ` Roger Pau Monné
2020-09-16  8:50     ` Trammell Hudson
2020-09-16  9:57       ` Jan Beulich
2020-09-17 12:51   ` Jan Beulich
2020-09-17 14:05     ` Trammell Hudson
2020-09-17 15:26       ` Jan Beulich
2020-09-17 15:45         ` Trammell Hudson

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=20200916101020.GU753@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=hudson@trmm.net \
    --cc=jbeulich@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.