From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F55DCA9EC4 for ; Tue, 29 Oct 2019 16:52:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 428CF20830 for ; Tue, 29 Oct 2019 16:52:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="PCQcPN9k" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 428CF20830 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E3A886B0005; Tue, 29 Oct 2019 12:52:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEAE96B0008; Tue, 29 Oct 2019 12:52:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD90A6B000A; Tue, 29 Oct 2019 12:52:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id A39AC6B0005 for ; Tue, 29 Oct 2019 12:52:26 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 52CF7181AEF31 for ; Tue, 29 Oct 2019 16:52:26 +0000 (UTC) X-FDA: 76097415492.13.war30_899efb319ba54 X-HE-Tag: war30_899efb319ba54 X-Filterd-Recvd-Size: 4345 Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 16:52:25 +0000 (UTC) Received: by mail-lf1-f67.google.com with SMTP id y6so11073658lfj.2 for ; Tue, 29 Oct 2019 09:52:25 -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=JCP0gTNW0nrKOjfGXUDHkeT9LXYh8gTwBFSl8WQWe9E=; b=PCQcPN9krk/MLfnozI5e+YmrRxCY8nQ2YUphNRQ+Q7PWvraCFUevYyKeC3hb6cSU+E ptoftGM6aIVugo0NJ5Sj7+8ikD83EWAw+XBoNW6982A8TmkIVBVLCjVZXretXxGE0hIE uxSzFEmOYqjXztMzAKG2M3avS6nE/p3Mb230Y= 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=JCP0gTNW0nrKOjfGXUDHkeT9LXYh8gTwBFSl8WQWe9E=; b=ZWGTO8FlaAumf1jWhsQpqeyOrrgTrrgx8ZKN/8DzGLq68l02HWdyPVJUjWAXaUYCxA Gngiz7xi7QW9xWlVIZIxtpwxKGRvVC8uaHV+KoBMDjmacMDDAnbMHKAIL24qmo1S6L6x Yn7zD5ika+guo22H1yibRBfrhFtBOie8dn6Uz1u+ZSsdwCQtnGOfQ0MwneEYkJw2OoLa pfhx4CRaNUjorsarNp3PhcuRDSin+zawcADzVczIvDnvGw1YG0+99JPvC2mov0xHcZhY PxzS6gMCTOKZnp9/rKxfYsvTxazJZUHkaBN6iuk/pPZb708MpNyagbjyIO2F6YkpSwRV LW5Q== X-Gm-Message-State: APjAAAVZmL4E44e/owMW0AeTfv9WAupuYuPN1E4GOePQc/UVLd12N+rU XLUBFTPiEv8+V27diQUVH6XVpSkg5sknrA== X-Google-Smtp-Source: APXvYqx3rjHWN08yol64Rei6URE56G6D4BJnJbU/u5Y0CXaiXCQDUn+zJFb0W1JwkyTA8Yf2pnxNAA== X-Received: by 2002:a19:dc14:: with SMTP id t20mr3182581lfg.21.1572367943290; Tue, 29 Oct 2019 09:52:23 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id g2sm6231858lfc.37.2019.10.29.09.52.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Oct 2019 09:52:22 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id u16so11077832lfq.3 for ; Tue, 29 Oct 2019 09:52:21 -0700 (PDT) X-Received: by 2002:a19:820e:: with SMTP id e14mr3088342lfd.29.1572367941598; Tue, 29 Oct 2019 09:52:21 -0700 (PDT) MIME-Version: 1.0 References: <157225677483.3442.4227193290486305330.stgit@buzz> <20191028124222.ld6u3dhhujfqcn7w@box> <20191028125702.xdfbs7rqhm3wer5t@box> In-Reply-To: From: Linus Torvalds Date: Tue, 29 Oct 2019 17:52:05 +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: "Kirill A. Shutemov" , Linux-MM , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Johannes Weiner , Steven Whitehouse Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 29, 2019 at 3:25 PM Konstantin Khlebnikov wrote: > > I think all network filesystems which synchronize metadata lazily should be > marked. For example as "SB_VOLATILE". And vfs could handle them specially. No need. The VFS layer doesn't call generic_file_buffered_read() directly anyway. It's just a helper function for filesystems to use if they want to. They could (and should) make sure the inode size is sufficiently up-to-date before calling it. And if they want something more synchronous, they can do it themselves. But NFS, for example, has open/close consistency, so the metadata revalidation is at open() time, not at read time. Linus