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 F08C6C433EF for ; Sun, 24 Apr 2022 19:55:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 39D286B0074; Sun, 24 Apr 2022 15:55:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34CB86B0075; Sun, 24 Apr 2022 15:55:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C7546B0078; Sun, 24 Apr 2022 15:55:20 -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 0DE096B0074 for ; Sun, 24 Apr 2022 15:55:20 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D299E1D20 for ; Sun, 24 Apr 2022 19:55:19 +0000 (UTC) X-FDA: 79392826758.27.1CF09BE Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf04.hostedemail.com (Postfix) with ESMTP id 13AE14003F for ; Sun, 24 Apr 2022 19:55:15 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id bq30so22887061lfb.3 for ; Sun, 24 Apr 2022 12:55:18 -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=LLHrC18vqO4mAkzdZZc8nx6SJWE+jfgShrpAIINRfoE=; b=EdsexeSGCi4k+MyrihuimqWCq1Wu41k8sNbO7+/sbse2JMHu0Iv9yNxRjmA9oZYxE+ Orvp/Y/ct3CmG6lrZ4yp8YX79dWSC9Oef/kSYIBtDo5AjFMU5RHfs1pwXYhW2ddthYpB a/NKPJjwB/aNxIQQPCcuct2n9voSoTmgtvA0g= 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=LLHrC18vqO4mAkzdZZc8nx6SJWE+jfgShrpAIINRfoE=; b=phCPY4bLDNXMcX6i1+dTjl5J0jyYJxgytjuLenUUsSQsZ5nCp1El9+SYbJ9RQCyi4d JfcaNudCJFUUYpVK/4eqA+2J2oHKY4thEhhS/dihN3Tb/Fu5RPaZUZOxW7NCkZKEPr7B utRMBC9SaA72tb8m2htog8df35VgSVm5GAGtBzzWOgWhwuqmj1qkMbk0a69M8YneEfYz zZpQmhqZUfElpWZVC6POO9AjHkmmBtX8M2RAS+82iW/8aKg2plswOx/2cGOY6m5TQmiP dROvjjpSk+tty6Oc/IbRkLcSUFJEAgzf9XPtudItxU1G9SRoyZhjTfouc8/BFNzczLVZ WT6g== X-Gm-Message-State: AOAM532rXoMt195bC5D1UtSD6KLGG/USHO+jtGKNAWJlOXDL3H/YeBpt /1g4Ycb1GxvZv04LUMt6T0cAiz+pUlUQj/BC X-Google-Smtp-Source: ABdhPJzlijOabernQfekd4hgf55m9J5CDls6fDbLcgz2lxKOGdDTHn9wZfT9SdSV16TQ1bGjSRWyUQ== X-Received: by 2002:a05:6512:12cc:b0:472:384:ef0e with SMTP id p12-20020a05651212cc00b004720384ef0emr2177443lfg.407.1650830117270; Sun, 24 Apr 2022 12:55:17 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id a2-20020a19e302000000b00471988e79cdsm1121705lfh.180.2022.04.24.12.55.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Apr 2022 12:55:15 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id bn33so15512074ljb.6 for ; Sun, 24 Apr 2022 12:55:14 -0700 (PDT) X-Received: by 2002:a2e:934b:0:b0:24f:cce:5501 with SMTP id m11-20020a2e934b000000b0024f0cce5501mr3034323ljh.443.1650830114045; Sun, 24 Apr 2022 12:55:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sun, 24 Apr 2022 12:54:57 -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-Rspamd-Queue-Id: 13AE14003F X-Stat-Signature: a4yy3rxagd19yra6sngbsro355q1c31y X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=EdsexeSG; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.42 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam09 X-HE-Tag: 1650830115-979080 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:37 PM Borislav Petkov wrote: > > You could give me some more details but AFAIU, you mean, that > fallback to byte-sized reads is unnecessary and I can get rid of > copy_user_handle_tail? Because that would be a nice cleanup. Yeah, we already don't have that fallback in many other places. For example: traditionally we implemented fixed-size small copy_to/from_user() with get/put_user(). We don't do that any more, but see commit 4b842e4e25b1 ("x86: get rid of small constant size cases in raw_copy_{to,from}_user()") and realize how it historically never did the byte-loop fallback. The "clear_user()" case is another example of something that was never byte-exact. 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. > Anyway, I ran your short prog and it all looks like you predicted it: Well, this actually shows a bug. > fsrm: > ---- > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 65536) = 17 The above is good. > erms: > ----- > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 65536) = 17 This is good too: erms should do small copies with the expanded case, but sicne it *thinks* it's a large copy, it will just use "rep movsb" and be byte-exact. > rep_good: > --------- > read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 65536) = 16 This is good: it starts off with "rep movsq", does two iterations, and then fails on the third word, so it only succeeds for 16 bytes. > original: > --------- > read(3, strace: umoven: short read (17 < 33) @0x7f3ff61d5fef > 0x7f3ff61d5fef, 65536) = 3586 This is broken. And I'm *not* talking about the strace warning. The strace warning is actually just a *result* of the kernel bug. Look at that return value. It returns '3586'. That's just pure garbage. So that 'original' routine simply returns the wrong value. I suspect it's a %rax vs %rcx confusion again, but with your "patch on top of earlier patch" I didn't go and sort it out. Linus