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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1AE0C433EF for ; Sun, 24 Apr 2022 20:24:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DC226B0074; Sun, 24 Apr 2022 16:24:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48C046B0075; Sun, 24 Apr 2022 16:24:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 305316B0078; Sun, 24 Apr 2022 16:24:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 1BF7D6B0074 for ; Sun, 24 Apr 2022 16:24:38 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E8CCA269F9 for ; Sun, 24 Apr 2022 20:24:37 +0000 (UTC) X-FDA: 79392900594.22.82D8A40 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf07.hostedemail.com (Postfix) with ESMTP id 2753340033 for ; Sun, 24 Apr 2022 20:24:35 +0000 (UTC) Received: by mail-lf1-f51.google.com with SMTP id z18so5809034lfu.9 for ; Sun, 24 Apr 2022 13:24:37 -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=8D1tjludKMiFebgWWVz4ujQ9Db5s730fW/dMT08kpsM=; b=B/znUTigREnkE9FGYtanhZgKzwF1BCsrwTatdUOzXcIQBpKPen5PEkOrDwrtwBSsa2 rxNc/brlHn+IPbLFpZls+5ZVaWqq3eLMyIZDJcMiJq1TM+4IFVA/HfkJWn6RNLs4JSqh 55EXE/t9HSnVgz4ZWkJHKOQQE73gr0ZuMmKzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8D1tjludKMiFebgWWVz4ujQ9Db5s730fW/dMT08kpsM=; b=ossO0gCpfIKlHRi6ho5Xf6lSo5N1GhrWvWWdx96meuyOgypVw/DpEhllJXGU4X4g9m TPd5xLsm5AF/GiVCrhx3LAqJc7TJHI3i1WaKk2ksGKmkT9MF2z9HMy3iWY4yMpcDFg+b 6V0hrKiJzLtAlewDccW8Q1/Lgvbj42JcKPd7iki4rR80SAULycbHZ4nXdpo1q4IPFaSh 7THy13WHpe1RzmQaPXMHRBClhzRhM5XktT/uv9etG9cYsxHRl9+vWTSLoTuh4Oj2Ft7u 6eVgrBFKcX0frmrqv5rgsmxkqxnQYykqsJnSj5tV1R9pzwWCniCwy7W7DYgjKExWu8Dc BjgA== X-Gm-Message-State: AOAM531bef+dzN31JuQe/afMfJjcJFs4AIav7b3tOPw4S6/S9oJJXdZD yg6OuDfobFaJcE1DhbBckLmbiH+MMLMw2NCASzc= X-Google-Smtp-Source: ABdhPJzQs0mI6e0V1WNpTpIMjK9LnfMWNRAWW3CQF+68qsEELN6qsm4XNbtkzxw7+2yv2ClQKto1Ng== X-Received: by 2002:a05:6512:33c9:b0:471:94aa:4867 with SMTP id d9-20020a05651233c900b0047194aa4867mr10549223lfg.356.1650831875778; Sun, 24 Apr 2022 13:24:35 -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 d16-20020a2eb050000000b002461d8f365bsm988293ljl.38.2022.04.24.13.24.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Apr 2022 13:24:33 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id bu29so23001509lfb.0 for ; Sun, 24 Apr 2022 13:24:31 -0700 (PDT) X-Received: by 2002:a05:6512:1193:b0:471:af88:2d74 with SMTP id g19-20020a056512119300b00471af882d74mr10577735lfr.531.1650831871721; Sun, 24 Apr 2022 13:24:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sun, 24 Apr 2022 13:24:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 02/14] tmpfs: fix regressions from wider use of ZERO_PAGE To: Borislav Petkov Cc: Mark Hemment , Andrew Morton , "the arch/x86 maintainers" , Peter Zijlstra , patrice.chotard@foss.st.com, Mikulas Patocka , Lukas Czerner , Christoph Hellwig , "Darrick J. Wong" , Chuck Lever , Hugh Dickins , patches@lists.linux.dev, Linux-MM , mm-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: fi8i9s6cwhh49suc8gb7iuqa61ag1ofu X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2753340033 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="B/znUTig"; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.51 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-HE-Tag: 1650831875-986823 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 Sun, Apr 24, 2022 at 12:54 PM Linus Torvalds wrote: > > And last time we discussed this, Al was looking at making it > byte-exact, and I'm pretty sure he noted that other architectures > already didn't do always do it. > > Let me go try to find it. Hmnm. I may have mis-remembered the details. The thread I was thinking of was this: https://lore.kernel.org/all/20200719031733.GI2786714@ZenIV.linux.org.uk/ and while Al was arguing for not enforcing the exact byte count, he still suggested that it must make *some* progress. But note the whole "There are two problems with that. First of all, the promise was bogus - there are architectures where it is simply not true. E.g. ppc (or alpha, or sparc, or...) can have copy_from_user() called with source one word prior to an unmapped page, fetch that word, fail to fetch the next one and bugger off without doing any stores" ie it's simply never been the case in general, and Al mentions ppc, alpha and sparc as examples of architectures where it has not been true. (arm and arm64, btw, does seem to have the "try harder" byte copy loop at the end, like x86 does). And that's when I argued that we should just accept that the byte exact behavior simply has never been reality, and we shouldn't even try to make it be reality. NOTE! We almost certainly do want to have some limit of how much off we can be, though. I do *not* think we can just unroll the loop a ton, and say "hey, we're doing copies in chunks of 16 words, so now we're off by up to 128 bytes". I'd suggest making it clear that being "off" by a word is fine, because that's the natural thing for any architecture that needs to do a "load low/high word" followed by "store aligned word" due to not handling unaligned faults well (eg the whole traditional RISC thing). And yes, I think it's actually somewhat detrimental to our test coverage that x86 does the byte-exact thing, because it means that *if* we have any code that depends on it, it will just happen to work on x86, but then fail on architectures that don't get nearly the same test coverage. Linus