dax: fix race condition on the tuning buffer - #11056
Conversation
It is necessary cause p_dax is used in dax.c now. Signed-off-by: Jun Lai <jun.lai@dolby.com>
|
Can one of the admins verify this patch?
|
| size); | ||
| if (adapter_data->tmp_tuning_buf.addr && adapter_data->tmp_tuning_buf.size > 0) { | ||
| dax_buffer_release(mod, &dax_ctx->tuning_file_buffer); | ||
| dax_ctx->tuning_file_buffer = adapter_data->tmp_tuning_buf; |
There was a problem hiding this comment.
not sure how this fixes the race... dax_buffer_release() in line 253 itself is racy - it frees directly the dax_buff->addr pointer and only then assigns NULL to it, so there's a use-after-free potential there. Also here line 254 isn't atomic - it's still the same old memcpy(), so, not very clear to me how this commit fixes any racing issues?
There was a problem hiding this comment.
Uha, my bad, I miss some changes. A spinlock is added to protect access to set_tuning_file.
set_tuning_file now works in process thread which has lower thread priority than set configuration, hence I dont add a spinlock in dax_set_param_wrapper.
for dax_buffer_release(), use-after-free will not happen because tuning buffer is only used in process thread through dax_find_params interface. They are always in the same thread.
13a3dbb to
0749fcc
Compare
While the tuning buffer is being updated, it may also be being used simultaneously in the process thread. Signed-off-by: Jun Lai <jun.lai@dolby.com>
0749fcc to
95f5201
Compare
3 participants
No description provided.