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 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 A22C7C432C0 for ; Mon, 25 Nov 2019 17:13:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D51320674 for ; Mon, 25 Nov 2019 17:13:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="di9eo39C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D51320674 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 D78026B0003; Mon, 25 Nov 2019 12:13:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D02546B0005; Mon, 25 Nov 2019 12:13:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCB2C6B0006; Mon, 25 Nov 2019 12:13:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id A2BF96B0003 for ; Mon, 25 Nov 2019 12:13:40 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 59A524DD5 for ; Mon, 25 Nov 2019 17:13:40 +0000 (UTC) X-FDA: 76195446600.25.farm59_2b4027e37415 X-HE-Tag: farm59_2b4027e37415 X-Filterd-Recvd-Size: 6054 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 Nov 2019 17:13:38 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id d6so11666988lfc.0 for ; Mon, 25 Nov 2019 09:13:38 -0800 (PST) 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=IP1wfK3f8gL3K5of14NSdEE7VLJRLmDh9Mjfd6jLIUg=; b=di9eo39CEUbDhJQGDGRbvoBzSIsf4IsJ2vpQB30wyKTQ4oZuoI8I8FAMQktMgORFFP 8fBVLWpCUhdrhl0hj+dykFizgaSzPbdXAW3q2epeOP6k+UZ1g4c/aPYroPhY+MX/X+vS wBXrAbq1U0ohLCJc7HXm2ySYQ4bv4evW0kCik= 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=IP1wfK3f8gL3K5of14NSdEE7VLJRLmDh9Mjfd6jLIUg=; b=fhHBnfzl++EeiQGNfTj+mrpTEzhfAVkNUiNsxZBMzp/LnKdG4A0HdrigRemBhOA+IG 4VC8f8wGlmRrl78I+iQhee/utI48DN1hplx1cBi9CwER6RYKvze/3GBck70fkNyVmqZp VuLDsy1CFCDF1kIWsVlW2uhTK7/2gQa2+s9XsYOAExI4IW5zibFRE3caCdqfJxFLAit3 L59qwewSvT+LewGql8gOkUyaLYmT/3HAGKWlF4VycAbwvTBpQLFFAlPiel8/NXl/+Fd0 4rAM0gOH2HRw7FeIdo9jHutDsC0l8kWtUiyr98i2O29oxF0HDijy0NYUk7Z548+K8jXX TpzA== X-Gm-Message-State: APjAAAX6KXJlsPXb3rMcSTLtBy8dL6bnqM2ZXTk6EXvbAfh4ddJt6zcY QXpGq3HC8pwlLY3TjQkPKhnUsOZ1IsI= X-Google-Smtp-Source: APXvYqzYRhX/M1NBfiF50T5uW2h/HwEbASmfswtIrTVR+c9NAOBNF7KW3j+nDQCKpfNxlWrIz3nc0g== X-Received: by 2002:ac2:5464:: with SMTP id e4mr21389287lfn.47.1574702016246; Mon, 25 Nov 2019 09:13:36 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id n30sm4400622lfi.54.2019.11.25.09.13.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Nov 2019 09:13:36 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id m30so9793317lfp.8 for ; Mon, 25 Nov 2019 09:13:35 -0800 (PST) X-Received: by 2002:ac2:5a08:: with SMTP id q8mr21390671lfn.106.1574701545622; Mon, 25 Nov 2019 09:05:45 -0800 (PST) MIME-Version: 1.0 References: <157225677483.3442.4227193290486305330.stgit@buzz> <20191028124222.ld6u3dhhujfqcn7w@box> <20191028125702.xdfbs7rqhm3wer5t@box> <640bbe51-706b-8d9f-4abc-5f184de6a701@redhat.com> <22f04f02-86e4-b379-81c8-08c002a648f0@redhat.com> In-Reply-To: <22f04f02-86e4-b379-81c8-08c002a648f0@redhat.com> From: Linus Torvalds Date: Mon, 25 Nov 2019 09:05:29 -0800 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: =?UTF-8?Q?Andreas_Gr=C3=BCnbacher?= , Konstantin Khlebnikov , "Kirill A. Shutemov" , Linux-MM , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , Alexander Viro , Johannes Weiner , "cluster-devel@redhat.com" , Ronnie Sahlberg , Steve French , Andreas Gruenbacher , Bob Peterson 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 Mon, Nov 25, 2019 at 2:53 AM Steven Whitehouse wrote: > > Linus, is that roughly what you were thinking of? So the concept looks ok, but I don't really like the new flags as they seem to be gfs2-specific rather than generic. That said, I don't _gate_ them either, since they aren't in any critical code sequence, and it's not like they do anything really odd. I still think the whole gfs2 approach is broken. You're magically ok with using stale data from the cache just because it's cached, even if another client might have truncated the file or something. So you're ok with saying "the file used to be X bytes in size, so we'll just give you this data because we trust that the X is correct". But you're not ok to say "oh, the file used to be X bytes in size, but we don't want to give you a short read because it might not be correct any more". See the disconnect? You trust the size in one situation, but not in another one. I also don't really see that you *need* the new flag at all. Since you're doing to do a speculative read and then a real read anyway, and since the only thing that you seem to care about is the file size (because the *data* you will trust if it is cached), then why don't you just use the *existing* generic read, and *IFF* you get a truncated return value, then you go and double-check that the file hasn't changed in size? See what I'm saying? I think gfs2 is being very inconsistent in when it trusts the file size, and I don't see that you even need the new behavior that patch gives, because you might as well just use the existing code (just move the i_size check earlier, and then teach gfs2 to double-check the "I didn't get as much as I expected" case). Linus