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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 9FD89CA9EC5 for ; Wed, 30 Oct 2019 10:54:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4EADA20717 for ; Wed, 30 Oct 2019 10:54:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="BAJsYTc/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EADA20717 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 F07E36B0003; Wed, 30 Oct 2019 06:54:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E90CC6B0006; Wed, 30 Oct 2019 06:54:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7EC96B0007; Wed, 30 Oct 2019 06:54:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id B00FF6B0003 for ; Wed, 30 Oct 2019 06:54:56 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 3418E612D for ; Wed, 30 Oct 2019 10:54:56 +0000 (UTC) X-FDA: 76100143392.14.shape34_825bd5ab69a46 X-HE-Tag: shape34_825bd5ab69a46 X-Filterd-Recvd-Size: 4666 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 10:54:55 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id q64so2088178ljb.12 for ; Wed, 30 Oct 2019 03:54:55 -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=qtCKRSOH2wHBPxYWft32/SnJnhtK6FCm3n3b1weS2iw=; b=BAJsYTc/WnEx9YqK3Q0ZjZ4NLIwdz+jXTH4YfRpJ9sI9RvhB5+3oEy4JGzzu9ikMmj JBFxfCmjslc2gcgXJ8TUmf3+BQRpjtIMcUHEHm10Dbx9leMzPLpvUiu9ddeV3+iQwLbO aVM+FYR1044gIW56sLGDszs2pmd8cDBgBBeXM= 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=qtCKRSOH2wHBPxYWft32/SnJnhtK6FCm3n3b1weS2iw=; b=l1FYR+ukA/7xuHG58Z9hB/q5KdbxfrHDeNoNNhDl+4u13u1pcu3ODTMASWaYckUoZv b6UPp+Ham6/T7vikOofpNF9Xp+2NqsT/9HQVMOnZ8frQ81CXl60YhKD1KGtsC8sUY7mi eTbxauYRtGmXDLqcHd23YUabgNEU3mLhlepEUAjupu8AFXxXy0U79MWs7MZMkFHMRmYw 2I2sYMWZyeGx9K9Nznw/oEOJ6JsorxTMKDnS7geGjAT6o7/2nzFhZSzG08G1Y98Etewe vqeI8cFZPuSn9Q+HPLKk0kaOvb/FUMxrJLQQ/JdUAkzZDQ0phTcGGuKkTJbD6R7ynmXz 0PwQ== X-Gm-Message-State: APjAAAXSM1cw4ot7jSu0p6zRnepbtkI9Rp37cNmrpnE3Zv4ORYWAJcTi iu4RBBej6P2NriHoko4kEFma4LrS+p5tgw== X-Google-Smtp-Source: APXvYqzscgttsN6b05XCmHmyKaTmQtmJoRH5MQ1hykZN+6P1KrDqqPTls8gWFDkz6SIdF1xJzSVX6w== X-Received: by 2002:a2e:4e12:: with SMTP id c18mr6443964ljb.51.1572432893442; Wed, 30 Oct 2019 03:54:53 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id t17sm757992ljg.88.2019.10.30.03.54.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 03:54:52 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id t8so1165756lfc.13 for ; Wed, 30 Oct 2019 03:54:52 -0700 (PDT) X-Received: by 2002:a19:6f0e:: with SMTP id k14mr5783119lfc.79.1572432891872; Wed, 30 Oct 2019 03:54:51 -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: Wed, 30 Oct 2019 11:54:35 +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: Steven Whitehouse Cc: Konstantin Khlebnikov , "Kirill A. Shutemov" , Linux-MM , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Johannes Weiner , "cluster-devel@redhat.com" 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 Wed, Oct 30, 2019 at 11:35 AM Steven Whitehouse wrote: > > NFS may be ok here, but it will break GFS2. There may be others too... > OCFS2 is likely one. Not sure about CIFS either. Does it really matter > that we might occasionally allocate a page and then free it again? Why are gfs2 and cifs doing things wrong? "readpage()" is not for synchrionizing metadata. Never has been. You shouldn't treat it that way, and you shouldn't then make excuses for filesystems that treat it that way. Look at mmap, for example. It will do the SIGBUS handling before calling readpage(). Same goes for the copyfile code. A filesystem that thinks "I will update size at readpage" is already fundamentally buggy. We do _recheck_ the inode size under the page lock, but that's to handle the races with truncate etc. Linus