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: <CA+55aFwgyjqRHxLaWGxxsg_v07FrxbVTeLdHTGp7MfeSRjrKsQ@mail.gmail.com>
Date:	Thu, 12 Sep 2013 11:03:53 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] perf fixes

On Thu, Sep 12, 2013 at 6:38 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> Various fixes. (The -g perf report lockup you reported is only partially
> addressed, patches that fix the excessive runtime are still being worked
> on.)

So I pulled this and compiled a new version, and I have a new
complaint. The _bug_ probably is not new, but it happened because I
was compiling the tools/perf/ subdirectory while another terminal was
busy doing a "make allmodconfig" test build (hey, sue me, I do a lot
of them during the merge window).

When I compiled "perf" at the same time as doing a big kernel compile,
the kernel compile failed! I got a few odd "No such file or directory"
for temporary object files in the kernel build. That's not nice. Why
does "make" in the perf tools mess up a "make" of the main kernel?
That implies that the perf tools aren't really independent, and they
try to make at least part of the top-level build. Very annoying.

Another annoyance during that make was that "make install" seems to
want to re-make the thing I just built. That's absolutely horrible,
even if I've seen too many broken projects do that. Now, for perf it's
not as horrible as for some (because you can do "make install" as a
normal user), but it's still a pattern that needs to be called out and
needs to die. It's not just that it slows down "make install", it's
also that a normal pattern *should* be that you build things as a
normal user, and do "make install" as root.

            Linus
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ