linux-kernel - Re: [tip:perf/core] perf/x86: Clean up cap_user

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]

Date:	Mon, 7 Oct 2013 19:40:37 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] perf/x86: Clean up cap_user_time* setting

On Mon, Oct 07, 2013 at 10:22:06AM -0700, H. Peter Anvin wrote:
> CONFIG_X86_TSC is a baseline control option; we shouldn't key
> functionality off of it.  It's fine to say notsc -> no tracing, but
> making it a compile-time key makes me a bit uphappy.  We cut off 386,
> but cutting of 486 at this point makes me nervous.

The thing that annoys me about notsc is that it disables usage even if
its present.

I've no problem with 486 which simply doesn't have TSC and thus
cpu_has_tsc will be false and other stuff will happen -- and I don't
think my proposition would actually change anything there.

What is completely insane is people using notsc on say a haswell chip
and expecting something sane to happen.

So I'm not proposing we remove !cap_has_tsc support; all I'm proposing
is we remove the notsc knob that avoids using the TSC on perfectly good
hardware.
--
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/