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] dyndbg: make dyndbg a known cli param
To:     Andrew Halaney <ahalaney@redhat.com>
Cc:     linux-kernel@vger.kernel.org, Jim Cromie <jim.cromie@gmail.com>
References: <20210909161755.61743-1-ahalaney@redhat.com>
From:   Jason Baron <jbaron@akamai.com>
Message-ID: <0849504a-b7ed-f448-6d66-1a9fd5ad70ce@akamai.com>
Date:   Thu, 9 Sep 2021 17:34:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210909161755.61743-1-ahalaney@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 9/9/21 12:17 PM, Andrew Halaney wrote:
> Right now dyndbg shows up as an unknown parameter if used on boot:
> 
>     Unknown command line parameters: dyndbg=module params +p ; module sys +p
> 
> That's because it is unknown, it doesn't sit in the __param
> section, so the processing done to warn users supplying an unknown
> parameter doesn't think it is legitimate.
> 
> Install a dummy handler to register it. This was chosen instead of the
> approach the (deprecated) ddebug_query param takes, which is to
> have a real handler that copies the string taking up a KiB memory.
> 
> Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters")
> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> ---
> 
> This is the last valid param I know of that was getting flagged on boot
> if used correctly. Please let me know if the alternative approach of
> actually copying the string is preferred and I'll spin that up instead.
> 

Hi Andrew,

So I think you are referring to the string copying that ddebug_query= does.
I don't think that works for 'dyndbg=' b/c its actually looking through
the entire command line for stuff like <module_name>.dyndbg="blah".

So I think what you prposed below makes sense, we could perhaps add a note
as to why it's a noop. As I mentioned it needs to look through the entire
string.


> Sort of an aside, but what's the policy for removing deprecated cli
> params? ddebug_query has been deprecated for a very long time now, but I
> am not sure if removing params like that is considered almost as bad as
> breaking userspace considering some systems might update their kernels
> but not the bootloader supplying the param.

I think it's probably ok to remove at this point, especially now that
we are going to flag it as unknown, right? So I feel like that change
can logically go with this series if you want as a separate patch.

Thanks,

-Jason


> 
>  lib/dynamic_debug.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index cb5abb42c16a..84c16309cc63 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -761,6 +761,18 @@ static __init int ddebug_setup_query(char *str)
>  
>  __setup("ddebug_query=", ddebug_setup_query);
>  
> +/*
> + * Install a noop handler to make dyndbg look like a normal kernel cli param.
> + * This avoids warnings about dyndbg being an unknown cli param when supplied
> + * by a user.
> + */
> +static __init int dyndbg_setup(char *str)
> +{
> +	return 1;
> +}
> +
> +__setup("dyndbg=", dyndbg_setup);
> +
>  /*
>   * File_ops->write method for <debugfs>/dynamic_debug/control.  Gathers the
>   * command text from userspace, parses and executes it.
>