Skip to content

Conversation

@jukkar
Copy link
Member

@jukkar jukkar commented Mar 6, 2025

This is a backport of #86553 to v3.7. It does not have commit d5335d3 as the feature it is fixing was not present in v3.7

In order to avoid any mutex deadlocks between iface->lock and TX lock, release the interface lock before calling a function that will acquire TX lock. See previous commit for similar issue in RS timer handling. So here we create a separate list of multicast addresses that are to be rejoined when network interface comes up and then rejoin the groups without iface->lock held.

Fixes #86499

jukkar added 5 commits March 6, 2025 17:57
Add documentation for DAD start time variable as it was missing.

Signed-off-by: Jukka Rissanen <[email protected]>
Add documentation for ACD timeout variable as it was missing.

Signed-off-by: Jukka Rissanen <[email protected]>
The net_if.c:rs_timeout() is sending a new IPv6 router solicitation
message to network by calling net_if_start_rs(). That function will
then acquire iface->lock and call net_ipv6_start_rs() which will try
to send the RS message and acquire TX send lock.
During this RS send, we might receive TCP data that could try to
send an ack to peer. This will then in turn cause also TX lock
to be acquired. Depending on timing, the lock ordering between
rx thread and system workq might mix which could lead to deadlock.
Fix this issue by releasing the iface->lock before starting the
RS sending process. The net_if_start_rs() does not really need to
keep the interface lock for a long time as it is the only one sending
the RS message.

Fixes zephyrproject-rtos#86499

Signed-off-by: Jukka Rissanen <[email protected]>
In order to avoid any mutex deadlocks between iface->lock and
TX lock, release the interface lock before calling a function
that will acquire TX lock. See previous commit for similar issue
in RS timer handling.

Signed-off-by: Jukka Rissanen <[email protected]>
In order to avoid any mutex deadlocks between iface->lock and
TX lock, release the interface lock before calling a function
that will acquire TX lock. See previous commit for similar issue
in RS timer handling. So here we create a separate list of ACD
addresses that are to be started when network interface comes up
without iface->lock held.

Signed-off-by: Jukka Rissanen <[email protected]>
@jukkar jukkar added this to Backports Mar 6, 2025
@github-project-automation github-project-automation bot moved this to To do in Backports Mar 6, 2025
@jukkar jukkar added this to the v3.7.2 milestone Mar 6, 2025
@jukkar jukkar added area: Networking Backport Backport PR and backport failure issues labels Mar 6, 2025
@jukkar jukkar requested review from pdgendt and rlubos March 6, 2025 17:04
@nashif nashif merged commit 7fb377a into zephyrproject-rtos:v3.7-branch Apr 1, 2025
27 of 28 checks passed
@github-project-automation github-project-automation bot moved this from To do to Done in Backports Apr 1, 2025
@jukkar jukkar deleted the backport-86553-to-v3.7-branch branch April 2, 2025 08:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Networking Backport Backport PR and backport failure issues

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants