Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp150897imu; Thu, 15 Nov 2018 23:58:09 -0800 (PST) X-Google-Smtp-Source: AJdET5fuCXVInQ6WJsgfJd3hU3eyP2CCI4Q5z1RB/j5dgIMh+nzP8SUZJ5Wvw+J5bljPOSNjCD6D X-Received: by 2002:a62:14d1:: with SMTP id 200mr10132817pfu.103.1542355089553; Thu, 15 Nov 2018 23:58:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542355089; cv=none; d=google.com; s=arc-20160816; b=i1eWa8VwEqJYdG/suL5tVv3808Tfrl5gO92E/zFbnXZnxdIbUmQto0c9sdeUxw6PGv 6Hx8kVF6g/et5cy+rzScUbRC+rRmL9rEVG/n36nXGQWSGpDERCgEX+exZqgU6ZhAdtH8 wDrwzEgbp7w8nH2vWoE8F3XZ9TJbnQ006WU9QuebgvQkyBmwaVfZhxiwPMVDx05f7Lex ebNpQcIJO0XMwVw1OTgXGblvbs4z+gfhbaQ8W5rDYkdoqC+wlq6fICH7pDgWTSMAoDGH Q+Z7wn6S+aoHwrZ/9muSIved0K62zSrppTZv46PjyGVLWxmjlJcop8hEZHVswQCmuLnG lgmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=vmTx8CgAMUPUXF9oxqu76gvKs2MmM+nz6oiUVcqobzc=; b=zacC94DLxqD2JRZXIWx9Fp3wngDR/XE0bTCFGTgE/1mgmUX+/InR91SAt+VROqyCfd kItE5Hr3zVRCzhP/4yjfYnBIB6j19a2h0VYg0nsigrv8GsF3Ll5zyqej7l1KazD/mMXn dZVpKdgu5pDYRDHPLhHrVI01tOmY0UHp+2i4u5bd6wHGCa7WK6Dgd5EmCbUrqlbh6dd1 hTU/zqGeMfFwXcnm3MH7BJx72dT3+JPMQxUlwEVvTZfmCJBYTb2K7Ar0XUbN0UQchVQe 97FlKWxOqhPHB9PFgFJo8VfjaNDuIe0Qpjxk7St6BA29niWYtBqp7Cu46dHiL8Ag7FBb cf2A== 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 h3-v6si32551822pfd.228.2018.11.15.23.57.54; Thu, 15 Nov 2018 23:58:09 -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 S1728062AbeKPSHI (ORCPT + 99 others); Fri, 16 Nov 2018 13:07:08 -0500 Received: from relay.sw.ru ([185.231.240.75]:53012 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727410AbeKPSHH (ORCPT ); Fri, 16 Nov 2018 13:07:07 -0500 Received: from [172.16.24.21] by relay.sw.ru with esmtp (Exim 4.90_1) (envelope-from ) id 1gNYyg-0004Z1-8L; Fri, 16 Nov 2018 10:55:46 +0300 Subject: Re: [PATCH] mm: cleancache: fix corruption on missed inode invalidation To: Andrew Morton , Pavel Tikhomirov Cc: Andrey Ryabinin , Konstantin Khorenko , Johannes Weiner , Mel Gorman , Jan Kara , Matthew Wilcox , Andi Kleen , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20181112095734.17979-1-ptikhomirov@virtuozzo.com> <20181115143103.c6fa8fec343bb706b91f6c6c@linux-foundation.org> From: Vasily Averin Message-ID: Date: Fri, 16 Nov 2018 10:55:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181115143103.c6fa8fec343bb706b91f6c6c@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/16/18 1:31 AM, Andrew Morton wrote: > On Mon, 12 Nov 2018 12:57:34 +0300 Pavel Tikhomirov wrote: > >> 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. >> > > Data corruption sounds serious. Shouldn't we backport this into > -stable kernels? Yes, it was broken in 4.14 kernel and it should affect all who uses cleancache Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")