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 3602EC77B7C for ; Fri, 5 May 2023 07:44:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAC926B0075; Fri, 5 May 2023 03:44:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5D366B0078; Fri, 5 May 2023 03:44:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9722E6B007B; Fri, 5 May 2023 03:44:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by kanga.kvack.org (Postfix) with ESMTP id 803A96B0075 for ; Fri, 5 May 2023 03:44:23 -0400 (EDT) Received: by mail-il1-f178.google.com with SMTP id e9e14a558f8ab-33119abae99so30023115ab.0 for ; Fri, 05 May 2023 00:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683272663; x=1685864663; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lPZVtfp6t3Y0W83bt9VDuQwkydTNBKwgjyEPJPSY9oo=; b=3CTGLUNi41774qWN2MdvThPefR+2JWAFFB3SDr72C708dur/f93EMMFzAxRNyK5Ekv LIh/Lcfrzmg8Y0JkqH/TP00YbU0LHeEL1FIXunqiWpa/BHRx1Ii+By20gB8tRnqqmxWJ 7rA2p5REb5sQET6rksFE2VvtWG6saxcb04bES43ic9H+OvnU+FnYTxvEMRhnrsEpzEN4 +d4ZYueujsNWDQ3FLG9XEtBnnqnhAVfJfQ+Y7acMxW4pEE/2cQiZQhAHohyKuuVvc9Zp rMEJng5UAwkEoqOjj0mEMPToPiltEc53F3QJiz88LavqXUJqI0b3h2RCjbQN982JfBij F5jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683272663; x=1685864663; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lPZVtfp6t3Y0W83bt9VDuQwkydTNBKwgjyEPJPSY9oo=; b=NpSqQ2uY582knkX1QqGCMSl8psOndYPpdvip6WEOKSyM7dvtf7dszlE5orRsE4cBDL kdWvJC4A2sQ/Uhhic5I+YDGUHLc0DOO57ici2PkATTByKJyoupDj1qZDKsHeQGm0tCBu GKtPtgrNoKZrlD+PMWBaN712RF1ohZpA/ZH7oB6dySzODCH50a5M3fHbT9M/aahZ9kV6 Pgi22LRTU81DpFh6s3xgVFwBNW5DR+vRBFV/Bv9nAldGFAeUFJlIps2mnOaD+tiaoGOY 21BIfebNABYM3vPjBng0RJwarzoBK9Z1QOTR8cC9b5hh+01XVOvQyPjBiPtuLt4uB9fu wnkA== X-Gm-Message-State: AC+VfDzZzKEylbpnicM/VBV2+ZuhAvTp07tpPPunkaTd0FYucaRK9bL3 AeVCr8SZU9kDZ3zgcvbkS6eL1oNtmm5CXIGYclp5oQ== X-Google-Smtp-Source: ACHHUZ4epH5CJTOlram+1GD8qTmDW8HjKYhj0AillBoub3xAs1nJF7QedWwGl/arLZNXCFh6UVEOeuHiI5Hr+RGxzi0= X-Received: by 2002:a5e:9244:0:b0:760:af65:4787 with SMTP id z4-20020a5e9244000000b00760af654787mr500379iop.6.1683272662794; Fri, 05 May 2023 00:44:22 -0700 (PDT) MIME-Version: 1.0 References: <20230505035127.195387-1-mpe@ellerman.id.au> In-Reply-To: <20230505035127.195387-1-mpe@ellerman.id.au> From: Marco Elver Date: Fri, 5 May 2023 09:43:46 +0200 Message-ID: Subject: Re: [PATCH] mm: kfence: Fix false positives on big endian To: Michael Ellerman Cc: glider@google.com, akpm@linux-foundation.org, zhangpeng.00@bytedance.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org 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 Fri, 5 May 2023 at 05:51, Michael Ellerman wrote: > > Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of > __kfence_alloc() and __kfence_free()"), kfence reports failures in > random places at boot on big endian machines. > > The problem is that the new KFENCE_CANARY_PATTERN_U64 encodes the > address of each byte in its value, so it needs to be byte swapped on big > endian machines. > > The compiler is smart enough to do the le64_to_cpu() at compile time, so > there is no runtime overhead. > > Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of __kfence_alloc() and __kfence_free()") > Signed-off-by: Michael Ellerman Reviewed-by: Marco Elver Andrew, is the Fixes enough to make it to stable as well or do we also need Cc: stable? Thanks, -- Marco > --- > mm/kfence/kfence.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h > index 2aafc46a4aaf..392fb273e7bd 100644 > --- a/mm/kfence/kfence.h > +++ b/mm/kfence/kfence.h > @@ -29,7 +29,7 @@ > * canary of every 8 bytes is the same. 64-bit memory can be filled and checked > * at a time instead of byte by byte to improve performance. > */ > -#define KFENCE_CANARY_PATTERN_U64 ((u64)0xaaaaaaaaaaaaaaaa ^ (u64)(0x0706050403020100)) > +#define KFENCE_CANARY_PATTERN_U64 ((u64)0xaaaaaaaaaaaaaaaa ^ (u64)(le64_to_cpu(0x0706050403020100))) > > /* Maximum stack depth for reports. */ > #define KFENCE_STACK_DEPTH 64 > -- > 2.40.1 >