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: <2df3e6cd-cf4d-4c22-849f-0e4e9651ff6f@gmail.com>
Date: Sun, 26 Nov 2023 21:13:54 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, David Miller <davem@...emloft.net>,
 Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
 Realtek linux nic maintainers <nic_swsd@...ltek.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net] r8169: prevent potential deadlock in rtl8169_close

On 25.11.2023 18:25, Heiner Kallweit wrote:
> ndo_stop() is RTNL-protected by net core, and the worker function takes
> RTNL as well. Therefore we will deadlock when trying to execute a
> pending work synchronously. To fix this execute any pending work
> asynchronously. This will do no harm because netif_running() is false
> in ndo_stop(), and therefore the work function is effectively a no-op.
> 
> Fixes: abe5fc42f9ce ("r8169: use RTNL to protect critical sections")
> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
> ---
>  drivers/net/ethernet/realtek/r8169_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 0aed99a20..0ee3579ce 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -4603,7 +4603,7 @@ static int rtl8169_close(struct net_device *dev)
>  	rtl8169_down(tp);
>  	rtl8169_rx_clear(tp);
>  
> -	cancel_work_sync(&tp->wk.work);
> +	cancel_work(&tp->wk.work);
>  
>  	free_irq(tp->irq, tp);
>  

I noticed there's a potential issue with my approach.
So I have to rework this, please do not apply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ