Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3458958ybg; Mon, 28 Oct 2019 13:11:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxvtXwW23NdlWsPqNqdsJQrAotNREtHWqv7hJ4bdqNEYbTJbPO8Hebz9yc/QTREbxn+Yx/z X-Received: by 2002:a17:906:2961:: with SMTP id x1mr18339917ejd.91.1572293469531; Mon, 28 Oct 2019 13:11:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572293469; cv=none; d=google.com; s=arc-20160816; b=cZammmyVWsDSDjOOSiSfJQ17llR1tvzT+/DaEJCX5Ja45nGqC4UoiYMTyWL1HxwrED c4LsO0WlmaGP5UwzPdsrbHtDuYmBda55zPNISxOB+Umm3DRNE7MW/wc1lr396xS7AXaM cwmPCReNsGHLZklSd4f53p8uTXT8Skz7xTxKVFFMLu0kp58niWE5NFBhxrqk+7nQOsux NqnZLBeAcUczaVOW3qoFp6VKjHs+RNTooQLAsGnQm8NEfeNsWSyrYfaGkGvqwCX6GEvv VWoXHgd6JfWQIowMyLAYfX3VZpbYZebmd6unCQIgRCdWgU9Y9Oc4Nzvoqr73YTzNLqAs LHRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=YXz21DLbYChNtLC16qKg/F5siZzPuHpmcF6L0vjR70Q=; b=u/capIqcDgxHW87D98XZV7SZdnqCJjCKS985sGQNDkdBbpQ8oqXKQEjd5fajv5YQXo u1qOf4jzglqzshdtxa+HjDa1jXAz1AD7552lQnaRsH6mzz6po1+aZ69QwpseDz+ALTFS 05fw+Pm7scdpsE3uxq5birvGMW7ki8OgAIpNLGqZxAbJWnkvMcKMMs95vlD9kJYk57nz o1LBc9gqmOzotzVnus/VqCeknCM/niSnmNKKB7XxVJZD/1qxp9BYmZbiT4fXzRbmqhXt GnLIklR+mSfJDjA/Y87V+0YB/Zuyh41wGroq0F2opCj5JMlMGSkLL0+4FaSFipVIr6yr igmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=UDy5cy9j; 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 b24si3753502ejv.254.2019.10.28.13.10.45; Mon, 28 Oct 2019 13:11:09 -0700 (PDT) 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; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=UDy5cy9j; 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 S2389182AbfJ1MmX (ORCPT + 99 others); Mon, 28 Oct 2019 08:42:23 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:36766 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389175AbfJ1MmX (ORCPT ); Mon, 28 Oct 2019 08:42:23 -0400 Received: by mail-lj1-f194.google.com with SMTP id v24so11196752ljj.3 for ; Mon, 28 Oct 2019 05:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YXz21DLbYChNtLC16qKg/F5siZzPuHpmcF6L0vjR70Q=; b=UDy5cy9jp7qw9ea3NmGoBYL5rkK3rD7lP+Y1vSO/MvqCsnHZxGiFpUyWebGJzCFW9E O4EN/t7pstqQFEkuseKzS6HdAafHy69l0s5ygYkRkW8TfdZhrlCNwaXt87RY98wEt4RP Is7yuQa+XX5HsO0mbecgrOsACK82b0mMHfbbMNG+RwruNptd7tjW6NPWahNTvZ/ZFKST 2P+zFWeOa9FKappwZ+pztKsRRDT1l00rkjKdMCAIe4JbmppMd9zzBec12Pq0lMHa2GJ7 Nl6Qdmal2rG3oTZIll/X/BRfpYMawwGMn5q0oMGKiT8/fQssH8XyiL1bv1kzEd1UPD1C iwTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YXz21DLbYChNtLC16qKg/F5siZzPuHpmcF6L0vjR70Q=; b=dC1R1PE+1hpz7ulwlYiAOoJfuV1T+NKmyBNeygDdDOxHmdFuTpJSxy3LTS90VeCD7w 2Aim1k39UL6lH4Xr/7Lc1s6gxvbAeA7ymk+FA+v7/vNJIU9iCSo7leiaNacmYpZnABpC S6wSxE+oUPmtaAJ6D0KGjTla8paCmDen+10Jn0NEuVJ4wwPI1IYE3fNPP9QIY5++fCMJ Z0ovsTMoeCn86kZJNUYcZt5TNvSgRzT1y8End42be/g7uk79+cm5MrIvC3JHzo01pUdi lDyYW+7ZNJv9Kr+CBGJBd6JgapVFiMhQjBOcx1eHAXaObvjl/W0dr8Jl3FjzPBMgVPNS 9F+w== X-Gm-Message-State: APjAAAWcUZJH6mF/Zv/rBds08bxevxtkS3/oFoJ5/fEr+41roQVcJmXE UVIRvKQFDdar02YGq9bb0aCqBA== X-Received: by 2002:a2e:547:: with SMTP id 68mr11779036ljf.150.1572266541309; Mon, 28 Oct 2019 05:42:21 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id 4sm6328938lfa.95.2019.10.28.05.42.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2019 05:42:20 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 86B96100242; Mon, 28 Oct 2019 15:42:22 +0300 (+03) Date: Mon, 28 Oct 2019 15:42:22 +0300 From: "Kirill A. Shutemov" To: Konstantin Khlebnikov Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Linus Torvalds , Alexander Viro , Johannes Weiner , Steven Whitehouse Subject: Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read Message-ID: <20191028124222.ld6u3dhhujfqcn7w@box> References: <157225677483.3442.4227193290486305330.stgit@buzz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157225677483.3442.4227193290486305330.stgit@buzz> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 28, 2019 at 12:59:34PM +0300, Konstantin Khlebnikov wrote: > Page cache could contain pages beyond end of file during write or > if read races with truncate. But generic_file_buffered_read() always > allocates unneeded pages beyond eof if somebody reads here and one > extra page at the end if file size is page-aligned. > > Function generic_file_buffered_read() calls page_cache_sync_readahead() > if page not found in cache and then do another lookup. Readahead checks > file size in __do_page_cache_readahead() before allocating pages. > After that generic_file_buffered_read() falls back to slow path and > allocates page for ->readpage() without checking file size. > > This patch checks file size before allocating page for ->readpage(). > > Signed-off-by: Konstantin Khlebnikov > --- > mm/filemap.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 85b7d087eb45..92abf5f348a9 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2225,6 +2225,10 @@ static ssize_t generic_file_buffered_read(struct kiocb *iocb, > goto out; > > no_cached_page: > + /* Do not allocate cache pages beyond end of file. */ > + if (((loff_t)index << PAGE_SHIFT) >= i_size_read(inode)) > + goto out; > + > /* > * Ok, it wasn't cached, so we need to create a new > * page.. > > CC Steven. I've tried something of this sort back in 2013: http://lore.kernel.org/r/1377099441-2224-1-git-send-email-kirill.shutemov@linux.intel.com and I've got push back. Apparently, some filesystems may not have valid i_size before >readpage(). Not sure if it's still the case... Anyway I don't think it's valid reason for this inefficiency. These filesystems have to have own implementation of >read_iter() to deal with this. -- Kirill A. Shutemov