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
Uh oh!
There was an error while loading. Please reload this page.
-
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