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]
Date:	Wed, 04 Dec 2013 10:15:52 -0500
From:	Prarit Bhargava <prarit@...hat.com>
To:	"Yu, Fenghua" <fenghua.yu@...el.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH] x86: Add check for number of available vectors before
 CPU down



On 12/03/2013 06:42 PM, Yu, Fenghua wrote:
> 
> 
>> -----Original Message-----
>> From: Prarit Bhargava [mailto:prarit@...hat.com]
>>
>> Second try at this ...
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791
>>
>> When a cpu is downed on a system, the irqs on the cpu are assigned to
>> other cpus.  It is possible, however, that when a cpu is downed there
>> aren't enough free vectors on the remaining cpus to account for the
>> vectors from the cpu that is being downed.
>>
>> This results in an interesting "overflow" condition where irqs are
>> "assigned" to a CPU but are not handled.
>>
>> For example, when downing cpus on a 1-64 logical processor system:
>>
>> +			if (per_cpu(vector_irq, cpu)[vector] < 0)
>> +				count++;
> 
> But later on fixup_irqs will set some of vector_irq vector as -1 on this
> to-be-disabled cpu. That will release vectors assigned to this cpu. So
> checking vector_irq at this point before fixup_irqs doesn't make sense, right?
> 

Fenghua, IIUC the purpose of fixup_irqs() is to migrate irqs from the
to-be-disabled cpu to other cpus by using affinity, etc..  The to-be-disabled
cpus' irqs are set to -1, however, only after they are migrated off to an
enabled cpu.

This check I'm introducing is well before that stage in effort to determine
whether or not the system has "room" for the irqs on the remaining cpus.

So I think that the check is in the right spot.  We should do it early.  I
suppose an argument could be made to do the check in fixup_irqs(), however, my
feeling is by then it is very late in the process of downing the cpu.

I noticed a subtle bug in my patch that I will send with a [v2].  I'm not taking
into account per-cpu interrupts in the check_vectors() function.

P.

> Thanks.
> 
> -Fenghua
> 
--
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