netdev - Re: [PATCH net-next 0/6] sfc: rework locking around filter management

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: <20180327.133415.1695812033939717097.davem@davemloft.net>
Date:   Tue, 27 Mar 2018 13:34:15 -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 net-next 0/6] sfc: rework locking around filter
 management

From: Edward Cree <ecree@...arflare.com>
Date: Tue, 27 Mar 2018 17:40:11 +0100

> The use of a spinlock to protect filter state combined with the need for a
>  sleeping operation (MCDI) to apply that state to the NIC (on EF10) led to
>  unfixable race conditions, around the handling of filter restoration after
>  an MC reboot.
> So, this patch series removes the requirement to be able to modify the SW
>  filter table from atomic context, by using a workqueue to request
>  asynchronous filter operations (which are needed for ARFS).  Then, the
>  filter table locks are changed to mutexes, replacing the dance of spinlocks
>  and 'busy' flags.  Also, a mutex is added to protect the RSS context state,
>  since otherwise a similar race is possible around restoring that after an
>  MC reboot.  While we're at it, fix a couple of other related bugs.

Series applied, thank you.