summaryrefslogtreecommitdiff
path: root/arch/um/include
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2012-11-26 14:48:41 (GMT)
committerSteve French <smfrench@gmail.com>2012-11-27 19:46:12 (GMT)
commit3a98b8614312026d489e56c1d0e294a68e2aad77 (patch)
tree19230b635db898db1ca0661cbc4170fca9bccade /arch/um/include
parent5e351cdc998db82935d1248a053a1be37d1160fd (diff)
downloadlinux-3a98b8614312026d489e56c1d0e294a68e2aad77.tar.xz
cifs: fix writeback race with file that is growing
Commit eddb079deb4 created a regression in the writepages codepath. Previously, whenever it needed to check the size of the file, it did so by consulting the inode->i_size field directly. With that patch, the i_size was fetched once on entry into the writepages code and that value was used henceforth. If the file is changing size though (for instance, if someone is writing to it or has truncated it), then that value is likely to be wrong. This can lead to data corruption. Pages past the EOF at the time that the writepages call was issued may be silently dropped and ignored because cifs_writepages wrongly assumes that the file must have been truncated in the interim. Fix cifs_writepages to properly fetch the size from the inode->i_size field instead to properly account for this possibility. Original bug report is here: https://bugzilla.kernel.org/show_bug.cgi?id=50991 Reported-and-Tested-by: Maxim Britov <ungifted01@gmail.com> Reviewed-by: Suresh Jayaraman <sjayaraman@suse.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
Diffstat (limited to 'arch/um/include')
0 files changed, 0 insertions, 0 deletions