mirror of
https://github.com/versity/scoutfs.git
synced 2026-02-09 04:00:10 +00:00
a8db7e5b74
If item iteration finds a hole in the cache it tries to read items. After the items are read it can look at the cached region and return items or -ENOENT. We recently added an end key to limit how far we can read and cache items. The end key addition correctly limited the cache read to the lock end value. It could never read item cache ranges beyond that. This means that it can't iterate past the end value and should return -ENOENT if it gets past end. But the code forgot to do that, it only checked for iteration past last before returning -ENOENT. It spins continually finding a hole past end but inside last, tries to read items but limits them to end, then finds the same hole again. Triggering this requires a lock end that's nearer than the last iteration key. That's hard to do because most of our item reads are covered by inode group locks which extend well past iteration inside a given inode. Inode index item can easily trigger this if there's no items. I tripped over it when walking empty indexes (data_seq or online_blocks with no regular files). Signed-off-by: Zach Brown <zab@versity.com>