aboutsummaryrefslogtreecommitdiff
path: root/tools/testing/selftests/bpf/prog_tests/global_data_init.c
diff options
context:
space:
mode:
authorJingbo Xu <jefflexu@linux.alibaba.com>2022-11-04 13:40:28 +0800
committerGao Xiang <hsiangkao@linux.alibaba.com>2022-11-08 14:46:30 +0800
commite6d9f9ba111b56154f1b1120252aff269cebd49c (patch)
treecb957acb4f9ff55a3caea2ab1bc1e79e5c90555c /tools/testing/selftests/bpf/prog_tests/global_data_init.c
parent75e43355cbe4d5948a79bd592f2ffecb9f75f75d (diff)
erofs: get correct count for unmapped range in fscache mode
For unmapped range, the returned map.m_llen is zero, and thus the calculated count is unexpected zero. Prior to the refactoring introduced by commit 1ae9470c3e14 ("erofs: clean up .read_folio() and .readahead() in fscache mode"), only the readahead routine suffers from this. With the refactoring of making .read_folio() and .readahead() calling one common routine, both read_folio and readahead have this issue now. Fix this by calculating count separately in unmapped condition. Fixes: c665b394b9e8 ("erofs: implement fscache-based data readahead") Fixes: 1ae9470c3e14 ("erofs: clean up .read_folio() and .readahead() in fscache mode") Signed-off-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Chao Yu <chao@kernel.org> Link: https://lore.kernel.org/r/20221104054028.52208-3-jefflexu@linux.alibaba.com Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Diffstat (limited to 'tools/testing/selftests/bpf/prog_tests/global_data_init.c')
0 files changed, 0 insertions, 0 deletions