netdev - RE: [Intel-wired-lan] [PATCH net 1/2] iavf: fix temporary deadlock and failure to set MAC address

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: <BL0PR11MB3521150D2DB45BBD32A453CD8FC49@BL0PR11MB3521.namprd11.prod.outlook.com>
Date:   Thu, 19 Jan 2023 12:10:49 +0000
From:   "Romanowski, Rafal" <rafal.romanowski@...el.com>
To:     mschmidt <mschmidt@...hat.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC:     ivecera <ivecera@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Piotrowski, Patryk" <patryk.piotrowski@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH net 1/2] iavf: fix temporary deadlock
 and failure to set MAC address

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Michal Schmidt
> Sent: czwartek, 15 grudnia 2022 23:51
> To: intel-wired-lan@...ts.osuosl.org
> Cc: ivecera <ivecera@...hat.com>; netdev@...r.kernel.org; Piotrowski,
> Patryk <patryk.piotrowski@...el.com>
> Subject: [Intel-wired-lan] [PATCH net 1/2] iavf: fix temporary deadlock and
> failure to set MAC address
> 
> We are seeing an issue where setting the MAC address on iavf fails with
> EAGAIN after the 2.5s timeout expires in iavf_set_mac().
> 
> There is the following deadlock scenario:
> 
> iavf_set_mac(), holding rtnl_lock, waits on:
>   iavf_watchdog_task (within iavf_wq) to send a message to the PF,  and
>   iavf_adminq_task (within iavf_wq) to receive a response from the PF.
> In this adapter state (>=__IAVF_DOWN), these tasks do not need to take
> rtnl_lock, but iavf_wq is a global single-threaded workqueue, so they may
> get stuck waiting for another adapter's iavf_watchdog_task to run
> iavf_init_config_adapter(), which does take rtnl_lock.
> 
> The deadlock resolves itself by the timeout in iavf_set_mac(), which results
> in EAGAIN returned to userspace.
> 
> Let's break the deadlock loop by changing iavf_wq into a per-adapter
> workqueue, so that one adapter's tasks are not blocked by another's.
> 
> Fixes: 35a2443d0910 ("iavf: Add waiting for response from PF in set mac")
> Co-developed-by: Ivan Vecera <ivecera@...hat.com>
> Signed-off-by: Ivan Vecera <ivecera@...hat.com>
> Signed-off-by: Michal Schmidt <mschmidt@...hat.com>
> ---
>  drivers/net/ethernet/intel/iavf/iavf.h        |  2 +-
>  .../net/ethernet/intel/iavf/iavf_ethtool.c    | 10 +--
>  drivers/net/ethernet/intel/iavf/iavf_main.c   | 86 +++++++++----------
>  .../net/ethernet/intel/iavf/iavf_virtchnl.c   |  2 +-
>  4 files changed, 49 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> b/drivers/net/ethernet/intel/iavf/iavf.h
> index 0d1bab4ac1b0..2a9f1eeeb701 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf.h

Tested-by: Rafal Romanowski <rafal.romanowski@...el.com>