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=DKIMWL_WL_HIGH,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 3A8E0CA9EC6 for ; Wed, 30 Oct 2019 10:54:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CBA8A208C0 for ; Wed, 30 Oct 2019 10:54:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572432899; bh=9dXBQTNelP7YGh565AlkMr+9JlOxUXuYZ+QCaMPcqbk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=UbaPnTefktQvuRn3ErSylMQtCX71FmTtzsviaxyWabh7/+60OK6fBlAJcK2bwr4Og NGXqGpdxonWqMEHxiovNCOgBlingqI55/iKsqlv8jQIPGL5IxW5LJ7t1cqGPJ23sk7 YaD+MjGDq+o0mqZzYNUTH0RURUG13RRSPcu/E8CY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726804AbfJ3Ky5 (ORCPT ); Wed, 30 Oct 2019 06:54:57 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:39371 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726566AbfJ3Ky5 (ORCPT ); Wed, 30 Oct 2019 06:54:57 -0400 Received: by mail-lj1-f195.google.com with SMTP id y3so2126301ljj.6 for ; Wed, 30 Oct 2019 03:54:54 -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=sVbBCF3q9LMa0w0/+KiOjIUGUS0EqsXLu37+AMFhrGqbocTNGuDr9IGeYSbRT09HD9 s0uemNQIZ696J4wr20sIkgOdJRVThjesySYQWmN1DQbIQnC+ouSzFu1a2wr6kmhS5L6h yRvtVWrUtKsGE5wEUky7lfTRt2Rt5WSlbjueraos8FYKSPqc3tq/tKMTJ0HA2IVV51Fe 72yMKhmJ0XCuBT53zLQGFiGsvRNlFm3bT92yXmakTBmMOtxofloEgcBVIrX2fdVun4wx jVmtFCFw2XCE6JTYaaW4MrIuuGV8XOWWzieLUsW3USmcu6Hv9iQexjM0ZENgnwsEOi77 hIEg== X-Gm-Message-State: APjAAAWYDZLNkVe/rXcZADGbKViXKOtka5mdHUarew/IiLXKhP6SqUOa xOOb3wHfxX4jQbZPAyXgwQK5EwfekhDnCA== X-Google-Smtp-Source: APXvYqzlrxz6OvI5qiirGT+9aeCbYm9ozkft74/bIBWGSMinG+aDx6N17cJLhwck1sZpQq/XLlG/fQ== X-Received: by 2002:a2e:b5d4:: with SMTP id g20mr2343697ljn.140.1572432893395; Wed, 30 Oct 2019 03:54:53 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id g25sm923539ljk.36.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-f44.google.com with SMTP id f5so1197546lfp.1 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" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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