netdev - Re: [net-next 12/15] i40evf: Drop i40evf_fire_sw

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:   Thu, 4 Jan 2018 12:31:41 +0300
From:   Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>, davem@...emloft.net
Cc:     Alexander Duyck <alexander.h.duyck@...el.com>,
        netdev@...r.kernel.org, nhorman@...hat.com, sassmann@...hat.com,
        jogreene@...hat.com
Subject: Re: [net-next 12/15] i40evf: Drop i40evf_fire_sw_int as it is prone
 to races

Hello!

On 1/4/2018 12:22 AM, Jeff Kirsher wrote:

> From: Alexander Duyck <alexander.h.duyck@...el.com>
> 
> Having the interrupts firing while we are polling causes extra overhead and
> isn't needed for most systems out there. If an interrupt is lost us
> experiencing a 2s latency spike before recovering is still not acceptable
> and masks the issue. We are better off just identifying systems that lose
> interrupts and instead enable workarounds for those systems.
> 
> To that end I am dropping the code that was strobing the interrupts as
> there is a narrow window where having them enabled can actually cause
> race issues anyway where a few stray packets might get misses if the
> interrupt is re-enabled and fires before we call napi_complete.
> 
> Also replace one line where we were using bit 31 instead of the define
> for the bit to represent masking the interrupt enable bit.

    I'm not seeing this change...

> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
> Tested-by: Andrew Bowers <andrewx.bowers@...el.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
[...]

MBR, Sergei