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
| ||
|
Date: Mon, 29 Nov 2010 19:07:00 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: Huang Ying <ying.huang@...el.com> Cc: Len Brown <lenb@...nel.org>, linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>, Tony Luck <tony.luck@...el.com>, linux-acpi@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...e.hu> Subject: Re: [PATCH -v2 3/3] ACPI, APEI, report GHES error information via printk On Tue, 30 Nov 2010 10:51:41 +0800 Huang Ying <ying.huang@...el.com> wrote: > printk is one of the methods to report hardware errors to user space. > This patch implements hardware error reporting for GHES via printk. > > Signed-off-by: Huang Ying <ying.huang@...el.com> > --- > drivers/acpi/apei/ghes.c | 21 +++++++++++++++++---- > 1 file changed, 17 insertions(+), 4 deletions(-) > > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -255,11 +255,23 @@ static void ghes_do_proc(struct ghes *gh > } > #endif > } > +} > > - if (!processed && printk_ratelimit()) > - pr_warning(GHES_PFX > - "Unknown error record from generic hardware error source: %d\n", > - ghes->generic->header.source_id); > +static void ghes_print_estatus(const char *pfx, struct ghes *ghes) > +{ > + if (pfx == NULL) { > + if (ghes_severity(ghes->estatus->error_severity) <= > + GHES_SEV_CORRECTED) > + pfx = KERN_WARNING HW_ERR; > + else > + pfx = KERN_ERR HW_ERR; > + } > + if (printk_ratelimit()) { > + printk( > + "%s""Hardware error from APEI Generic Hardware Error Source: %d\n", > + pfx, ghes->generic->header.source_id); > + apei_estatus_print(pfx, ghes->estatus); That code layout is just ghastly. Please, if it can't be done nicely in 80-cols then simply exceed the 80 cols. And please don't use (or retain) printk_ratelimit(). It was a mistake. A printk_ratelimt() site shares state with all other printk_ratelimit() states, so if a random firewire driver is doing a lot of printk_ratelimit() calls, your messages get suppressed! Use printk_ratelimited() or __ratelimit(). > > ... > -- 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