deepseek-ai/3FS
1
0
Fork 0
mirror of https://github.com/deepseek-ai/3FS.git synced 2026-11-05 00:47:47 +00:00
Code Issues 166 Projects Packages Wiki Activity

[GH-ISSUE #384] [SAFETY] Memory safety consideration in update_chunk() #225

New issue
Closed
opened 2026-10-26 09:47:23 +00:00 by bsakaguchi · 1 comment
bsakaguchi commented 2026-10-26 09:47:23 +00:00
Owner
Copy link

Originally created by @red1239109-cmd on GitHub (Jan 20, 2026).
Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/384

Originally assigned to: @SF-Zhou, @Copilot on GitHub.

[SAFETY] Memory safety consideration in update_chunk()

Hi team,

I was studying the Engine module to understand its architecture and noticed a subtle safety constraint in update_chunk().

Observation:
The unsafe { std::slice::from_raw_parts(...) } in update_chunk() assumes the req.data pointer remains valid only because the slice is consumed immediately within safe_write/copy_on_write.

Why this matters now:
This is perfectly safe in the current synchronous flow. However, if we ever optimize by making writes asynchronous (write-behind, background flush), this would become a use-after-free hazard.

Low-effort safeguard suggestion:

  1. Add a // SAFETY: comment above the unsafe block documenting this synchronous consumption requirement
  2. (Future) Consider providing a safe API layer that accepts &[u8] alongside the raw pointer interface

This isn't a pressing bug, but documenting this constraint will prevent accidental memory safety issues during future optimizations.

Thoughts?

Originally created by @red1239109-cmd on GitHub (Jan 20, 2026). Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/384 Originally assigned to: @SF-Zhou, @Copilot on GitHub. [SAFETY] Memory safety consideration in update_chunk() Hi team, I was studying the Engine module to understand its architecture and noticed a subtle safety constraint in `update_chunk()`. **Observation:** The `unsafe { std::slice::from_raw_parts(...) }` in `update_chunk()` assumes the `req.data` pointer remains valid only because the slice is consumed immediately within `safe_write`/`copy_on_write`. **Why this matters now:** This is perfectly safe in the current synchronous flow. However, if we ever optimize by making writes asynchronous (write-behind, background flush), this would become a use-after-free hazard. **Low-effort safeguard suggestion:** 1. Add a `// SAFETY:` comment above the unsafe block documenting this synchronous consumption requirement 2. (Future) Consider providing a safe API layer that accepts `&[u8]` alongside the raw pointer interface This isn't a pressing bug, but documenting this constraint will prevent accidental memory safety issues during future optimizations. Thoughts?
bsakaguchi commented 2026-10-26 09:47:24 +00:00
Author
Owner
Copy link

@SF-Zhou commented on GitHub (Jan 20, 2026):

Thanks for catching this — I'll add a SAFETY comment to document the assumption.

<!-- gh-comment-id:3771093074 --> @SF-Zhou commented on GitHub (Jan 20, 2026): Thanks for catching this — I'll add a SAFETY comment to document the assumption.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
SF-Zhou-patch-1
No results found.
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/3FS#225
No description provided.