mm/map: Remove MM_MAP_COUNT_MAX Kconfig and related check

[xiaoxiang781216]

Summary

since it's not necessary to limit the number of map entries.

Impact

remove the artificial limitation

Testing

ci

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not meet the NuttX requirements. The provided information is far too vague and lacks crucial details. Here's why:

• Summary: "since it's not necessary to limit the number of map entries" is not a sufficient explanation. What map entries? What was the limit? Why was it there in the first place? What part of the codebase was changed? What is the functional change? This section needs to clearly articulate the what and why of the change. Issue references are missing.

• Impact: "remove the artificial limitation" is similarly vague. What limitation? What are the ramifications of removing it? While it says it impacts the user, build, etc., by saying "NO", it provides no reasoning or context. For a proper assessment, consider the memory usage implications of removing this limit. Could it lead to out-of-memory errors in certain scenarios? Even if the answer to all impacts is "NO", a brief justification ("No change to user experience," for example) is preferable for clarity.

• Testing: "ci" is insufficient. "ci" presumably means Continuous Integration, but that doesn't provide any specifics. What targets were tested? What tests were run? What were the results? Crucially, there are no "before" and "after" logs demonstrating the actual change in behavior. This section requires concrete evidence that the change works as intended and doesn't introduce regressions.

In short, the PR description needs significantly more detail and concrete information to be considered acceptable. It needs to provide a clear understanding of the change, its implications, and thorough verification through testing.

[acassis]

@xiaoxiang781216 could you please elaborate further? Why isn't it necessary to limit the number of map entries? Which other alternative do we have? Please include this information in the commit message!

[xiaoxiang781216]

The implementation could support any number map if the system has enough memory, so it's an artificial limitation and better to remove to simplify the configuration.

[XuNeo]

LTP test will fail if it's removed.

[patacongo]

This could be security problem couldn't it? Any user application could cause a kernel simply by consuming memory regions.

Linux, apparently, restricts the number of regions to 65535. But this can be changed by writing to a proc file sysem entry: See https://www.ibm.com/docs/en/safer-payments/6.5?topic=settings-increasing-virtual-memory-map-size

That is a better solution than a configuration setting, but functionally very similar. This option should only be available to privileged applications.

[patacongo]

Linux, apparently, restricts the number of regions to 65535. But this can be changed by writing to a proc file sysem entry: See https://www.ibm.com/docs/en/safer-payments/6.5?topic=settings-increasing-virtual-memory-map-size

POSIX permits implementation-specific limits on the number of memory regions, but does not require them. For example for mmap(): https://pubs.opengroup.org/onlinepubs/9799919799/functions/mmap.html