Re: [PATCH] x86, fix x86 fixup_irqs() error handling

[Prarit Bhargava]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/