Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2] init: Print out unknown kernel parameters
To:     Andrew Halaney <ahalaney@redhat.com>
Cc:     akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
        Steven Rostedt <rostedt@goodmis.org>,
        Borislav Petkov <bp@suse.de>
References: <20210511211009.42259-1-ahalaney@redhat.com>
 <cbd3c07e-9dae-44b2-761e-653bd8d0e930@infradead.org>
 <20210513130050.6czigy6cpz34ovz7@halaneylaptop>
From:   Randy Dunlap <rdunlap@infradead.org>
Message-ID: <d77f6819-9d3b-8d50-16cb-fff1a62dc67d@infradead.org>
Date:   Thu, 13 May 2021 09:06:35 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <20210513130050.6czigy6cpz34ovz7@halaneylaptop>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/13/21 6:00 AM, Andrew Halaney wrote:
> On Wed, May 12, 2021 at 04:00:21PM -0700, Randy Dunlap wrote:
>> On 5/11/21 2:10 PM, Andrew Halaney wrote:
>>> It is easy to foobar setting a kernel parameter on the command line
>>> without realizing it, there's not much output that you can use to
>>> assess what the kernel did with that parameter by default.
>>>
>>> Make it a little more explicit which parameters on the command line
>>> _looked_ like a valid parameter for the kernel, but did not match
>>> anything and ultimately got tossed to init. This is very similar to the
>>> unknown parameter message received when loading a module.
>>>
>>> This assumes the parameters are processed in a normal fashion, some
>>> parameters (dyndbg= for example) don't register their
>>> parameter with the rest of the kernel's parameters, and therefore
>>> always show up in this list (and are also given to init - like the
>>> rest of this list).
>>>
>>> Another example is BOOT_IMAGE= is highlighted as an offender, which it
>>> technically is, but is passed by LILO and GRUB so most systems will see
>>> that complaint.
>>>
>>> An example output where "foobared" and "unrecognized" are intentionally
>>> invalid parameters:
>>>
>>>   Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
>>>   Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo
>>
>> Hi Andrew,
>> What order is the list of unknown command line parameters listed in?
> 
> Hi Randy,
> 
> That's a good question considering that they are out of order in my
> example output compared to the command line. The order is parameters
> without an "=val", then those with an "=val", and within those groups
> they should be ordered as they are on the command line.
> 
> This is because I'm using the processing work done by
> unknown_bootoption(), which stores them in two separate lists to pass to
> init later (for arguments and environment). I am "stealing" from those
> here:
> 
> 	for (p = &argv_init[1]; *p; p++)
> 		end += sprintf(end, " %s", *p);
> 	for (p = &envp_init[2]; *p; p++)
> 		end += sprintf(end, " %s", *p);
> 
> hence the differing output order from the command line. I didn't
> see much value in trying to duplicate that processing logic to get them in
> a single list in the order of the command line itself. I debated looking
> at the command line and searching each of the offending lists for that
> entry to get them in the order of the command line but decided to keep
> it simple here since it was achieving what I wanted.

Thanks for explaining. That's what I was looking for.

-- 
~Randy