diff options
| author | Joel Fernandes <[email protected]> | 2025-02-13 16:47:27 +0000 |
|---|---|---|
| committer | Joel Fernandes <[email protected]> | 2025-04-08 18:55:55 +0000 |
| commit | f50ad4b73e1bdf7fb40566650fa11bcb438ad5ce (patch) | |
| tree | 14d890279de338b5f1bfdaf6da7c29da8a1036f9 /drivers/gpu/drm/amd/amdgpu/atom.c | |
| parent | rcu: Comment on the extraneous delta test on rcu_seq_done_exact() (diff) | |
| download | kernel-f50ad4b73e1bdf7fb40566650fa11bcb438ad5ce.tar.gz kernel-f50ad4b73e1bdf7fb40566650fa11bcb438ad5ce.zip | |
srcu: Use rcu_seq_done_exact() for polling API
poll_state_synchronize_srcu() uses rcu_seq_done() unlike
poll_state_synchronize_rcu() which uses rcu_seq_done_exact().
The rcu_seq_done_exact() makes more sense for polling API, as with
this API, there is a higher chance that there is a significant delay
between the get_state..() and poll_state..() calls since a cookie
can be stored and reused at a later time. During such a delay, if
the gp_seq counter progresses more than ULONG_MAX/2 distance, then
poll_state..() may return false for a long time unwantedly.
Fix by using the more accurate rcu_seq_done_exact() API which is
exactly what straight RCU's polling does.
It may make sense, as future work, to add debug code here as well, where
we compare a physical timestamp between get_state..() and poll_state()
calls and yell if significant time has past but the grace period has
still not progressed.
Reviewed-by: Neeraj Upadhyay <[email protected]>
Reviewed-by: Paul E. McKenney <[email protected]>
Reviewed-by: Kent Overstreet <[email protected]>
Cc: Kent Overstreet <[email protected]>
Signed-off-by: Joel Fernandes <[email protected]>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/atom.c')
0 files changed, 0 insertions, 0 deletions
