mm: Add mm_lock_irq, mm_unlock_iq

[W-M-R]

Note: Please adhere to Contributing Guidelines.

Summary

mm: Add mm_lock_irq, mm_unlock_iq

Impact

Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.

Testing

Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.

[nuttxpr]

[Experimental Bot, please feedback here]

This PR does not fully meet the NuttX requirements as presented. While it provides a summary of the changes (addition of mm_lock_irq and mm_unlock_irq), it completely omits the crucial details requested in the template.

Here's a breakdown of what's missing:

• Summary: Lacks essential information:

  • Why are these functions necessary? What problem do they solve? Is this a fix, update, or new feature?
  • What part of the code is affected? (e.g., memory manager, scheduler, specific driver).
  • How exactly do they work? What changes in behavior will result from their addition? What do they lock/unlock specifically?
  • Related issue references: Are there any related issues in either the NuttX or NuttX-apps repositories?

• Impact: The section is placeholder text. It needs to address all the listed points:

  • Is this a new feature?
  • Will users need to adapt their code?
  • Does the build process change (e.g., new Kconfig options)?
  • Are any architectures, boards, or drivers affected?
  • Is documentation required?
  • Are there security implications (e.g., preventing race conditions)?
  • Are there backward/forward compatibility issues?
  • Any other considerations?

• Testing: This section also has placeholder text. It must include:

  • Build Host details: OS, CPU architecture, compiler (including version)
  • Target details: Architecture (simulator, real hardware), board and configuration
  • Testing Logs: "Before" and "after" logs demonstrating the change's effect (or lack thereof, if intended). These logs are crucial for reviewers to understand the change's impact and verify its correctness.

In short, the PR needs to be significantly expanded to provide the necessary context and evidence to support the proposed changes. Without this information, reviewers cannot effectively evaluate the PR.