linux-kernel - Re: [PATCH] checkkconfigsymbols.py: filter reports for tools/

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] [day] [month] [year] [list]

Date:	Tue, 03 Mar 2015 23:52:07 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Valentin Rothberg <valentinrothberg@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	hengelein Stefan <stefan.hengelein@....de>,
	linux-kernel@...r.kernel.org,
	Andreas Ruprecht <rupran@...server.de>
Subject: Re: [PATCH] checkkconfigsymbols.py: filter reports for tools/

On Tue, 2015-03-03 at 08:55 +0100, Valentin Rothberg wrote:
> On Tue, Mar 3, 2015 at 1:57 AM, Paul Bolle <pebolle@...cali.nl> wrote:
> > On Wed, 2015-02-25 at 15:15 +0100, Valentin Rothberg wrote:
> > This patch was triggered by perf changes that hit next-20150225, wasn't
> > it? If so, we might want to find out why the perf people need to use
> 
> Yes, it was in next-20150225.  However, more recent changes have the
> same problem.  I fear it get's worse for us : )
> 
> > their
> >     "$(call detected,CONFIG_EXAMPLE)"
> >
> > hack. Especially because that hack is also used on existing Kconfig
> > symbols (I spotted X86, X86_64, AUDIT, and NUMA). And the usage of both
> > valid Kconfig macros and faux Kconfig macros in that hack looks odd to
> > me.
> 
> AFAIU it's independent from Kconfig / Kbuild.  The usage of Kconfig
> symbols seems completely random to me.

I think the entire "call detected" mechanism might as well use, say,
DETECTED_ for a prefix. That would solve our worries. Please have a look
at that hack, and see if I got that right. In that case we might as well
send a patch to do something like that and see if the perf developers
bark.

> Ignoring tools entirely also seems a little too much, since some tools
> are still Kconfig sensitive.    Hence, I vote to ignore only perf:
> 
> +                gitfile.startswith("tools/perf"):

My suggestion to only use "tools/perf/config/Makefile" was silly, and
you missed an opportunity to mock me.

tools/ is special. I'm unsure how to handle it. Assuming
checkkconfigsymbols.py will not be used by the "checker complains, so
patches must be sent" crowd, I suggest to do nothing. But it's your
script, so I defer to your decision.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/