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. 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?
