在 2026/8/2 17:07, Cole Munz 写道:
On 2026/8/2 16:17, Qu Wenruo wrote:
The function btrfs_read_next_dirty_entry() is search the key inside the
parent directory.
Meanwhile this one is search for the inode item of the child entry.
They are completely different and I didn't see why "refactor" can improve.
Right, the two searches are for different keys and cannot be merged.
The repetition v2 removes is elsewhere. btrfs_size() open codes the
same inode item search, and its error path never releases the path.
OK, the u-boot's btrfs_search_slot() is different from kernel and progs,
that on error it doesn't release the path.
So indeed we need to properly clean it up.
Although I'd prefer to change btrfs_search_slot() in u-boot to follow
the same kernel/progs behavior.
For the new helper, btrfs_get_inode_size(), is indeed called in both
btrfs_size() and btrfs_readdir(), so there is indeed some duplication.
That leaks the extent buffers btrfs_search_slot() attached before
failing. So v2 mixed a cleanup into a fix, which was the real
mistake here.
How about a v3 with the fix back in the v1 shape, plus a second patch
for the btrfs_size() helper and the missing release?
That sounds very reasonable to me.
Thanks,
Qu
