netdev - Re: [PATCH V3 net-next 1/8] net: ena: avoid unnecessary rearming of interrupt vector when busy-polling

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] [day] [month] [year] [list]

Date:   Fri, 17 Jul 2020 20:28:18 +0000
From:   "Bshara, Nafea" <nafea@...zon.com>
To:     David Miller <davem@...emloft.net>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "Machulsky, Zorik" <zorik@...zon.com>,
        "Matushevsky, Alexander" <matua@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "Wilson, Matt" <msw@...zon.com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        "Tzalik, Guy" <gtzalik@...zon.com>,
        "Belgazal, Netanel" <netanel@...zon.com>,
        "Saidi, Ali" <alisaidi@...zon.com>,
        "Herrenschmidt, Benjamin" <benh@...zon.com>,
        "Dagan, Noam" <ndagan@...zon.com>,
        "Agroskin, Shay" <shayagr@...zon.com>,
        "Jubran, Samih" <sameehj@...zon.com>,
        "eric.dumazet@...il.com" <eric.dumazet@...il.com>
Subject: Re: [PATCH V3 net-next 1/8] net: ena: avoid unnecessary rearming of
 interrupt vector when busy-polling



On 7/17/20, 12:53 PM, "David Miller" <davem@...emloft.net> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    From: <akiyano@...zon.com>
    Date: Thu, 16 Jul 2020 21:10:03 +0300

    > To the best of my knowledge this assumption holds for ARM64 and x86_64
    > architecture which use a MESI like cache coherency model.

    Use the well defined kernel memory model correctly please.

    This is no place for architectural assumptions.  The memory model of
    the kernel defines the rules, and in what locations various memory
    barriers are required for correct operation.

    Thank you.

True and we will add smp_rmb()
And I wouldn’t worry about the perf hit here, both x86 and modern arm v8 (specifically the Graviton2 that uses ENA) are pretty efficient and close enough to no-op