summaryrefslogtreecommitdiffstats
path: root/fs/exofs
diff options
context:
space:
mode:
authorBoaz Harrosh <bharrosh@panasas.com>2012-06-08 02:02:30 +0300
committerBoaz Harrosh <bharrosh@panasas.com>2012-07-20 11:50:31 +0300
commitc999ff68029ebd0f56ccae75444f640f6d5a27d2 (patch)
tree1b6dfac964c363ea50048c2d6609e143a900126f /fs/exofs
parent9909d45a8557455ca5f8ee7af0f253debc851f1a (diff)
downloadlinux-stable-c999ff68029ebd0f56ccae75444f640f6d5a27d2.tar.gz
linux-stable-c999ff68029ebd0f56ccae75444f640f6d5a27d2.tar.bz2
linux-stable-c999ff68029ebd0f56ccae75444f640f6d5a27d2.zip
pnfs-obj: Fix __r4w_get_page when offset is beyond i_size
It is very common for the end of the file to be unaligned on stripe size. But since we know it's beyond file's end then the XOR should be preformed with all zeros. Old code used to just read zeros out of the OSD devices, which is a great waist. But what scares me more about this situation is that, we now have pages attached to the file's mapping that are beyond i_size. I don't like the kind of bugs this calls for. Fix both birds, by returning a global zero_page, if offset is beyond i_size. TODO: Change the API to ->__r4w_get_page() so a NULL can be returned without being considered as error, since XOR API treats NULL entries as zero_pages. [Bug since 3.2. Should apply the same way to all Kernels since] CC: Stable Tree <stable@kernel.org> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Diffstat (limited to 'fs/exofs')
0 files changed, 0 insertions, 0 deletions