Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further critical section issues #6427

Closed
6 tasks done
devyte opened this issue Aug 19, 2019 · 1 comment
Closed
6 tasks done

Further critical section issues #6427

devyte opened this issue Aug 19, 2019 · 1 comment
Assignees
Milestone

Comments

@devyte
Copy link
Collaborator

devyte commented Aug 19, 2019

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • If there is a stack dump, I have decoded it.
  • I have filled out all fields below.

Platform

All

Settings in IDE

All

Problem Description

With #6274, and related PRs, several major flaws in interrupt locking were addressed in our core code, especially in umm malloc (configured defines for critical sections). In essence, ets_intr_{un}lock() were found to not allow nesting of interrupt critical sections, which would lead to instability.
The core code was fixed, but the SDK and ROM code is still pending.

The SDK closed source libs must be searched for calls to ets_intr_{un}lock() as well as the asm instruction(s) that dis/enable interrupts. Libs that contain such calls must be patched to call a function in our core instead.

The ROM must be reverse engineered enough to build a calling tree of every ROM function that calls ets_intr{un}lock(), and work upwards through all functions that call that function, and so on. Then, the SDK closed libs (and possibly our core) must be patched by adding fixed versions of the ROM functions, and then have the SDK libs (and possibly our core) call those functions instead of the ROM ones.

The above is, of course, a top level view of what must be done. It's entirely possible that some linker magic could make things somewhat easier.

@devyte devyte added this to the 2.6.0 milestone Sep 13, 2019
@devyte devyte self-assigned this Sep 13, 2019
@devyte
Copy link
Collaborator Author

devyte commented Sep 13, 2019

Closed via #6484.
Ref: #2330.

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

No branches or pull requests

1 participant