Skip to content

RDKB-67307 - rbus-wanmanger deadlock fix - #234

Open
dhaneesh663 wants to merge 1 commit into
rdkcentral:mainfrom
dhaneesh663:main
Open

dhaneesh663 wants to merge 1 commit into
rdkcentral:mainfrom
dhaneesh663:main

Conversation

@dhaneesh663

Copy link
Copy Markdown

RDKB-67307 [MAP-T][COX]MAP-T Device Transitions to Dual-Stack Following DHCPv6 Renewal fix: Implementing try-lock and retry for deadlock

RDKB-67307  [MAP-T][COX]MAP-T Device Transitions to Dual-Stack Following DHCPv6 Renewal
fix: Implementing trylock and retry for deadlock
@dhaneesh663
dhaneesh663 requested a review from a team as a code owner October 19, 2026 09:39
Copilot AI balanced review requested due to automatic review settings October 19, 2026 09:39

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Retry exhaustion discards connectivity updates, leaving stale status that can affect WAN failover decisions.

1 open issue
What changed in this PR

This PR addresses a WanManager/RBUS deadlock associated with MAP-T transitions after DHCPv6 renewal.

Changes:

  • Replaces blocking mutex acquisition in alias lookup with bounded try-lock retries.
  • Adds retry limits, delays, and a warning on exhaustion.
File Description
source/​WanManager/​wanmgr_data.c Adds bounded mutex retries to virtual-interface alias lookup.

Review effort: Balanced

{
CcspTraceWarning(("%s %d: gDataMutex busy after %d retries, skipping (Alias=%s)\n",
__FUNCTION__, __LINE__, attempts, Alias));
return NULL;
{
if (++attempts >= GDATAMUTEX_TRYLOCK_MAX_RETRIES)
{
CcspTraceWarning(("%s %d: gDataMutex busy after %d retries, skipping (Alias=%s)\n",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOG ERROR

#include "wanmgr_dslite.h"
#endif

#define GDATAMUTEX_TRYLOCK_MAX_RETRIES 80

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This values need to be tested. We need to take RBUS timeout in consideration.

#endif

#define GDATAMUTEX_TRYLOCK_MAX_RETRIES 80
#define GDATAMUTEX_TRYLOCK_RETRY_DELAY_US 50000

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4 seconds may not be enough, it is possible other process hold mutex more than 4 seconds.

Comment thread source/WanManager/wanmgr_data.c
int lockRc;

if(pthread_mutex_lock(&gWanMgrDataBase.gDataMutex) == 0)
while ((lockRc = pthread_mutex_trylock(&gWanMgrDataBase.gDataMutex)) == EBUSY)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to check how this lock failure may affect the events

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants