Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp105020rwd; Wed, 17 May 2023 15:26:58 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7uuiZ2FiS7sPHKyJD9vXOsVQFDMv77TD+leZfGVN2PbKa/RcLqIdjoGocDhyNb4vQQn9PP X-Received: by 2002:a05:6a20:7f83:b0:100:5ddc:c6a1 with SMTP id d3-20020a056a207f8300b001005ddcc6a1mr44453373pzj.15.1684362418011; Wed, 17 May 2023 15:26:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684362417; cv=none; d=google.com; s=arc-20160816; b=yDFl9s0OOWbdu+kCc9phnT9MzQymIC/1g4LWoYHcMqJ5bH1LojLUzG+Yc7TJmQi/Sf YHERoIVer5ABj8L58/Ce3haJZNSkGg9A+fQZN4Wckb8oSCgEh2RzU6Qo55ZlHtnn+6OF +CvFhK8YNDxf9vfIGy6jUkzameq1YNe/a8umbazu63NfV4aFREdhuEfTEo8x7hlbGWkw uo8Q+9KdFkheVj25IfRXPapKgouvkrGqPknKO+/+uNkB+HboZKFVRvM76x5mhrhOfcbT hECl1pki6mbnYZlH2+q5ILK8Yciu6zDhOZYto1auvaGVww1tIT70B881EFevhceGWGu/ 3ukA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=Q9tDQnfF7TdLCx8KOF8KFg0w6OpgZ8LU6IX9uNm/27w=; b=yHvmhnplzUahmVa0/D1eGQ6xfDIwX96KYbnc+VHvwHBnCumN+kM2PkpAdkmj+PMGJK Vp28J8pWC29m+ys/09LMxCpP4T828C5yWdjtr2h2VyeNn7alTXgN/GMBGaPt86mqswUw MPWO1TuJsGt3LM1JS/O8nTJ0urNPn3q1ZdOldM1APMwWvNOgfM/vgGAMDpFGZ+MKuoM8 6tHBkMmXzSOwpPEB58Gw8USBmQM34UxSrwXsZVvF5+/RQ3MNJWbBZe13XVxy5Q0XUvoy gX3Gaokw6R9iwTWSQlw7JzMuOqT+Y/ebiL/5jgFICCzxZG/TGoPWAsSLSGz5869NgGQj qCRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=Aq61Wmrq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e29-20020a63745d000000b0053438e687basi5372527pgn.840.2023.05.17.15.26.43; Wed, 17 May 2023 15:26:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=Aq61Wmrq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229656AbjEQWVB (ORCPT + 99 others); Wed, 17 May 2023 18:21:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbjEQWU7 (ORCPT ); Wed, 17 May 2023 18:20:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C753940F4 for ; Wed, 17 May 2023 15:20:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 658CD64B99 for ; Wed, 17 May 2023 22:20:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 842E5C433EF; Wed, 17 May 2023 22:20:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1684362029; bh=NytFsz7TaWpQ0xHSi4FEPFoDMRh4D1j2c+g6k9t3n5Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Aq61Wmrq0K6xc/wL30oB3UkxyHJ6Uh9hXcZBrdPGcHI4q5pNWgufSkg5RwAAWDNoD MAn83CSWtOuNJbqAT0yyjyU4mzXMtKbDQ3OTB5r9iKHpO6HXDytYgtMlea7n8vQKkP LRBlUK9k2mYMbLsmmZ6RPvWFyz1LyUsMWhbDNPzk= Date: Wed, 17 May 2023 15:20:28 -0700 From: Andrew Morton To: David Laight Cc: 'Michael Ellerman' , "glider@google.com" , "elver@google.com" , "zhangpeng.00@bytedance.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linuxppc-dev@lists.ozlabs.org" Subject: Re: [PATCH] mm: kfence: Fix false positives on big endian Message-Id: <20230517152028.86b6d2d5afa4541b4269131b@linux-foundation.org> In-Reply-To: <826f836f41db41eeb0fc32061994ac39@AcuMS.aculab.com> References: <20230505035127.195387-1-mpe@ellerman.id.au> <826f836f41db41eeb0fc32061994ac39@AcuMS.aculab.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 5 May 2023 16:02:17 +0000 David Laight wrote: > From: Michael Ellerman > > Sent: 05 May 2023 04:51 > > > > 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 > > --- > > 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))) > > What at the (u64) casts for? > The constants should probably have a ul (or ull) suffix. > I tried that, didn't fix the sparse warnings described at https://lkml.kernel.org/r/202305132244.DwzBUcUd-lkp@intel.com. Michael, have you looked into this? I'll merge it upstream - I guess we can live with the warnings for a while.