summaryrefslogtreecommitdiff
path: root/mm/memory.c
diff options
context:
space:
mode:
authorMatthew Wilcox <matthew.r.wilcox@intel.com>2014-06-04 16:10:44 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2014-06-04 16:54:11 -0700
commit7fc34a62ca4434a79c68e23e70ed26111b7a4cf8 (patch)
treea5d31cf18a1df2e3d9d323e27d108b3cec7a2fd2 /mm/memory.c
parent65eb71823b01051ca6e256e9cc8259141a849052 (diff)
downloadlwn-7fc34a62ca4434a79c68e23e70ed26111b7a4cf8.tar.gz
lwn-7fc34a62ca4434a79c68e23e70ed26111b7a4cf8.zip
mm/msync.c: sync only the requested range in msync()
msync() currently syncs more than POSIX requires or BSD or Solaris implement. It is supposed to be equivalent to fdatasync(), not fsync(), and it is only supposed to sync the portion of the file that overlaps the range passed to msync. If the VMA is non-linear, fall back to syncing the entire file, but we still optimise to only fdatasync() the entire file, not the full fsync(). akpm: there are obvious concerns with bck-compatibility: is anyone relying on the undocumented side-effect for their data integrity? And how would they ever know if this change broke their data integrity? We think the risk is reasonably low, and this patch brings the kernel into line with other OS's and with what the manpage has always said... Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Jeff Moyer <jmoyer@redhat.com> Cc: Chris Mason <clm@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/memory.c')
0 files changed, 0 insertions, 0 deletions