Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2969729imu; Sun, 9 Dec 2018 13:57:03 -0800 (PST) X-Google-Smtp-Source: AFSGD/VxN/dsuJZixDXzXZb9e+cEbmZRbpyC+L7zvl1/7wF1KkRBwD9WlJQDd40QbxRYTV5NGoVJ X-Received: by 2002:a17:902:b78b:: with SMTP id e11mr9924558pls.90.1544392623062; Sun, 09 Dec 2018 13:57:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544392623; cv=none; d=google.com; s=arc-20160816; b=ww8hVaICgxu3nfJ38lKpx/4PYv5byAHAjE6GYWE656KoWpEaOQ3ZRxVT/rSoBxxwnP KGuqI+jvRLT+0+LYxAIsuyjLURrd9716Dfo2hjTZZoGk2bWchhJG0pbceDyILa2HUpnr 8IN43eXGT29e5dCR9HhwxSX7GS2q3bOf3jWg+TFFe++MxE7/XIj9z1JZnAWjNzksPFmH +n/vgNSPfoFeoGy92GPob44Kn9xCzqVYb+10edI3IUHJxMXNGOIA3jkVU4tCzsNp7Wet m9pD0OMicTgNZ6a9ezWJMp5/e8gJN3BL+4NmcYH89X0nrXWCK9Xn3m7QGgm8Wrdk2rBn nI5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=8nxq8oUedpP3noAh3reiWf7WMnBKO1ythclzm9kG3c8=; b=MG9vKtTlbSTYvhGMeCkp2Bk5vXWTzIQwPfC6vQmTNbyXkTfaRspYxOAFVAPdwegFgI CyqN7j6F4oA785a6xFZ/leXL1Vg2KLNiQWDLjjtYdqDiNvpHLpYlZdxKoUbs3OoVxHjr y2mbbDIv4wJgBvQbBEnOXR3AZR29nW3ZXAbRQCF2+q7LEwxJoH6bIyhAJptC0JzDoSdY ef/LRm64TZp6F34mlfyccFLLHkOsvAfms51LHbcLlgGIJs/XupXxeViICAFMyyxx6r4I uolEkcoh9VL4gyxGKi67Yoz8sJfl9SO3zK0UxVdylsUC1q8nyOKYXSl6Djsw4wHBE1Zb dJGw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u28si8124488pgn.436.2018.12.09.13.56.47; Sun, 09 Dec 2018 13:57:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726835AbeLIVzq (ORCPT + 99 others); Sun, 9 Dec 2018 16:55:46 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35572 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726577AbeLIVz1 (ORCPT ); Sun, 9 Dec 2018 16:55:27 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72q-0002pr-G9; Sun, 09 Dec 2018 21:55:24 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72l-0003hi-TS; Sun, 09 Dec 2018 21:55:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Andi Kleen" , "Jan Kara" , "Johannes Weiner" , "Andrey Ryabinin" , "Vasily Averin" , "Linus Torvalds" , "Mel Gorman" , "Matthew Wilcox" , "Pavel Tikhomirov" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 325/328] mm: cleancache: fix corruption on missed inode invalidation In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Pavel Tikhomirov commit 6ff38bd40230af35e446239396e5fc8ebd6a5248 upstream. If all pages are deleted from the mapping by memory reclaim and also moved to the cleancache: __delete_from_page_cache (no shadow case) unaccount_page_cache_page cleancache_put_page page_cache_delete mapping->nrpages -= nr (nrpages becomes 0) We don't clean the cleancache for an inode after final file truncation (removal). truncate_inode_pages_final check (nrpages || nrexceptional) is false no truncate_inode_pages no cleancache_invalidate_inode(mapping) These way when reading the new file created with same inode we may get these trash leftover pages from cleancache and see wrong data instead of the contents of the new file. Fix it by always doing truncate_inode_pages which is already ready for nrpages == 0 && nrexceptional == 0 case and just invalidates inode. [akpm@linux-foundation.org: add comment, per Jan] Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache") Signed-off-by: Pavel Tikhomirov Reviewed-by: Vasily Averin Reviewed-by: Andrey Ryabinin Reviewed-by: Jan Kara Cc: Johannes Weiner Cc: Mel Gorman Cc: Matthew Wilcox Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- mm/truncate.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/mm/truncate.c +++ b/mm/truncate.c @@ -461,9 +461,13 @@ void truncate_inode_pages_final(struct a */ spin_lock_irq(&mapping->tree_lock); spin_unlock_irq(&mapping->tree_lock); - - truncate_inode_pages(mapping, 0); } + + /* + * Cleancache needs notification even if there are no pages or shadow + * entries. + */ + truncate_inode_pages(mapping, 0); } EXPORT_SYMBOL(truncate_inode_pages_final);