linux-kernel - Re: [PATCH] namespace: fix namespace.pl script to support relative paths

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: <CAK7LNAQow8N9a5e_=pu7qDiuvETy1x1P5fxp20zYOZgQhXPJhg@mail.gmail.com>
Date:   Thu, 24 Oct 2019 10:21:57 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH] namespace: fix namespace.pl script to support relative paths

On Thu, Oct 24, 2019 at 6:34 AM Keller, Jacob E
<jacob.e.keller@...el.com> wrote:
>
> > -----Original Message-----
> > From: Masahiro Yamada <yamada.masahiro@...ionext.com>
> > Sent: Tuesday, October 22, 2019 10:22 PM
> > To: Keller, Jacob E <jacob.e.keller@...el.com>; Randy Dunlap
> > <rdunlap@...radead.org>
> > Cc: intel-wired-lan@...ts.osuosl.org; linux-kernel@...r.kernel.org; linux-kbuild
> > <linux-kbuild@...r.kernel.org>
> > Subject: Re: [PATCH] namespace: fix namespace.pl script to support relative
> > paths
> >
> > This scripts has been 5-year broken,
> > and I did not see any complaint except from you.
> > So, I wonder how many people are using this.
> >
> > Nor, do I understand how to use it.
> >
> > Could you teach me a bit more about this script?
> >
> >
> >
> > Something might be missing in my mind, but
> > I do not know how to use this script in a useful way.
> >
> >
> >
> > It provides three checks.
> >
> > [1] list_multiply_defined()
> >
> > This warns multiple definition of functions.
> >
> > The compiler would fail if it saw any multiple definition,
> > so the reports from this check are all false-positive.
> >
> >
> > [2] resolve_external_references()
> >
> > This warns unresolved symbols.
> >
> > The compiler would fail if it saw any unresolved symbol,
> > so the reports from this check are all false-positive, too.
> >
> >
>
> The compiler won't necessarily fail when building modules, because the symbol might be in another loadable module.

Right, but this is already checked by modpost, isn't it?



> >
> >
> > [3] list_extra_externals
> >
> > This warns symbols with no reference.
> >
> > This potentially contains lots of false-positives.
> > For example, the core framework provides APIs, but if all drivers
> > are disabled, there is no user of those APIs.
> >
>
> We use this to help verify that driver modules do not expose symbols.

Ah, the output is quite large, so
you search for only modules in your interest. Right?


If you want to detect missing 'static',
have you tried 'sparse'?



> Thanks,
> Jake



-- 
Best Regards
Masahiro Yamada