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 48375C433F5 for ; Sun, 17 Apr 2022 20:56:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49D796B0080; Sun, 17 Apr 2022 16:56:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44D3D6B0081; Sun, 17 Apr 2022 16:56:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2ED5F6B0082; Sun, 17 Apr 2022 16:56:46 -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 1D5886B0080 for ; Sun, 17 Apr 2022 16:56:46 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CBBB52402C for ; Sun, 17 Apr 2022 20:56:45 +0000 (UTC) X-FDA: 79367579970.14.5F2E6E5 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf30.hostedemail.com (Postfix) with ESMTP id 5B5E880005 for ; Sun, 17 Apr 2022 20:56:45 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id x33so21668621lfu.1 for ; Sun, 17 Apr 2022 13:56:45 -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=DsyxLgNrrlFcEa7Y01Ulqliiz+Bkxw84zt+8RzzuZRo=; b=WXRtYH3k6SxBF/y/KFw7kiV8oQU8icffy4o+sluqUWmZ1tbNBig1mFI9GYeGtGdw1y uFQCY6mv+8o1UtvYz8mD/ZEpob40zlS8W5FIjQpHXzi0UUzCLQuiM9oWDenMmppAdKRb GmYRYlbNO68MYyq/zyzukR0j04JB6zUHJxzO8= 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=DsyxLgNrrlFcEa7Y01Ulqliiz+Bkxw84zt+8RzzuZRo=; b=Oorzu/6OFqZdQULw3QPmtDKx/OtOUwOfqRjPeI5S9t8qWlV0qsuH6mWviOJSnm7YUZ 4pvCC7D6OS4WMWkk/4cnWNKFq1pwoun3vdXBfONxyn+EYU32XAwC5dVxSxcMn8i9ew/i /iECnw7uDlKcriVuWDcB+Mg0M2jcEYO3fRZTeSzLq9y+FuHZeCGuAQkB5lknbsNLUxFJ Of0AEE0ZWyeJuocTwGYo+ZUiVTwPrlYtjNsjCwCPE6ortOj8ZjEudt1t48+i8IA0CnHA sLWwecmqCBOrhWDxUV+FvLEQQcNe8xWNyZ41jPCTtt9NujfIiPqVy0/dzMKI4IE4s8Lu IxmQ== X-Gm-Message-State: AOAM530lZdsJEiRKPdBwW4+amfA5ua8lMsp9jAiLc99dUUVWg6jibZl6 jXrNCUfz8gCKYAqtulJTQ3IEQIkjoobNwU3Z X-Google-Smtp-Source: ABdhPJwSq6zjeJeO8KuhAE8nxUy+qtgqvvLg93NE5D0aW8BvsutAWXSMZ//InJVT9c7hRn2N51GwCA== X-Received: by 2002:a05:6512:2148:b0:46b:be29:5563 with SMTP id s8-20020a056512214800b0046bbe295563mr6109606lfr.347.1650229003130; Sun, 17 Apr 2022 13:56:43 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id x40-20020a056512132800b004489691436esm1024187lfu.146.2022.04.17.13.56.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Apr 2022 13:56:41 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id t25so21622394lfg.7 for ; Sun, 17 Apr 2022 13:56:41 -0700 (PDT) X-Received: by 2002:a05:6512:3055:b0:44a:3914:6603 with SMTP id b21-20020a056512305500b0044a39146603mr6024068lfb.435.1650229001342; Sun, 17 Apr 2022 13:56:41 -0700 (PDT) MIME-Version: 1.0 References: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org> <20220415021328.7D31EC385A1@smtp.kernel.org> <29b9ef95-1226-73b4-b4d1-6e8d164fb17d@gmail.com> In-Reply-To: From: Linus Torvalds Date: Sun, 17 Apr 2022 13:56:25 -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-Rspam-User: X-Rspamd-Queue-Id: 5B5E880005 X-Stat-Signature: b9y9nhwrgd71qat4pe3hymsgcpdm856f Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=WXRtYH3k; spf=pass (imf30.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.54 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam01 X-HE-Tag: 1650229005-994472 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 17, 2022 at 12:41 PM Borislav Petkov wrote: > > Anyway, more playing with this later to make sure it really does what it > should. I think the special calling conventions have tripped you up: > SYM_FUNC_START(clear_user_original) > - ASM_STAC > movq %rcx,%rax > shrq $3,%rcx > andq $7,%rax > @@ -86,7 +84,7 @@ SYM_FUNC_START(clear_user_original) > decl %ecx > jnz 2b > > -3: ASM_CLAC > +3: > movq %rcx,%rax > RET That 'movq %rcx,%rax' can't be right. The caller expects it to be zero on input and stay zero on output. But I think "xorl %eax,%eax" is good, since %eax was used as a temporary in that function. And the comment above the function should be fixed too. > SYM_FUNC_START(clear_user_rep_good) > - ASM_STAC > movq %rcx,%rdx > - xorq %rax,%rax > shrq $3,%rcx > andq $7,%rdx > > @@ -118,7 +113,7 @@ SYM_FUNC_START(clear_user_rep_good) > > 1: rep stosb > > -3: ASM_CLAC > +3: > movq %rcx,%rax > RET Same issue here. Probably nothing notices, since %rcx *does* end up containing the right value, and it's _likely_ that the compiler doesn't actually end up re-using the zero value in %rax after the inline asm (that this bug has corrupted), but if the compiler ever goes "Oh, I put zero in %rax, so I'll just use that afterwards", this is going to blow up very spectacularly and be very hard to debug. > @@ -135,15 +130,13 @@ EXPORT_SYMBOL(clear_user_rep_good) > * > * Output: > * rax uncopied bytes or 0 if successful. > + * > + * XXX: check for small sizes and call the original version. > + * Benchmark it first though. > */ > - > SYM_FUNC_START(clear_user_erms) > - xorq %rax,%rax > - ASM_STAC > - > 0: rep stosb > - > -3: ASM_CLAC > +3: > movq %rcx,%rax > RET .. and one more time. Also, I do think that the rep_good and erms cases should probably check for small copes, and use the clear_user_original thing for %rcx < 64 or something like that. It's what we do on the memcpy side - and more importantly, it's the only difference between "erms" and FSRM. If the ERMS code doesn't do anything different for small copies, why have it at all? But other than these small issues, it looks good to me. Linus