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

Remove O_DIRECT from basic_read_test #114

Merged
merged 1 commit into from
Feb 24, 2023
Merged

Remove O_DIRECT from basic_read_test #114

merged 1 commit into from
Feb 24, 2023

Conversation

jamesbornholt
Copy link
Member

This test is failing sporadically in CI with corrupt data. I believe the cause is the same as why we reverted #84. Per the man page for open(2), O_DIRECT is not safe to use concurrently with fork syscalls:

O_DIRECT I/Os should never be run concurrently with the fork(2)
system call, if the memory buffer is a private mapping (i.e., any
mapping created with the mmap(2) MAP_PRIVATE flag; this includes
memory allocated on the heap and statically allocated buffers).
Any such I/Os, whether submitted via an asynchronous I/O
interface or from another thread in the process, should be
completed before fork(2) is called. Failure to do so can result
in data corruption and undefined behavior in parent and child
processes.

Our test runner does a fork every time we mount a FUSE file system, since we don't run our tests as root, and so we need to execute the fusermount3 utility to do the mount. Since tests run concurrently, that means we will sometimes do one of these forks at the same time as this test is doing an O_DIRECT read.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

This test is failing sporadically in CI with corrupt data. I believe the
cause is the same as #84. Per the man page for `open(2)`, `O_DIRECT` is
not safe to use concurrently with `fork` syscalls:

> O_DIRECT I/Os should never be run concurrently with the fork(2)
> system call, if the memory buffer is a private mapping (i.e., any
> mapping created with the mmap(2) MAP_PRIVATE flag; this includes
> memory allocated on the heap and statically allocated buffers).
> Any such I/Os, whether submitted via an asynchronous I/O
> interface or from another thread in the process, should be
> completed before fork(2) is called.  Failure to do so can result
> in data corruption and undefined behavior in parent and child
> processes.

Our test runner does a `fork` every time we mount a FUSE file system,
since we don't run our tests as root, and so we need to execute the
`fusermount3` utility to do the mount. Since tests run concurrently,
that means we will sometimes do one of these forks at the same time as
this test is doing an `O_DIRECT` read.

Signed-off-by: James Bornholt <bornholt@cs.utexas.edu>
Copy link
Contributor

@dannycjones dannycjones left a comment

Choose a reason for hiding this comment

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

LGTM.

Looks like it will close #107?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants