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.
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>
13a3dbb to
0749fcc
Compare
3 participants
No description provided.