summaryrefslogtreecommitdiffstats
path: root/fs/exofs/namei.c
diff options
context:
space:
mode:
authorNick Piggin <npiggin@kernel.dk>2010-11-25 12:47:15 +0200
committerBoaz Harrosh <bharrosh@panasas.com>2011-03-15 15:02:50 +0200
commit97178b7b6c84bd14660b89474d27931a1ea65c66 (patch)
treeb763cc48e6456b944e7bed877ad2a996809124eb /fs/exofs/namei.c
parenta8f1418f9e9bd4c487a7b703ff26c5dd5ceb2bf3 (diff)
downloadlinux-97178b7b6c84bd14660b89474d27931a1ea65c66.tar.gz
linux-97178b7b6c84bd14660b89474d27931a1ea65c66.tar.bz2
linux-97178b7b6c84bd14660b89474d27931a1ea65c66.zip
exofs: simple fsync race fix
It is incorrect to test inode dirty bits without participating in the inode writeback protocol. Inode writeback sets I_SYNC and clears I_DIRTY_?, then writes out the particular bits, then clears I_SYNC when it is done. BTW. it may not completely write all pages out, so I_DIRTY_PAGES would get set again. This is a standard pattern used throughout the kernel's writeback caches (I_SYNC ~= I_WRITEBACK, if that makes it clearer). And so it is not possible to determine an inode's dirty status just by checking I_DIRTY bits. Especially not for the purpose of data integrity syncs. Missing the check for these bits means that fsync can complete while writeback to the inode is underway. Inode writeback functions get this right, so call into them rather than try to shortcut things by testing dirty state improperly. Signed-off-by: Nick Piggin <npiggin@kernel.dk> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Diffstat (limited to 'fs/exofs/namei.c')
0 files changed, 0 insertions, 0 deletions