aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorMingming Cao <cmm@us.ibm.com>2007-07-31 00:37:46 -0700
committerGreg Kroah-Hartman <gregkh@suse.de>2007-08-09 14:27:36 -0700
commite2b5b2ab31b585fd67faab69db3bfe2e3c993ec7 (patch)
treeb5de611d697618020de33e6069cfd7f493d47dd9 /include
parent04a603a7e20124d3f2fed85a4dfda07cf2216268 (diff)
"ext4_ext_put_in_cache" uses __u32 to receive physical block number
Yan Zheng wrote: > I think I found a bug in ext4/extents.c, "ext4_ext_put_in_cache" uses > "__u32" to receive physical block number. "ext4_ext_put_in_cache" is > used in "ext4_ext_get_blocks", it sets ext4 inode's extent cache > according most recently tree lookup (higher 16 bits of saved physical > block number are always zero). when serving a mapping request, > "ext4_ext_get_blocks" first check whether the logical block is in > inode's extent cache. if the logical block is in the cache and the > cached region isn't a gap, "ext4_ext_get_blocks" gets physical block > number by using cached region's physical block number and offset in > the cached region. as described above, "ext4_ext_get_blocks" may > return wrong result when there are physical block numbers bigger than > 0xffffffff. > You are right. Thanks for reporting this! Signed-off-by: Mingming Cao <cmm@us.ibm.com> Cc: Yan Zheng <yanzheng@21cn.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions