linux-kernel - Re: RFC - KBUILD_MODNAME is misleading in builtins, as seen in /proc/dynamic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNATGL4oBPO6s27Zp15-TvD=y4BuqD24YHzLMJxcbk_Ff3w@mail.gmail.com>
Date:   Tue, 21 Mar 2023 15:45:02 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     jim.cromie@...il.com
Cc:     Jason Baron <jbaron@...mai.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-kbuild@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>,
        Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: RFC - KBUILD_MODNAME is misleading in builtins, as seen in /proc/dynamic_debug/control

On Tue, Mar 21, 2023 at 5:00 AM <jim.cromie@...il.com> wrote:
>
> On Mon, Mar 20, 2023 at 12:35 PM Jason Baron <jbaron@...mai.com> wrote:
> >
> >
> >
> > On 3/20/23 1:05 AM, jim.cromie@...il.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 = {                          \
> > >                  .modname = KBUILD_MODNAME,                      \
> > >
> > > This is going amiss for some builtins, ie those enabled here, by:
> > >
> > >      echo module main +pmf > /proc/dynamic_debug_control
> > >      grep =pmf /proc/dynamic_debug/control
> > >
> > > init/main.c:1187 [main]initcall_blacklist =pmf "blacklisting initcall %s\n"
> > > init/main.c:1226 [main]initcall_blacklisted =pmf "initcall %s blacklisted\n"
> > > init/main.c:1432 [main]run_init_process =pmf "  with arguments:\n"
> > > init/main.c:1434 [main]run_init_process =pmf "    %s\n"
> > > init/main.c:1435 [main]run_init_process =pmf "  with environment:\n"
> > > init/main.c:1437 [main]run_init_process =pmf "    %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 some time.
>
> I believe that with
> cfc1d277891e module: Move all into module/
>
> module's module-name joined them, changing from [module] to [main]

Maybe more.

We have almost 100 'main.c' files.

$ find . -name main.c | wc
     97      97    3473





> 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 something
> > 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.


I do not understand what you mean.


KBUILD_MODNAME is not affected by the y/m configuration.




If an object is a member of a composite object, which
does not necessarily be a real module, KBUILD_MODNAME
refers to the name of the composite.
Otherwise, the basename of the source file.


Examples:


obj-y += alias-name.o
alias-name-objs := foo.o

  -->  KBUILD_MODNAME is "alias-name"



obj-y += foo.o

  -->  KBUILD_MODNAME is "foo"



This is about how you write Makefile code.
CONFIG options are unrelated.







> Also, I dont think "only builtins are affected" captures the whole problem.
> I dont recall amdgpu or other modules changing when built with =y
>
> 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 default.
>
> arch/x86/events/amd/ibs.c:1398 [ibs]force_ibs_eilvt_setup =_ "No EILVT
> entry available\n"
> arch/x86/events/intel/pt.c:797 [pt]pt_topa_dump =_ "# table @%p, off
> %llx size %zx\n"w=%16llx\n"
>
> kvm gets a solid name, because tristate ?
>
> arch/x86/kvm/mmu/mmu.c:6661 [kvm]kvm_mmu_invalidate_mmio_sptes =_
> "kvm: kvm [%i]: zapping shadow pages for mmio generation wraparound\n"
> arch/x86/kvm/hyperv.c:1402 [kvm]kvm_hv_set_msr_pw =_ "kvm [%i]: vcpu%i
> hv crash (0x%llx 0x%llx 0x%llx 0x%llx 0x%llx)\n"
>
> kvm-intel and kvm-amd get their names elsewhere.
>
> arch/x86/kvm/vmx/nested.c:207 [kvm_intel]nested_vmx_abort =_
> "kvm_intel: nested vmx abort, indicator %d\n"
> arch/x86/kvm/vmx/nested.c:913 [kvm_intel]nested_vmx_load_msr =_
> "kvm_intel: %s cannot read MSR entry (%u, 0x%08llx)\n"
>
> arch/x86/kvm/svm/avic.c:860 [kvm_amd]get_pi_vcpu_info =_ "SVM: %s: use
> GA mode for irq %u\n"
> arch/x86/kvm/svm/avic.c:889 [kvm_amd]avic_pi_update_irte =_ "SVM: %s:
> host_irq=%#x, guest_irq=%#x, set=%#x\n"
>
> iow, I dont know..
>
> >
> > Thanks,
> >
> > -Jason



-- 
Best Regards
Masahiro Yamada