Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add comment clarifying proper use of fs_scratch (facebook#13189)
Summary: facebook#13182 seems to have resolved the `heap-use-after-free` / `heap-buffer-overflow` issues, but not for the reasons we had in mind. I believe I have figured out the root cause after doing more thinking / reading into the warm storage code. **`fs_scratch` cannot be assumed to point to the start of the data buffer. It must be treated as a pointer to any arbitrary object / data structure. As such, we must rely only on result.data().** I think that part of the reason for the bug was that the comment for `fs_scratch` was > fs_scratch is a data buffer allocated and provided by underlying FileSystem which is _extremely misleading_. To avoid confusion in the future, I have updated the comments related to `FsReadRequest` with some of my learnings and included `WARNING`s in all caps to hopefully steer future engineers aware from the same issue. In another PR, I will update some of our mock file system test classes that support `FSSupportedOps::kFSBuffer`. The test class implementation also contributed to my confusion, since `fs_scratch` did point to the start of the valid data in those implementations. This cannot and should not be assumed to be true in general, and we should try to guard against potential future bugs by updating those mock implementations. Pull Request resolved: facebook#13189 Test Plan: These are just comments. Reviewed By: anand1976, hx235 Differential Revision: D66849436 Pulled By: archang19 fbshipit-source-id: c264007647af9cc2a4dfd58dbe7287af86fa2261
- Loading branch information