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

clock_timekeeping: remove enter_critical_section in sched/clock/clock_timekeeping.c #15136

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hujun260
Copy link
Contributor

Summary

clock_timekeeping: remove enter_critical_section in sched/clock/clock_timekeeping.c
reason:
We would like to replace the critical section with a small lock.

Impact

clock_timekeeping

Testing

ci

…_timekeeping.c

reason:
We would like to replace the critical section with a small lock.

Signed-off-by: hujun5 <[email protected]>
@hujun260 hujun260 changed the title clock_timekeeping: remove enter_critical_section in sched/clock/clock… clock_timekeeping: remove enter_critical_section in sched/clock/clock_timekeeping.c Dec 11, 2024
@github-actions github-actions bot added Area: OS Components OS Components issues Size: S The size of the change in this PR is small labels Dec 11, 2024
@nuttxpr
Copy link

nuttxpr commented Dec 11, 2024

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides a summary and mentions testing, it lacks crucial details.

Here's what's missing:

  • Summary: Needs more detail. Why do you want to replace the critical section with a lock? What problem does this solve? What specific changes are being made (e.g., "Replacing enter_critical_section() and leave_critical_section() with calls to nxmutex_take() and nxmutex_give() on a newly introduced mutex")?
  • Impact: The current entry is insufficient. Address all the impact points with "YES" or "NO" and provide descriptions where necessary. Consider:
    • Impact on user: Likely no, but explain why.
    • Impact on build: Possibly no, but state explicitly.
    • Impact on hardware: Probably no, but state explicitly.
    • Impact on documentation: If no documentation changes are needed, state that explicitly.
    • Impact on security: Does using a mutex instead of a critical section have any security implications? (e.g., priority inversion).
    • Impact on compatibility: Are there any backward compatibility concerns?
  • Testing: "ci" is not sufficient. Provide specific details about the build host (OS, CPU architecture, compiler) and the target platform (architecture, board, configuration). Include actual testing logs demonstrating the issue before the change and the improved behavior after the change. Just saying "works as intended" is not enough; show evidence.

The PR needs to be significantly expanded to meet the requirements. Provide the missing information to ensure a thorough review.

@@ -72,7 +73,7 @@ static int clock_get_current_time(FAR struct timespec *ts,
time_t sec;
int ret;

flags = enter_critical_section();
flags = spin_lock_irqsave(&g_clock_lock);

ret = up_timer_gettick(&counter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ret = up_timer_gettick(&counter);
ret = up_timer_gettick(&counter); <---

same issue with #15129, how to protect lower half data

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there is no clear specification that requires up_timer_gettick to be called within a critical_section. Currently, there are numerous calls to up_timer_gettick that are not within a critical section. For example, clock_systime_ticks calls up_timer_gettick, but clock_systime_ticks itself is not within a critical_section in many places.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key issue is that the scope of impact of your code before and after modification is different. You cannot guarantee that the modification will not bring side effects within the visible range. If you insist on making changes, please ignore my comments,I will not spend time reviewing similar submissions in the future.

@@ -292,6 +296,7 @@ void clock_inittimekeeping(FAR const struct timespec *tp)
}

up_timer_gettick(&g_clock_last_counter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: OS Components OS Components issues Size: S The size of the change in this PR is small
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants