summaryrefslogtreecommitdiffstats
path: root/fs/ramfs
diff options
context:
space:
mode:
authorZhao Lei <zhaolei@cn.fujitsu.com>2015-07-21 15:42:26 +0800
committerChris Mason <clm@fb.com>2015-08-09 07:07:11 -0700
commita0dd59de3c73fbb3b738eaf333732f2f27254a2c (patch)
tree076493bd15c6a524095beec075cc99fd9f6779a6 /fs/ramfs
parent6fa96d72f79a15579da2bb63c65cafb210915b48 (diff)
downloadlinux-a0dd59de3c73fbb3b738eaf333732f2f27254a2c.tar.bz2
btrfs: Fix calculate typo caused by ambiguous meaning of logic_end
For example, in scrub_raid56_parity(), following lines are used to judge is all data processed: place1: if (key.objectid > logic_end) ... place2: if (logic_start >= logic_end) ... ... (place2 is typo, is should be ">", it is copied from other place, where logic_end's meaning is different, long story...) We can fix above typo directly, but the root reason is ambiguous meaning of logic_end in scrub raid56 parity. In other place, XXX_end is pointed to data which is not included, and we need to process segment of [XXX_start, XXX_end). But for scrub raid56 parity, logic_end is pointed to lattest data need to process, and introduced many "+ 1" and "- 1" in code as below: length = sparity->logic_end - sparity->logic_start + 1 logic_end - logic_start + 1 stripe_logical + increment - 1 This patch changed logic_end's meaning to make it in normal understanding in raid56 parity functions and data struct alone with above bugfix. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'fs/ramfs')
0 files changed, 0 insertions, 0 deletions