From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ricardo Neri
<ricardo.neri-calderon-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Glenn P. Williamson"
<glenn.p.williamson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v2] efi: Check for null efi kernel parameters
Date: Thu, 30 Jul 2015 13:30:48 +0100 [thread overview]
Message-ID: <20150730123047.GE2725@codeblueprint.co.uk> (raw)
In-Reply-To: <1437701417.10814.12.camel@ranerica-desk01>
On Thu, 23 Jul, at 06:30:17PM, Ricardo Neri wrote:
> >
> > Ricardo, any reason not change in parse_option_str general function?
> > I prefer to fix it in parse_option_str, because it is for checking
> > if str contains an option string, if str is NULL then it should
> > return false.
>
> Yes, I thought about it as well. I thought that this implementation
> aligns with what the majority of the param functions does. That was the
> main reason. But having this in parse_option_str might seem a better
> alternative if more param functions use it.
> >
> > But since it is only used in efi code for now so I have no strong opinion.
>
> Matt, do you have any specific preference?
Yeah, I like Ricardo's patch.
The problem with fixing this in parse_option_str() is that it would be
difficult to distinguish between "str is invalid" and "option wasn't
found in str". You'd have to start inspecting the return value to be
able to print a useful message in the caller, e.g.
ret = parse_option_str(str, "foobar");
if (ret == -EINVAL)
pr_err("No option provided for efi parameter");
if (ret == -ENOENT)
return; /* "foobar" not found */
etc.
Plus there's precedence for checking 'str' for NULL in early_param()
handlers.
--
Matt Fleming, Intel Open Source Technology Center
prev parent reply other threads:[~2015-07-30 12:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 2:36 [PATCH v2] efi: Check for null efi kernel parameters Ricardo Neri
[not found] ` <1437014163-4652-1-git-send-email-ricardo.neri-calderon-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2015-07-21 9:22 ` Dave Young
[not found] ` <20150721092217.GA7361-sa4SJRhfYT7GSfWCAtytT/XAX3CI6PSWQQ4Iyu8u01E@public.gmane.org>
2015-07-24 1:30 ` Ricardo Neri
2015-07-24 7:32 ` Dave Young
2015-07-30 12:30 ` Matt Fleming [this message]
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=20150730123047.GE2725@codeblueprint.co.uk \
--to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
--cc=dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=glenn.p.williamson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=ricardo.neri-calderon-VuQAYsv1563Yd54FQh9/CA@public.gmane.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.