linux-kernel - Re: [RFC PATCH 0/4] Persistent device name using alias name

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] [day] [month] [year] [list]

Message-ID: <4E41E68E.2030806@hitachi.com>
Date:	Wed, 10 Aug 2011 11:01:50 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Borislav Petkov <bp@...64.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Greg KH <greg@...ah.com>,
	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	jcm@...hat.com, dle-develop@...ts.sourceforge.net,
	yrl.pp-manager.tt@...achi.com, dgilbert@...erlog.com,
	stefanr@...6.in-berlin.de, hare@...e.de,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Tony Luck <tony.luck@...el.com>,
	yoshihiro.hayashi.cd@...achi.com
Subject: Re: [RFC PATCH 0/4] Persistent device name using alias name

(2011/08/04 2:16), Borislav Petkov wrote:
> On Sat, Jul 09, 2011 at 03:11:45PM +0900, Masami Hiramatsu wrote:
>> BTW, I'm also interested in that structured error events, from the long
>> term view and viewpoint of tracers :)
>
> Let me chime in a "mee too" from the HW errors perspective.

Of course, :) and I guess this may be related to Fredrdic's work.


>> I think we could expand current TRACE_EVENT macro to define those
>> error events.
>
> Concerning structure, we can use the format file in debugfs which
> currently describes the fields of a tracepoint:
>
> /sys/kernel/debug/tracing/events/../../format
>
> and expand those to generic kernel events. Userspace parses the format
> and knows exactly at what data it is looking at. Also, the idea is to
> move that events hierarchy into sysfs so it will be present on every
> system.

Yeah, that is exactly what I've thought. Current trace events
strongly depends on ftrace and perf. And both of them are not
enough for handling events as error monitoring. Maybe we have to
prepare another monitor for this purpose, because, usually,
error monitoring should be run always on the machine, separately
from (and concurrently with) performance tuning or debugging tools.

Even though, I think the trace-event macros (include/trace/events/)
are good starting point.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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/