[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <568D5574.2000006@sr71.net>
Date: Wed, 6 Jan 2016 09:57:08 -0800
From: Dave Hansen <dave@...1.net>
To: x86@...nel.org
Cc: linux-kernel@...r.kernel.org, dave.hansen@...ux.intel.com,
bp@...e.de, hpa@...or.com, fenghua.yu@...el.com,
yu-cheng.yu@...el.com
Subject: Re: [PATCH 1/5] x86: fix early command-line parsing when matching at
end
Moving over to the actual patch we're talking about...
On 12/22/2015 02:52 PM, Dave Hansen wrote:
> @@ -37,11 +39,14 @@ int cmdline_find_option_bool(const char
> if (!cmdline)
> return -1; /* No command line */
>
> - len = min_t(int, strlen(cmdline), COMMAND_LINE_SIZE);
> - if (!len)
> + if (!strlen(cmdline))
> return 0;
>
> - while (len--) {
> + /*
> + * This 'pos' check ensures we do not overrun
> + * a non-NULL-terminated 'cmdline'
> + */
> + while (pos < COMMAND_LINE_SIZE) {
Borislav says:
>> So why not leave the min_t:
>>
>> maxlen = min_t(int, strlen(cmdline), COMMAND_LINE_SIZE);
>>
>> and then do:
>>
>> while (pos < maxlen)
That works, and it's functionally equivalent to what I have (I think).
I like what I have because it separates the 'strlen' checking from the
COMMAND_LINE_SIZE checking, which makes it super duper obvious that the
third patch here is OK.
So, after the third patch, the strlen() goes away any way you do this.
The code ends up looking the same (the while() check is against the
max-length variable alone).
I'm happy to rewrite this to have a different intermediate form and
repost the thing, but the end result will be the same.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists