A revoked page-cache read stays on ff->revoke_list until it completes. It's possible and legitimate that a second invalidation of the same inode is issued before a reply to the revoked read by userspace, so so drop the bogus WARN_ON_ONCE() and just skip it.
https://virtuozzo.atlassian.net/browse/VSTOR-136315 Signed-off-by: Liu Kui <[email protected]> --- fs/fuse/file.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index e804e3c0d6bd..17f1a21b0445 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -1225,11 +1225,15 @@ void fuse_revoke_readpages(struct fuse_file *ff) spin_lock(&ff->lock); /* revoke all pending read issued from page cache */ list_for_each_entry(ia, &ff->revoke_list, revoke_entry) { - /* this should never happen unless userspace misbehaves */ - if (unlikely(ia->ap.args.killed)) { - WARN_ON_ONCE(1); + /* + * Already revoked by a previous invalidation and not yet completed, + * its pages are already unlocked and its completion callback will + * remove it from the list. This is a normal condition when the same + * inode is invalidated more than once while a read is still outstanding, + * so just skip it. + */ + if (ia->ap.args.killed) continue; - } ia->ap.args.killed = 1; for (i = 0; i < ia->ap.num_pages; i++) unlock_page(ia->ap.pages[i]); -- 2.50.1 (Apple Git-155) _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
