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]

Date:	Thu, 31 May 2012 15:32:52 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Borislav Petkov <bp@...64.org>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	"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>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] RAS: Add a tracepoint for reporting memory controller
 events

On Thu, 2012-05-31 at 19:13 +0200, Borislav Petkov wrote:

> > 	- No other userspace API provides it;
> 
> Yes, it should.
> 
> > 	- The granularity is a property of the per-error address;
> 
> Not necessarily, as it is shown above.
> 
> > 	- There are well-known cases where the address grain changes are
> > 	  dynamically filled by the error registers (MCA arch on Intel).
> 
> Ok.
> 
> > So, the memory error tracepoint is the proper place to store it, as it is
> > the place where the address and the other memory error information is
> > reported to userspace.
> 
> Yes, but not as a separate field but in driver_detail _only_ on those
> drivers where grain is dynamic. The remaining ones simply don't output
> it all because they have done so in dmesg or sysfs.
> 
> > Also, converting the grain to a string, as you proposed would require
> > at least 26 bytes to store "grain: 0xdeadbeef:deadbeef", while putting
> > it as a u64 will consume only 8 bytes.
> 
> 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. Their
> tracepoint records shouldn't be inflated for no reason.

Just so I understand your point. You are saying things like grain that
don't change but are different per device, should just be in some sysfs
file somewhere, and things that are dynamic during runtime should go
into the tracepoint.

Correct?

-- Steve



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