Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3984880imu; Mon, 12 Nov 2018 04:01:22 -0800 (PST) X-Google-Smtp-Source: AJdET5eb9sP6kYkGVYEJk6Rkd5QD69gSseJTXyZ/YxrPVm6tiO5Mmc1aZ2gvxT+1t9MJtRZytzXM X-Received: by 2002:a17:902:7685:: with SMTP id m5-v6mr445377pll.111.1542024082262; Mon, 12 Nov 2018 04:01:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542024082; cv=none; d=google.com; s=arc-20160816; b=OHFSdzO05MqmuuZKlOtLkjsBdoi107UHgIsV8Z6ebTAL3Yff1lBJjmGloT1KQdY3Ac cUr/gN+Bof+So1h3ul+TRE9bBhz9sszwPLQQvxDqHDHP+9BVOS/1zOfrKdeGauV9S5At rQPnztdUnn0VT8jXZtSY9yyP/edxyaFe93Bid3dyEMp5XbUxKO4xAlsZbF1l+evwOQzb XbfrjS0a2CYMp3JC583slo+DxKGgEyizQRe97PCQ9pjQFSGBon4akMeDigWmKmD/LJjA GEZeDuA526vG/tu2vH9MpGU2MXnAEKs1MOtvPMDUW+dC5s58k/QbY4+OYPsBL3Aosy7S Rbow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=lPgQrY/hEr6EnH4YxP1qV6ve7x1RyTlRzCugdoO0NYY=; b=AWbItsc/pxl7FfAbIgvMDaJNuAiTO1U7zMO4QZKCb/kTBcG3ITmAXawy4rbSjFprfA X1qm3bhgAo6bknaqrChHBFwB1W0BGvv2D2KpbzDq6fo+nrUm2OPZfuXghnWSUpbd4mdm /AVJjT9iFTDOUztDo/8TO29xIetsMIoFYnTpV/Y4EWV8Snjh5xTryMtj00GBUYAzDU/f i739HottUdO8PYd2N88bsomwLNLB8YBHEdgaDB/EGG52tMfLUGUiy7CnkKXl/9h2pIfb jySsB0HSOM2/J1c5p5n/7cCKJKzrS5SI1i0bqPjEfQO56P3JQACkLVeoYJpoHYc36//n r0mg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j23-v6si16956383pll.179.2018.11.12.04.01.04; Mon, 12 Nov 2018 04:01:22 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730068AbeKLVxN (ORCPT + 99 others); Mon, 12 Nov 2018 16:53:13 -0500 Received: from relay.sw.ru ([185.231.240.75]:43202 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729569AbeKLVxL (ORCPT ); Mon, 12 Nov 2018 16:53:11 -0500 Received: from [172.16.24.163] (helo=snorch.sw.ru) by relay.sw.ru with esmtp (Exim 4.90_1) (envelope-from ) id 1gMAsv-0006JV-RC; Mon, 12 Nov 2018 15:00:05 +0300 From: Pavel Tikhomirov To: Jan Kara Cc: Vasily Averin , Andrey Ryabinin , Konstantin Khorenko , Pavel Tikhomirov , Johannes Weiner , Mel Gorman , Matthew Wilcox , Andi Kleen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] mm: cleancache: fix corruption on missed inode invalidation Date: Mon, 12 Nov 2018 15:00:03 +0300 Message-Id: <20181112120003.23245-1-ptikhomirov@virtuozzo.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181112113153.GC7175@quack2.suse.cz> References: <20181112113153.GC7175@quack2.suse.cz> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. v2: add comment Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache") To: Andrew Morton Cc: Johannes Weiner Cc: Mel Gorman Cc: Jan Kara Cc: Matthew Wilcox Cc: Andi Kleen Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Vasily Averin Reviewed-by: Andrey Ryabinin Reviewed-by: Jan Kara Signed-off-by: Pavel Tikhomirov --- mm/truncate.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/truncate.c b/mm/truncate.c index 45d68e90b703..2c5285767ce5 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -517,9 +517,14 @@ void truncate_inode_pages_final(struct address_space *mapping) */ xa_lock_irq(&mapping->i_pages); xa_unlock_irq(&mapping->i_pages); - - truncate_inode_pages(mapping, 0); } + + /* + * Cleancache needs notification even if there are no pages or shadow + * entries, else we will leave leftover pages in the cleancache for + * a deleted inode. + */ + truncate_inode_pages(mapping, 0); } EXPORT_SYMBOL(truncate_inode_pages_final); -- 2.17.1