summaryrefslogtreecommitdiffstats
path: root/fs/hpfs/alloc.c
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2012-11-26 09:48:41 -0500
committerSteve French <smfrench@gmail.com>2012-11-27 13:46:12 -0600
commit3a98b8614312026d489e56c1d0e294a68e2aad77 (patch)
tree19230b635db898db1ca0661cbc4170fca9bccade /fs/hpfs/alloc.c
parent5e351cdc998db82935d1248a053a1be37d1160fd (diff)
downloadlinux-3a98b8614312026d489e56c1d0e294a68e2aad77.tar.gz
linux-3a98b8614312026d489e56c1d0e294a68e2aad77.tar.bz2
linux-3a98b8614312026d489e56c1d0e294a68e2aad77.zip
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 'fs/hpfs/alloc.c')
0 files changed, 0 insertions, 0 deletions