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
| ||
|
Message-ID: <5317ABD5.80908@redhat.com> Date: Wed, 05 Mar 2014 17:57:25 -0500 From: Prarit Bhargava <prarit@...hat.com> To: David Rientjes <rientjes@...gle.com> CC: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, Rui Wang <rui.y.wang@...el.com>, Liu Ping Fan <kernelfans@...il.com>, Bjorn Helgaas <bhelgaas@...gle.com>, Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>, Lv Zheng <lv.zheng@...el.com>, Seiji Aguchi <seiji.aguchi@....com>, Yang Zhang <yang.z.zhang@...el.com>, Andi Kleen <ak@...ux.intel.com>, "Steven Rostedt (Red Hat)" <rostedt@...dmis.org>, Li Fei <fei.li@...el.com>, gong.chen@...ux.intel.com Subject: Re: [PATCH] x86, fix x86 fixup_irqs() error handling On 03/05/2014 04:09 PM, David Rientjes wrote: > On Wed, 5 Mar 2014, Prarit Bhargava wrote: > >> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c >> index d99f31d..55fab61 100644 >> --- a/arch/x86/kernel/irq.c >> +++ b/arch/x86/kernel/irq.c >> @@ -351,6 +351,7 @@ void fixup_irqs(void) >> struct irq_desc *desc; >> struct irq_data *data; >> struct irq_chip *chip; >> + int ret; >> >> for_each_irq_desc(irq, desc) { >> int break_affinity = 0; >> @@ -389,8 +390,12 @@ void fixup_irqs(void) >> if (!irqd_can_move_in_process_context(data) && chip->irq_mask) >> chip->irq_mask(data); >> >> - if (chip->irq_set_affinity) >> - chip->irq_set_affinity(data, affinity, true); >> + if (chip->irq_set_affinity) { >> + ret = chip->irq_set_affinity(data, affinity, true); >> + WARN(ret == -ENOSPC, >> + "IRQ %d set affinity failed with %d. The device assigned to this IRQ is unstable.\n", >> + irq, ret); > > Should this be WARN_ON_ONCE() to avoid filling the kernel log instead? The problem is that it could hit multiple IRQs ... maybe pr_crit might be better here so we don't flood the log with an unnecessary stack trace; anyone with the source can figure out what the call path is. > > It doesn't make much sense to print out the negative return value, maybe > you meant to print -ret instead? Heh :) You're right. I'll fix that too. P. > >> + } >> else if (!(warned++)) >> set_affinity = 0; >> -- 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