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

fix: directIO read size can exceeds buffer size #68

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

shuoranliu
Copy link

Since the package uses a fixed-size memory pool for out messages,
it is important to tell fuse kernel module what the maximum read size is.
Otherwise, a large read will cause a panic.

Right now, max readahead size can only affect buffered read. The kernel
might still send a large directIO read in spite of the max readahead size.
We need to specify "max_read" option during mount.

Signed-off-by: Shuoran Liu [email protected]

Copy link
Collaborator

@stapelberg stapelberg left a comment

Choose a reason for hiding this comment

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

Thanks for your PR!

Out of curiosity, can you elaborate on in which situation you encountered a panic?

@@ -29,6 +32,8 @@ func fusermount(dir string, cfg *MountConfig) (*os.File, error) {
// Start fusermount, passing it a buffer in which to write stderr.
var stderr bytes.Buffer

cfg.Options["max_read"] = strconv.Itoa(buffer.MaxReadSize)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you’ll need to ensure cfg.Options is non-nil here, see the travis test failure.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks, I've made a modification. To reproduce the issue, just try to invoke a read system call with the size of 512Kbytes which is larger than MaxReadSize, and with O_DIRECT flag.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for fixing this! Would it be possible to add a unit test, too, which exercises this behavior? It should fail before your fix commit, and pass afterwards, so that we don’t accidentally re-introduce this bug at some point down the road.

Copy link
Author

Choose a reason for hiding this comment

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

Is there a guide on how to write ci test cases? I believe it is better to write a test case from user space file system. BTW, I have no idea why ci failed again.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not sure I understand your question—there are no “ci test cases”, the CI just runs the go tests of this project :)

This particular failure might have been a flake (sometimes the CI is overloaded), so I have restarted the run.

Since the package uses a fixed-size memory pool for out messages,
it is important to tell fuse kernel module what the maximum read size is.
Otherwise, a large read will cause a panic.

Right now, max readahead size can only affect buffered read. The kernel
might still send a large directIO read in spite of the max readahead size.
We need to specify "max_read" option during mount.

Signed-off-by: Shuoran Liu <[email protected]>
@shuoranliu shuoranliu force-pushed the fix-max-read-size-may-exceeds-buffer branch from 01da9b6 to 1f74c2f Compare October 21, 2019 07:35
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.

2 participants