The patch titled
Subject: mm/filemap.c: warn if stale pagecache is left after direct write
has been removed from the -mm tree. Its filename was
fs-warn-if-stale-pagecache-is-left-after-direct-write.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxxxxxx>
Subject: mm/filemap.c: warn if stale pagecache is left after direct write
generic_file_direct_write() tries to invalidate pagecache after O_DIRECT
write. Unlike to similar code in dio_complete() this silently ignores
error returned from invalidate_inode_pages2_range().
According to comment this code here because not all filesystems call
dio_complete() to do proper invalidation after O_DIRECT write. Noticeable
example is a blkdev_direct_IO().
This patch calls dio_warn_stale_pagecache() if invalidation fails.
Link: http://lkml.kernel.org/r/157270038294.4812.2238891109785106069.stgit@buzz
Signed-off-by: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxxxxxx>
Reviewed-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Reviewed-by: Jan Kara <jack@xxxxxxx>
Cc: Jens Axboe <axboe@xxxxxxxxx>
Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/filemap.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/mm/filemap.c~fs-warn-if-stale-pagecache-is-left-after-direct-write
+++ a/mm/filemap.c
@@ -3241,11 +3241,13 @@ generic_file_direct_write(struct kiocb *
* do not end up with dio_complete() being called, so let's not break
* them by removing it completely.
*
+ * Noticeable example is a blkdev_direct_IO().
+ *
* Skip invalidation for async writes or if mapping has no pages.
*/
- if (written > 0 && mapping->nrpages)
- invalidate_inode_pages2_range(mapping,
- pos >> PAGE_SHIFT, end);
+ if (written > 0 && mapping->nrpages &&
+ invalidate_inode_pages2_range(mapping, pos >> PAGE_SHIFT, end))
+ dio_warn_stale_pagecache(file);
if (written > 0) {
pos += written;
_
Patches currently in -mm which might be from khlebnikov@xxxxxxxxxxxxxx are
mm-vmstat-add-helpers-to-get-vmstat-item-names-for-each-enum-type.patch
mm-vmstat-do-not-use-size-of-vmstat_text-as-count-of-proc-vmstat-items.patch
mm-memcontrol-use-vmstat-names-for-printing-statistics.patch
