MIME-Version: 1.0
References: <CAJfuBxyeKz3bsc=WfjJZDKgAHScC80_irQvmsecxPukjM-J8gw@mail.gmail.com>
 <6af9da81-7a7b-9f47-acb1-d0350bae7f3f@akamai.com> <CAJfuBxyoeuurDoUe2tLs=JbX=BbxGdYpf2yBEP6bkhtFh2XTtQ@mail.gmail.com>
 <ZBjKb8fXHOxnHuHD@bombadil.infradead.org>
In-Reply-To: <ZBjKb8fXHOxnHuHD@bombadil.infradead.org>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue, 21 Mar 2023 18:03:01 +0900
Message-ID: <CAK7LNASVpBih3iSHd=RXkKNZQ-v5LVzEOuZG3H_i3fcZfsGhDA@mail.gmail.com>
Subject: Re: RFC - KBUILD_MODNAME is misleading in builtins, as seen in /proc/dynamic_debug/control
To:     Luis Chamberlain <mcgrof@kernel.org>
Cc:     jim.cromie@gmail.com, linux-modules@vger.kernel.org,
        Nick Alcock <nick.alcock@oracle.com>,
        Aaron Tomlin <atomlin@redhat.com>,
        Jason Baron <jbaron@akamai.com>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-kbuild@vger.kernel.org, Greg KH <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Mar 21, 2023 at 6:04=E2=80=AFAM Luis Chamberlain <mcgrof@kernel.org=
> wrote:
>
> On Mon, Mar 20, 2023 at 01:59:28PM -0600, jim.cromie@gmail.com wrote:
> > On Mon, Mar 20, 2023 at 12:35=E2=80=AFPM Jason Baron <jbaron@akamai.com=
> wrote:
> > >
> > >
> > >
> > > On 3/20/23 1:05 AM, jim.cromie@gmail.com wrote:
> > > > dynamic-debug METADATA uses KBUILD_MODNAME as:
> > > >
> > > > #define DEFINE_DYNAMIC_DEBUG_METADATA_CLS(name, cls, fmt)       \
> > > >          static struct _ddebug  __aligned(8)                     \
> > > >          __section("__dyndbg") name =3D {                          =
\
> > > >                  .modname =3D KBUILD_MODNAME,                      =
\
> > > >
> > > > This is going amiss for some builtins, ie those enabled here, by:
> > > >
> > > >      echo module main +pmf > /proc/dynamic_debug_control
> > > >      grep =3Dpmf /proc/dynamic_debug/control
> > > >
> > > > init/main.c:1187 [main]initcall_blacklist =3Dpmf "blacklisting init=
call %s\n"
> > > > init/main.c:1226 [main]initcall_blacklisted =3Dpmf "initcall %s bla=
cklisted\n"
> > > > init/main.c:1432 [main]run_init_process =3Dpmf "  with arguments:\n=
"
> > > > init/main.c:1434 [main]run_init_process =3Dpmf "    %s\n"
> > > > init/main.c:1435 [main]run_init_process =3Dpmf "  with environment:=
\n"
> > > > init/main.c:1437 [main]run_init_process =3Dpmf "    %s\n"
> > >
> > >
> > > Hi Jim,
> > >
> > > So if I'm following correctly, this is not a new issue, the 'module'
> > > name for dynamic debug has always been this way for builtin.
> >
> > It is not a new issue - both PM and init-main have been in [main] for s=
ome time.
> >
> > I believe that with
> > cfc1d277891e module: Move all into module/
> >
> > module's module-name joined them, changing from [module] to [main]
>
> If there was a regression due to this, we'd be very interested in
> hearing about it. Aaron he did the work to move the code to its own direc=
tory.
>
> > We could do
> > > something simple and just normalize it when we initially create the
> > > table, but setting the 'module name' to 'core' or 'builtin' or someth=
ing
> > > for all these?
> >
> > core and builtin would both lump all those separate modules together,
> > making it less meaningful.
> >
> > having stable names independent of M vs Y config choices is imperative,=
 ISTM.
> >
> > Also, I dont think "only builtins are affected" captures the whole prob=
lem.
> > I dont recall amdgpu or other modules changing when built with =3Dy
> >
> > Theres some subtlety in how KBUILD_MODNAME is set,
> > and probably many current users who like its current behavior.
> > A new var ?
> >
> > 1st, I think that anything tristate gets a sensible value,
> > but at least some of the builtin-only "modules" get basenames, by defau=
lt.
>
> In general we could all benefit from an enhancement for a shortname for
> things which could be modules being built-in. We're now seeing requests
> for dynamic debug, but it could also be usefulf for Nick's future work
> to help userspace tools / tracing map kallsysms to specific modules when
> built-in.


I think I rejected it some years ago.
He comes back again and again with almost the same approaches,
until he finds a "sponsor" (it's you) who will get it in.

Recently, I rejected the Kbuild changes again.


> To that end I had suggested the current state of affairs & current diffic=
ulty
> in trying to get us a name for this here:
>
> https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/
>
> I ended up suggesting perhaps we need a -DPOSSIBLE_MODULE then if we
> could *somehow* pull that off perhaps then we could instead use
> -DPOSSIBLE_KBUILD_MODNAME which would ensure a consistent symbol when
> a module is built-in as well.
>
> That still leaves the difficulty in trying to gather possible-obj-m as
> a future challenge.


I do not understand your point.

Why is it important to achieve "precisely-exactly-possible-obj-m" instead o=
f
"perhaps-possible-obj-m"?


When "modprobe foo" succeeds, the user is sure that the kernel
provides the feature "foo" (but he does not care if
"foo" is built-in or modular).

I think that is the point for kmod check also module.builtin
before saying no.


When CONFIG_FOO=3Dy, "modprobe foo" succeeds because "foo" is available
as built-in.
When CONFIG_FOO=3Dn, "modprobe foo" fails because "foo" is not available an=
ywhere.
I do not see anything wrong here.

Why do we need to make "modprobe foo" fail, where the feature "foo" is
still available
but just because we cannot compile it as a module?

He spams with MODULE_LICENSE removal with no justification.

--=20
Best Regards
Masahiro Yamada