netdev - Re: [PATCH net] r8169: fix deadlock on RTL8125 in jumbo mtu mode

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

Date: Sun, 26 Nov 2023 23:03:29 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Realtek linux nic maintainers <nic_swsd@...ltek.com>,
 Jakub Kicinski <kuba@...nel.org>, David Miller <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 Ian Chen <free122448@...mail.com>
Subject: Re: [PATCH net] r8169: fix deadlock on RTL8125 in jumbo mtu mode

On 26.11.2023 21:14, Heiner Kallweit wrote:
> On 26.11.2023 19:36, Heiner Kallweit wrote:
>> The original change results in a deadlock if jumbo mtu mode is used.
>> Reason is that the phydev lock is held when rtl_reset_work() is called
>> here, and rtl_jumbo_config() calls phy_start_aneg() which also tries
>> to acquire the phydev lock. Fix this by calling rtl_reset_work()
>> asynchronously.
>>
>> Fixes: 621735f59064 ("r8169: fix rare issue with broken rx after link-down on RTL8125")
>> Reported-by: Ian Chen <free122448@...mail.com>
>> Tested-by: Ian Chen <free122448@...mail.com>
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>> ---
>>  drivers/net/ethernet/realtek/r8169_main.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>> index 0ee3579ce..e32cc3279 100644
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@ -575,6 +575,7 @@ struct rtl8169_tc_offsets {
>>  enum rtl_flag {
>>  	RTL_FLAG_TASK_ENABLED = 0,
>>  	RTL_FLAG_TASK_RESET_PENDING,
>> +	RTL_FLAG_TASK_RESET_NO_QUEUE_WAKE,
>>  	RTL_FLAG_TASK_TX_TIMEOUT,
>>  	RTL_FLAG_MAX
>>  };
>> @@ -4494,6 +4495,8 @@ static void rtl_task(struct work_struct *work)
>>  reset:
>>  		rtl_reset_work(tp);
>>  		netif_wake_queue(tp->dev);
>> +	} else if (test_and_clear_bit(RTL_FLAG_TASK_RESET_NO_QUEUE_WAKE, tp->wk.flags)) {
>> +		rtl_reset_work(tp);
>>  	}
>>  out_unlock:
>>  	rtnl_unlock();
>> @@ -4527,7 +4530,7 @@ static void r8169_phylink_handler(struct net_device *ndev)
>>  	} else {
>>  		/* In few cases rx is broken after link-down otherwise */
>>  		if (rtl_is_8125(tp))
>> -			rtl_reset_work(tp);
>> +			rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_NO_QUEUE_WAKE);
>>  		pm_runtime_idle(d);
>>  	}
>>  
> 
> I noticed there's a potential issue with my approach.
> So I have to rework this, please do not apply.
> 
The mentioned issue has an impact on patch "r8169: prevent potential deadlock
in rtl8169_close" only. The patch here can remain as it is and is ready to be
applied. Sorry for the noise.