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: Thu, 7 Sep 2017 10:57:29 +0800 From: Yu Chen <yu.c.chen@...el.com> To: Dan Williams <dan.j.williams@...el.com> Cc: Christoph Hellwig <hch@....de>, Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Rui Zhang <rui.zhang@...el.com>, LKML <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Len Brown <lenb@...nel.org>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU On Wed, Sep 06, 2017 at 10:46:17AM -0700, Dan Williams wrote: > On Tue, Sep 5, 2017 at 11:15 PM, Christoph Hellwig <hch@....de> wrote: > > On Wed, Sep 06, 2017 at 12:13:38PM +0800, Yu Chen wrote: > >> I agree, the driver could be rewritten, but it might take some time, so > >> meanwhile I'm looking at also other possible optimization. > > > > Which driver are we talking about anyway? Let's start looking at it > > and fix the issue there. > > As far as I understand, it's already fixed there: > > commit 7c9ae7f053e9e896c24fd23595ba369a5fe322e1 > Author: Carolyn Wyborny <carolyn.wyborny@...el.com> > Date: Tue Jun 20 15:16:53 2017 -0700 > > i40e: Fix for trace found with S4 state > > This patch fixes a problem found in systems when entering > S4 state. This patch fixes the problem by ensuring that > the misc vector's IRQ is disabled as well. Without this > patch a stack trace can be seen upon entering S4 state. > > However this seems like something that should be handled generically > in the irq-core especially since commit c5cb83bb337c > "genirq/cpuhotplug: Handle managed IRQs on CPU hotplug" was headed in > that direction. It's otherwise non-obvious when a driver needs to > release and re-acquire interrupts or be reworked to use managed > interrupts. Yes, thanks for the explaination! I did not notice this patch has been merged already. I'm using the normal CPU hotplug to reproduce the issue: #!/bin/bash n=1 while [ $n -le 31 ] do echo 0 > /sys/devices/system/cpu/cpu${n}/online n=$(( n+1 )) done Thanks, Yu
Powered by blists - more mailing lists