linux-kernel - Re: [PATCH] RAS: Add a tracepoint for reporting memory controller events

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: <20120531193739.GB16998@aftab.osrc.amd.com>
Date:	Thu, 31 May 2012 21:37:39 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aristeu Rozanski <arozansk@...hat.com>,
	Doug Thompson <norsk5@...oo.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] RAS: Add a tracepoint for reporting memory controller
 events

On Thu, May 31, 2012 at 03:04:55PM -0300, Mauro Carvalho Chehab wrote:
> The tracepoint approach is proposed as a way to replace dmesg, so,
> dmesg is not an option.

Of course it is an option: userspace parses dmesg and gets grain value.

> Sysfs nodes for address grain won't work, as, on MCA, the grain is
> only known when an error is generated, and it is valid only together
> with an error report.

This is only true on Intel.

> Having the _same_ field exported either in sysfs or via the trace,
> depending if the grain is dynamic or if it is global-wide is a very
> crappy API, as the same information would be provided to userspace via
> different API's, with is insane.

No, what is crappy is "punishing" other drivers just because you need
grain for your drivers.

Ask Steven how expensive are 4 bytes in a tracepoint and what it means
wasting space in the ring buffer.

[ … ]

> > Again, only on those drivers which have dynamic grain. Other drivers
> > which keep outputting 'x' (and 'x' doesn't change) on every tracepoint
> > invocation don't need to output it all in the tracepoint.
> 
> So what? If only one type of granularity applies to all addresses, the
> information provided to userspace won't be wrong.

The argument is not whether it is wrong or not - it is about wasting
space unnecessarily where it counts. Write this down and hammer it to
your forehead so that you can finally understand it!

<remove some random unrelated blubber>

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/