linux-kernel - RE: [PATCH v3] aerdrv: Move cper_print_aer() call out of interrupt context

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: <A961433CDFF2F640A2866803152E61F95D13A762@G9W0715.americas.hpqcorp.net>
Date:	Thu, 30 May 2013 14:04:42 +0000
From:	"Ortiz, Lance E" <lance.oritz@...com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Borislav Petkov <bp@...en8.de>
CC:	"Luck, Tony" <tony.luck@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"lance_ortiz@...mail.com" <lance_ortiz@...mail.com>,
	"jiang.liu@...wei.com" <jiang.liu@...wei.com>,
	"mchehab@...hat.com" <mchehab@...hat.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3] aerdrv: Move cper_print_aer() call out of interrupt
 context

> >
> > Sounds to me, this TODO item should be on your TODO list - not in
> kernel
> > sources :-)
> >
> 
> Also, that TODO sounds like there's output to userspace that can be
> parsed by a userspace tool. If a tool expects the current format, it
> may
> not be acceptable to change it later.
> 
> If the contents of this patch has nothing to do with the TODO, then
> leave it out. It just confuses things.

Steve, you do have a good point here.  I am wondering if that is why we should consider changing the output to match aer_print_error().  The code path to aer_print_error() is the more common path where not as many platforms support the cper_print_error() path (firmware first AER).  So it is more likely that any tools written would know how to parse the output from aer_print_error().  It would be good for those tools to support firmware first AER when it becomes more common.  Of course this is purely conjecture.  I have no idea if there are any tools that parse this text output.

Lance