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: <20150226185833.GG3314@pd.tnic>
Date:	Thu, 26 Feb 2015 19:58:33 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Vikas Shivappa <vikas.shivappa@...el.com>
Cc:	Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
	linux-kernel@...r.kernel.org, matt.fleming@...el.com,
	hpa@...or.com, tglx@...utronix.de, mingo@...nel.org, tj@...nel.org,
	peterz@...radead.org, will.auld@...el.com, dave.hansen@...el.com,
	andi.kleen@...el.com, tony.luck@...el.com, kanaka.d.juvva@...el.com
Subject: Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology
 detection

On Thu, Feb 26, 2015 at 10:19:42AM -0800, Vikas Shivappa wrote:
> This would be an indication that the System support RDT. On a system with
> RDT would see a print.
> 
> intel_rdt: cbmlength: xx , CLOss:xx

Ok, so I have a capacity bitmask of length xx and yy classes of service.
And?

Are you expecting for tools or experienced users to grep dmesg to find
that information?

Uh, but what happens on a machine which has a small log buffer and which
has wrapped around and that information has been overwritten?

See what I mean?

If you really want to communicate this information to someone, you
should use more robust methods like make userspace use CPUID directly or
expose that information in sysfs if CPUID is not an option (but I can't
imagine why it wouldn't be).

This flaky message which can get overwritten and gets used only by a
small percentage of people(?) (I haven't reached the part which tells
me the use cases for that resource management yet) is purely useless in
dmesg.

Even /proc/cpuinfo, which will have "rdt" et all in there according to
the defines you're adding, would be a much better way to detect what's
supported quickly than the message.

HTH.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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