diff options
author | Zhao Lei <zhaolei@cn.fujitsu.com> | 2015-07-21 10:42:26 +0300 |
---|---|---|
committer | Chris Mason <clm@fb.com> | 2015-08-09 17:07:11 +0300 |
commit | a0dd59de3c73fbb3b738eaf333732f2f27254a2c (patch) | |
tree | 076493bd15c6a524095beec075cc99fd9f6779a6 /fs/hfsplus/tables.c | |
parent | 6fa96d72f79a15579da2bb63c65cafb210915b48 (diff) | |
download | linux-a0dd59de3c73fbb3b738eaf333732f2f27254a2c.tar.xz |
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/hfsplus/tables.c')
0 files changed, 0 insertions, 0 deletions