netdev - Re: [PATCH v2 net 0/3] sfc: ARFS fixes

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]

Message-Id: <20180414.154024.66743859691828503.davem@davemloft.net>
Date:   Sat, 14 Apr 2018 15:40:24 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     ecree@...arflare.com
Cc:     linux-net-drivers@...arflare.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2 net 0/3] sfc: ARFS fixes

From: Edward Cree <ecree@...arflare.com>
Date: Fri, 13 Apr 2018 19:16:20 +0100

> Three issues introduced by my recent asynchronous filter handling changes:
> 1. The old filter_rfs_insert would replace a matching filter of equal
>    priority; we need to pass the appropriate argument to filter_insert to
>    make it do the same.
> 2. We're lying to the kernel with our return value from ndo_rx_flow_steer,
>    so we need to lie consistently when calling rps_may_expire_flow.  This
>    is only a partial fix, as the lie still prevents us from steering
>    multiple flows with the same ID to different queues; a proper fix that
>    stops us lying at all will hopefully follow later.
> 3. It's possible to cause the kernel to hammer ndo_rx_flow_steer very
>    hard, so make sure we don't build up too huge a backlog of workitems.
> 
> Possibly it would be better to fix #3 on the kernel side; I have a patch
>  which I think does that but it's not a regression in 4.17 so isn't 'net'
>  material.
> There's also the issue that we come up in the bad configuration that
>  triggers #3 by default, but that too is a problem for another time.

Series applied, thanks Edward.