Replies: 2 comments 1 reply
-
To me it seems we should add lock to |
Beta Was this translation helpful? Give feedback.
0 replies
-
See #64922 (comment) |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have a per-interface lock
net_if_lock/unlock
which synchronizes all transmissions on that interface amongst themselves and also with control path e.g,net_if_enable(true/false)
, but the locking itself inconsistent, few APIs take lock but few directly invoke TX. (Focusing on TX for now).This can cause issues with de-initialization path (deinit is seldom used, so, probably disable/stopping the interface), and we do see an occasional crash after a few hours of interface disconnect and connect tests, I don't have a specific test case to exemplify the issue, so, analysis based on code walkthrough. Below is a call trace that I did and only see
net_if_send_data
taking the lock. Even the docs are unclear about the locking requirements.We should document the locking requirements and fix the inconsistent locking. Below patch fixes by making the
net_if_tx
as the entry point and it takes the lock, I have only done basic tests, but as this is critical raising an RFC than the patch.Beta Was this translation helpful? Give feedback.
All reactions