MIME-Version: 1.0
References: <20211220035448.12054-1-yajun.deng@linux.dev>
In-Reply-To: <20211220035448.12054-1-yajun.deng@linux.dev>
From:   Marco Elver <elver@google.com>
Date:   Mon, 20 Dec 2021 12:20:13 +0100
Message-ID: <CANpmjNPsCVkq7SsVL-xpktGe3RsJnRGTJxEPZ60VUt1w_5QgPQ@mail.gmail.com>
Subject: Re: [PATCH] init: fix the wrong __setup_param() definition
To:     Yajun Deng <yajun.deng@linux.dev>
Cc:     keescook@chromium.org, samitolvanen@google.com, ojeda@kernel.org,
        masahiroy@kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 20 Dec 2021 at 04:55, Yajun Deng <yajun.deng@linux.dev> wrote:
>
> The parameters in __setup_param() should be four rather than three when
> MODULE isn't definited.

This is actually "when MODULE is defined". __setup_param() becomes a
nop when compiling as a module.

But that begs the question: why hasn't this been caught before?
Probably because nobody should be using __setup_param() if something
can also be compiled as a module, in which case module_param() and
friends should be used. But perhaps there are valid usecases where i
t's meant to become a nop if MODULE.

I don't object this fix, since the !MODULE __setup_param() seems like
it was meant to be defined.

Just curious: did you actually encounter a problem with some new code
using __setup_param()?

> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
> ---
>  include/linux/init.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/init.h b/include/linux/init.h
> index d82b4b2e1d25..62a77850f10e 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -355,7 +355,7 @@ void __init parse_early_options(char *cmdline);
>
>  #else /* MODULE */
>
> -#define __setup_param(str, unique_id, fn)      /* nothing */
> +#define __setup_param(str, unique_id, fn, early)/* nothing */
>  #define __setup(str, func)                     /* nothing */
>  #endif
>
> --
> 2.32.0
>