Skip to content

Clear ref_blkno output when block is already dirty - #315

Open
aversecat wants to merge 1 commit into
mainfrom
auke/clear_ref_blkno_dirty
Open

Clear ref_blkno output when block is already dirty#315
aversecat wants to merge 1 commit into
mainfrom
auke/clear_ref_blkno_dirty

Conversation

@aversecat

Copy link
Copy Markdown
Contributor

block_dirty_ref() skipped setting *ref_blkno when the block was already dirty, leaving the caller with a stale value passed by reference.

dirty_alloc_blocks() calls it twice but when the referenced block is already dirty, it will receive the uninitialized stack value back, and then adding it freed list with list_block_add() later.

Set it to 0 on the already-dirty fast path so callers do not try to free a random block.

@aversecat aversecat added the Bugfix Fixes a known bug label May 12, 2026
Comment thread kmod/src/block.c Outdated
@aversecat
aversecat force-pushed the auke/clear_ref_blkno_dirty branch from 9ab925b to c9d442c Compare July 1, 2026 17:07
scoutfs_block_dirty_ref() only sets *ref_blkno on the path that
allocates a new cow block. The early return paths leave it untouched,
so a caller that reads it back gets whatever value was on the stack.

This is harmless with the current callers. dirty_alloc_blocks() bails
out before calling here when the blocks are already dirty, so the
early return on an already-dirty block is never reached, and the
error paths return a negative value that callers check before using
ref_blkno.

Signed-off-by: Auke Kok <auke.kok@versity.com>
@aversecat
aversecat force-pushed the auke/clear_ref_blkno_dirty branch from c9d442c to e2ee720 Compare August 13, 2026 17:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bugfix Fixes a known bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants