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 F3EB2C77B7C for ; Fri, 5 May 2023 07:15:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38B5B6B0078; Fri, 5 May 2023 03:15:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33BAC6B007D; Fri, 5 May 2023 03:15:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 251346B007E; Fri, 5 May 2023 03:15:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by kanga.kvack.org (Postfix) with ESMTP id 080986B0078 for ; Fri, 5 May 2023 03:15:08 -0400 (EDT) Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4409786dab8so461783e0c.1 for ; Fri, 05 May 2023 00:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683270907; x=1685862907; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=N202Ijuno3Me5YJcbX3ewbYmNhi4YhDxuel30imfLFU=; b=ui9HE+plG5qgwjxWNuLdm9H4SsYL7slc73hg6yxo9gAHavkaxcJb3z67jG8bpI+b5j qWPLL14Yp5dVlZkYc9x/Al4w85+ya1TiVO4mErjuFGn6OhFgXGjk69wE3wxNEYp/0p// EYNvArp8JT14PtWg1MsfkgaqT97P9xxX7HC3yARHFM4vXA444rurRE7ldw82XLcAbFcW kqMnXqQ6bQCwGEAdmArcjoFjCCaiTBLAx4rlqeNN48rVXqfNx1EpJV60uJ+fMvd8UZ6S aZ+z8rKB8Qe5Rr019h90HTlwMOCg+2RE17hyTPNQWXkhHDt8KZ7Ozh5fHJBPpLcLcXVv kDcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683270907; x=1685862907; 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=N202Ijuno3Me5YJcbX3ewbYmNhi4YhDxuel30imfLFU=; b=aKFOdHqh5WXTd12FjXpvn5KWTX4o6oQ69ldEn+EeuHp7fw8hS1isSVPA1ctuKlxQxT mIDWQdu6yJE4+q/4P6lO2py9KmNDRbMDRqvVIyafr0SKiXr45i9BM6h20ic8IuCdB3+o 3wWqFA9utvRqwuCUDJIcf8XpzP0L7AAmFZMEx2huyQwBtAk2WQsEBLEHfxyhdENIT/PE cbvYCc2DK50XOnOCCZsg6Lx8bYKKx29TLePqAw4HDMH6ZRDDUVCGzacA7kGVAGGvHeDF s/h8YyG/L0O2zwD3hm9yuScsQ9XjrCTof5jum+evgSrh8Mepm3USmd3k8eVUnV5YjoXn xVlg== X-Gm-Message-State: AC+VfDxEFsG/s+LgFwY3re2IxN9IRr5JyoKBxseHFw0v8Ss1R/amMUot pSC9zYjnxA9eRhDPEste7KLZVl7sDmzzcZSnt0Sgxg== X-Google-Smtp-Source: ACHHUZ68ekcoEwkwg7QDBjpoDjZFUlLQ4BVP56EPnRRb/YXb9/U9BEdw5tIh/x3jYpeB03KJ05SbkUWIqztR3rE/znA= X-Received: by 2002:a1f:bf52:0:b0:44f:fa0d:d346 with SMTP id p79-20020a1fbf52000000b0044ffa0dd346mr164456vkf.5.1683270907166; Fri, 05 May 2023 00:15:07 -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: Alexander Potapenko Date: Fri, 5 May 2023 09:14:30 +0200 Message-ID: Subject: Re: [PATCH] mm: kfence: Fix false positives on big endian To: Michael Ellerman Cc: elver@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: multipart/alternative; boundary="0000000000007c0d3d05faed0c2c" 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: --0000000000007c0d3d05faed0c2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 5, 2023 at 5:51=E2=80=AFAM 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: Alexander Potapenko --0000000000007c0d3d05faed0c2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, May 5, 2023 at 5:51=E2=80=AFA= M Michael Ellerman <mpe@ellerman.i= d.au> 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 <mpe@ellerman.id.au>
Reviewed-b= y: Alexander Potapenko <glider@goog= le.com>
--0000000000007c0d3d05faed0c2c--