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]
Message-ID: <CAKgT0Uc7bQnQm_qZVK_XsPRTF2E0mZWofvyG40p_7fubHoFN8Q@mail.gmail.com>
Date:   Thu, 4 Jan 2018 09:51:21 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        David Miller <davem@...emloft.net>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Netdev <netdev@...r.kernel.org>,
        Neil Horman <nhorman@...hat.com>, sassmann@...hat.com,
        John Greene <jogreene@...hat.com>
Subject: Re: [net-next 12/15] i40evf: Drop i40evf_fire_sw_int as it is prone
 to races

On Thu, Jan 4, 2018 at 1:31 AM, Sergei Shtylyov
<sergei.shtylyov@...entembedded.com> wrote:
> 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

I think the change was dropped due to patches being reordered.
Basically the use of BIT(31) was in the Rx interrupt moderation
routine.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/ethernet/intel/i40evf/i40e_txrx.c?h=v4.15-rc5#n1499

Specifically that line is dropped in the patch at:
http://patchwork.ozlabs.org/patch/854014/

I think the patches were reordered an the use of that change was
dropped from the patch. I'll work with Jeff to make certain that the
comment about replacing the line is removed.

Thanks.

- Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ