sched/sem_rw: convert read-lock to write-lock when self already holds write-lock

[Donny9]

Summary

1. sched/sem_rw: convert read-lock to write-lock when self already holds write-lock
2. fs/inode: using read-lock to protect inode_find

The PR is releated to #13736 (comment), to fix issue about:

In some scenarios, inode_find and inode_remove are used in combination, such as in shm_open and shm_unlink. The remove operation requires a write lock. If we were to switch to a read lock in inode_find, then a lock would need to be added in inode_remove, and additional checks would be required elsewhere.

Impact

convert read-lock to write-lock when self already holds write-lock

Testing

Local test

[nuttxpr]

[Experimental Bot, please feedback here]

The PR summary partially meets the requirements, but is missing some key information:

What's Missing in Summary:

• Why is the change necessary? The summary mentions a related discussion, but doesn't explicitly state the problem the PR solves. It should clearly articulate the bug or improvement this PR addresses.
• How does the change exactly work? The summary provides a high-level description but lacks specifics. Explain the mechanism used to convert read-locks to write-locks and how using a read-lock in inode_find addresses the original issue.

Impact Section is Insufficient:

• The current impact section is overly brief. It only mentions "convert read-lock to write-lock" which duplicates information from the summary.
• Address ALL Impact Points: Go through each impact category listed in the requirements (user impact, build impact, hardware impact, etc.) and specify "NO" or provide details if applicable. For example, this change seems likely to impact compatibility, so explain the backward/forward compatibility implications.

Testing Section is Inadequate:

• Insufficient Detail: "Local test" is too vague. Specify the host OS, CPU architecture, compiler, target architecture, board configuration, and any specific test cases used.
• Missing Logs: The template asks for "Testing logs before change" and "Testing logs after change". Provide relevant snippets from your test runs demonstrating the problem before the PR and the successful outcome after.

In summary, while the PR addresses a specific issue, the provided description lacks the necessary detail and completeness expected in a NuttX PR. Expand the summary, thoroughly address all impact points, and provide specific details and logs for the testing section.

[acassis]

@Donny9 please include the Summary content in the commit log message

[Donny9]

@Donny9 please include the Summary content in the commit log message

Done~