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

Invalidate buffered data when bypassing the cache #80432

Merged
merged 5 commits into from
Jan 12, 2023

Conversation

adamsitnik
Copy link
Member

This PR fixes a very nasty bug reported by @yeunglee in #80344. It will require a backport to both 7.0 and 6.0

To get a better understanding of it PTAL at the test and the comments I've added.

fixes #80344

@ghost
Copy link

ghost commented Jan 10, 2023

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

This PR fixes a very nasty bug reported by @yeunglee in #80344. It will require a backport to both 7.0 and 6.0

To get a better understanding of it PTAL at the test and the comments I've added.

fixes #80344

Author: adamsitnik
Assignees: -
Labels:

area-System.IO

Milestone: -

@@ -318,6 +318,8 @@ public override ValueTask<int> ReadAsync(Memory<byte> buffer, CancellationToken
{
if (_readLen == _readPos && buffer.Length >= _bufferSize)
{
// invalidate the buffered data, otherwise certain Seek operation followed by a ReadAsync could try to re-use data from _buffer
_readPos = _readLen = 0;
Copy link
Member

Choose a reason for hiding this comment

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

This is on the ReadAsync path. Is there any similar issue on the Read path? What about in BufferedStream? Just want to make sure we've audited all similar code paths that could have a similar issue.

Copy link
Member Author

Choose a reason for hiding this comment

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

Is there any similar issue on the Read path?

There is not, and the test that I've added ensures this.

What about in BufferedStream?

This particular optimization was not ported to BufferedStream. But I can add a BufferedStream test to be 100% sure.

Just want to make sure we've audited all similar code paths that could have a similar issue.

Sure, that is a very good point. I've verified that neither Read or Write/WriteAsync suffer from same issue.

@adamsitnik
Copy link
Member Author

/backport to release/6.0

@adamsitnik
Copy link
Member Author

/backport to release/7.0

@github-actions
Copy link
Contributor

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/3894075864

@github-actions
Copy link
Contributor

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3894077772

@github-actions
Copy link
Contributor

@adamsitnik backporting to release/6.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: add a failing test
Using index info to reconstruct a base tree...
M	src/libraries/System.IO.FileSystem/tests/FileStream/ReadAsync.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.IO.FileSystem/tests/FileStream/ReadAsync.cs
Applying: fix
Applying: address code review feedback
Applying: test BufferedStream as well
error: sha1 information is lacking or useless (src/libraries/System.IO.FileSystem/tests/FileStream/ReadAsync.cs).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0004 test BufferedStream as well
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions
Copy link
Contributor

@adamsitnik an error occurred while backporting to release/6.0, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

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

Successfully merging this pull request may close these issues.

A bug in FileStream (async + buffer) since .Net 6?
2 participants