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: <4F4D7BF9.9070104@jp.fujitsu.com>
Date:	Wed, 29 Feb 2012 10:14:33 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Tony Luck <tony.luck@...el.com>, Ingo Molnar <mingo@...e.hu>,
	EDAC devel <linux-edac@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <borislav.petkov@....com>
Subject: Re: [PATCH 1/3] mce: Add a msg string to the MCE tracepoint

(2012/02/29 1:11), Borislav Petkov wrote:
> From: Borislav Petkov <borislav.petkov@....com>
> 
> The idea here is to pass an additional decoded MCE message through
> the tracepoint and into the ring buffer for userspace to consume. The
> designated consumers are RAS daemons and other tools collecting RAS
> information.

I could not catch the point... Why you need this msg field?

I think that all of information about the error is already packed in
the record and that we can make a string from the bits in the record
soon afterward.  From my point of view it seems that what you are
doing here is just consuming the ring buffer by repeating same
contents in another format with dynamic length which might be short
but otherwise could be too long.

And one more unacceptable point is that filling this msg field is
expected to be done in machine check context where have many
limitations in kernel's subsystems such as use of memory allocators.

Suggestion; How about having a kind of translator function for
userland, e.g. an exported function named mce_record_to_msg()?
Tool obtains raw data from the record in the tracepoint's ring buffer,
and if it likes, optionally it can pass the record to the translator
function to get some accomplished string.

> 
> Drop unneeded fields while at it, thus saving some room in the ring
> buffer.

Really unneeded and should be killed? 


Thanks,
H.Seto

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