Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3752453ybg; Mon, 28 Oct 2019 18:46:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqyzGWqmymhaC/4I4ekVhFjlg3GHD+Vyg8CUGPRzKDJuIPtalkU4UeKoTsNeRb2JYc0jFYOG X-Received: by 2002:a17:906:1542:: with SMTP id c2mr866368ejd.80.1572313587594; Mon, 28 Oct 2019 18:46:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572313587; cv=none; d=google.com; s=arc-20160816; b=ES/9herRHur5ZZ1RNF2bF9omzDcg8yX1WOr4hyuWW5Dl7CBPn8toVO1t1+rKJxLqLr J+9+fau1kPZ+V1R7KPNMjeQxWFtIzW2g4i34xNNPDzY5vr5dxHUDg17HohDmVq7jabLd ZjnBRaNV0dbudvhW1H6yYHkcX1ycejDsuU6UA9LHj2D9oksQ3aE94gQODWuZgVWwZlap By9Vy9b05t/kCm4nyqU06dDW7+SfntLmmHX/CETcMHycHjsT/7y/uG8tw0G3wV7moDig GdP3LnsTSSnkMBMEBH9VYK55f9AA5x4oG2kPiKUNohl5yR5o0eKLGmgnXEcZwn5uoQZ/ 7W2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ATDKJMcIxCSwydf+1lUKxJ7Ftg71NmlGmbozwsqMkmc=; b=uVSQ+sQbKSZWZm7bz3q5ljOHxdfh9YHTZbgsC39dHZkfev0IYq8f5NA2A/cf64GoLI AkCMvNbWeGaQulJ7fkTdHdZXssPRQzuifVUDXSt0saUruysaikqYFppS5JHu3pf4aUVo s51WLiTP/XN0ZjoIhvnwu6vpnJa+OXC9ha1bxJOdTUfffPqVv0L1rBmUSc04Vt9aqcEE kCu4UJHbMsC+KVZ9CfB5V4S+LrlGCURQfu5R8nxaDbmE+Adv31Rv4OtKWX9pq7vvzD3h JmMpmmtRrFquxvw8uB7EOdagmaNjyeU0Bo5B+bfqM2taEW9jo2FhdpKNlie1FGKl66HY 9how== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=QlzDd1Bh; 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 m16si6809541ejd.306.2019.10.28.18.46.03; Mon, 28 Oct 2019 18:46:27 -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=@linux-foundation.org header.s=google header.b=QlzDd1Bh; 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 S2389143AbfJ1MkH (ORCPT + 99 others); Mon, 28 Oct 2019 08:40:07 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:43086 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728199AbfJ1MkH (ORCPT ); Mon, 28 Oct 2019 08:40:07 -0400 Received: by mail-lj1-f196.google.com with SMTP id s4so10275572ljj.10 for ; Mon, 28 Oct 2019 05:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ATDKJMcIxCSwydf+1lUKxJ7Ftg71NmlGmbozwsqMkmc=; b=QlzDd1Bh3krOIKFjcDBdZoayUKXaWxUvGFEq2duRqI6syPWfllKIuNiRiwFp3Rsvlm nxqwqgYi8hs/NEk8mASxHt8carAtxDUSL6DW6fwUayesh7ZvlNihXqYJHT/hp5a3B/c/ sAj/eEL2RfuIZGHXujz05q+R3v1iYQI3WZw6c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ATDKJMcIxCSwydf+1lUKxJ7Ftg71NmlGmbozwsqMkmc=; b=AMXzU0RNbGOV1yzMY087YzMOGQ/vLh8QBhZ/2LBCSViQf3GXOyYvZHJ9R/z/wn8coa fTddVou04fzxK2bWVOjPpJcXoxH9KC+6EoGYzczuJMm3jdIh2Xb6aVIoQrDyACjQFTYp qmVX6yVg9zOXsk4UoapPAFFHy6vNWAigljjiMfNOR9nboBkFjDBTuqlx9LKhd8wjuFvX LUBSEdH2Yvgyi0Gs5N4UTsIxCqIkI6UuV1LnRSGQEyFWbMHsFBXmnS+9EV66ON08u3ki mOwpXE0NUE7mU+ZRW55bp7Z7hgl1jhdeQxmM60beNyMmMjSgrhaAQrNvKWW6aHe0NRB4 7nOg== X-Gm-Message-State: APjAAAWfrp48qH3emPnn4kuPHn9WI6OgaI9+iGaFzfd4qKdgfvrGmwV8 vEYFspiC8uw53ylkhBj0XutNfBdsihnQWQ== X-Received: by 2002:a05:651c:1108:: with SMTP id d8mr1931443ljo.221.1572266404791; Mon, 28 Oct 2019 05:40:04 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id f1sm4700434ljk.77.2019.10.28.05.40.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Oct 2019 05:40:02 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id v24so11188342ljj.3 for ; Mon, 28 Oct 2019 05:40:02 -0700 (PDT) X-Received: by 2002:a2e:3e18:: with SMTP id l24mr8529100lja.48.1572266402291; Mon, 28 Oct 2019 05:40:02 -0700 (PDT) MIME-Version: 1.0 References: <157225677483.3442.4227193290486305330.stgit@buzz> In-Reply-To: <157225677483.3442.4227193290486305330.stgit@buzz> From: Linus Torvalds Date: Mon, 28 Oct 2019 13:39:46 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/filemap: do not allocate cache pages beyond end of file at read To: Konstantin Khlebnikov Cc: Linux-MM , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Johannes Weiner Content-Type: text/plain; charset="UTF-8" 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 10:59 AM 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. I wonder if we could just do something like this instead: diff --git a/mm/filemap.c b/mm/filemap.c index 85b7d087eb45..80b08433c93a 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2013,7 +2013,7 @@ static ssize_t generic_file_buffered_read( struct address_space *mapping = filp->f_mapping; struct inode *inode = mapping->host; struct file_ra_state *ra = &filp->f_ra; - loff_t *ppos = &iocb->ki_pos; + loff_t *ppos = &iocb->ki_pos, size; pgoff_t index; pgoff_t last_index; pgoff_t prev_index; @@ -2021,9 +2021,10 @@ static ssize_t generic_file_buffered_read( unsigned int prev_offset; int error = 0; - if (unlikely(*ppos >= inode->i_sb->s_maxbytes)) + size = i_size_read(inode); + if (unlikely(*ppos >= size)) return 0; - iov_iter_truncate(iter, inode->i_sb->s_maxbytes); + iov_iter_truncate(iter, size); index = *ppos >> PAGE_SHIFT; prev_index = ra->prev_pos >> PAGE_SHIFT; and yes, we still need to re-check the inode size after we've read the page cache page (since it might have changed during the IO), but the above seems fairly benign and simple. Hmm? Linus