You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cudf::to_arrow copies data from device to host on a stream and never synchronizes that stream before making it available to the Arrow library, which does not use the same stream. Therefore I believe there is a potential race condition.
This is an example of one of the functions in to_arrow.cpp that copies data asynchronously to the host.
The to_arrow function ultimately calls this function and others like it, but never synchronizes before returning. Therefore an application could use this function to get an Arrow array/buffer, and then access that array on the host without synchronizing the stream.
I believe currently pageable host memory is used, which would cause cudaMemcpyAsync to return only once the copy is completed. But if this is switched to pinned host memory, it will be asynchronous, and we will have a race condition.
The text was updated successfully, but these errors were encountered:
Converting libcudf to use rmm::cuda_stream_view will require a LOT of changes, so I'm splitting it into multiple PRs to ease reviewing. This is the second PR in the series. This series of PRs will
Replace usage of cudaStream_t with rmm::cuda_stream_view
Replace usage of 0 or nullptr as a stream identifier with rmm::cuda_stream_default
Ensure all APIs always order the stream parameter before the memory resource parameter. #5119
Contributes to #6645 and #5119
Depends on #6646 so this PR will look much bigger until that one is merged.
Also fixes#6706 (to_arrow and to_dlpack are not properly synchronized).
This second PR converts:
table.hpp (and source / dependencies)
column_factories.hpp (and source / dependencies)
headers in include/detail/aggregation (and source / dependencies)
include/detail/groupby/sort_helper.hpp (and source / dependencies)
include/detail/utilities/cuda.cuh (and dependencies)
binary ops
concatenate
copy_if
copy_range
fill
gather
get_value
hash groupby
quantiles
reductions
repeat
replace
reshape
round
scatter
search
sequence
sorting
stream compaction
cudf::to_arrow
copies data from device to host on a stream and never synchronizes that stream before making it available to the Arrow library, which does not use the same stream. Therefore I believe there is a potential race condition.This is an example of one of the functions in
to_arrow.cpp
that copies data asynchronously to the host.cudf/cpp/src/interop/to_arrow.cpp
Lines 39 to 58 in 3d44ed5
The
to_arrow
function ultimately calls this function and others like it, but never synchronizes before returning. Therefore an application could use this function to get an Arrow array/buffer, and then access that array on the host without synchronizing the stream.I believe currently pageable host memory is used, which would cause
cudaMemcpyAsync
to return only once the copy is completed. But if this is switched to pinned host memory, it will be asynchronous, and we will have a race condition.The text was updated successfully, but these errors were encountered: