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 A968EC77B75 for ; Fri, 19 May 2023 06:30:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1749900004; Fri, 19 May 2023 02:30:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC5BC900003; Fri, 19 May 2023 02:30:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A667D900004; Fri, 19 May 2023 02:30:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 950FF900003 for ; Fri, 19 May 2023 02:30:57 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 570671209BF for ; Fri, 19 May 2023 06:30:57 +0000 (UTC) X-FDA: 80806031754.20.952BBB6 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf29.hostedemail.com (Postfix) with ESMTP id D802812001F for ; Fri, 19 May 2023 06:30:53 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=inB3dteE; spf=pass (imf29.hostedemail.com: domain of bgray@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=bgray@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684477854; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Nfs66LzAnHvE57Xngnbd2IkZW7oKWssPmRiExjFJzfk=; b=FjPDXZRMtAL2o8zVFMo9+ZCKGnPqwbAWxFU6+17YpSFRBTTpMP6YvUd49l60ClU+NJnVRV e+etnE5B9uaH5t16nPdOPnt1BZ7q88aGkzz/oHaWU+ImsqBaZ+HMPPmCzxrPsHowJ/EHi8 XYAENUEZbv9254XR2hUZLs2CeK8S2og= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684477854; a=rsa-sha256; cv=none; b=vuxJU0WpAJ8aT75bUuECiCQlD+zpdTHLzEQmHJpQqBgUb0YztXo3StbrvcpIKE1JXOTglI NFz8+5FLqZRCOVzD/jTMyXbv1PWVo9wqqOLRQ9BZnbnf2ELP+nleRpl6gNZeoo7DzYmiZu Ro6EhvUF5+EaEseXyMopgPUX07in5Es= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=inB3dteE; spf=pass (imf29.hostedemail.com: domain of bgray@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=bgray@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 34J6EjlJ028489; Fri, 19 May 2023 06:30:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=Nfs66LzAnHvE57Xngnbd2IkZW7oKWssPmRiExjFJzfk=; b=inB3dteEUEKMgzA6LbKk+fSk0LjAKZjmf3QG5CgePkH3eBC+oC9n9Rp6c41sggminxvD 18g8QPL2MB4K39Q1gR3VKQxn99C7+asuun+ihRfvmUuhjyjqW8l1zhn+WTpAiUPsSF2E F34/LgKYw4bxapDDUY+JX2O+zwJPHvsnlR8kH+DehtT8N2qFAFAQUFE/bYn5G01ZWkB0 JwdT3N6k/PWTeGwSdvlKEXm8fNzkeAeAaIzVdvRpYRWKafggM0N3dS1/o+Si0dTm4YrW RqJaR6nV27x/mjUTSunbh/L2GEHvdp6ONABou8bG7Rn4Qix/86QgMW99jMIqP9zHj7lD zA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3qp2vysen6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 May 2023 06:30:06 +0000 Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 34J6GPOI001298; Fri, 19 May 2023 06:30:06 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3qp2vysej1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 May 2023 06:30:05 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 34J3tih4031373; Fri, 19 May 2023 06:30:02 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma03ams.nl.ibm.com (PPS) with ESMTPS id 3qj264u139-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 May 2023 06:30:02 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 34J6TxZ010420934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 19 May 2023 06:29:59 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AA2420043; Fri, 19 May 2023 06:29:59 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5D27220040; Fri, 19 May 2023 06:29:58 +0000 (GMT) Received: from ozlabs.au.ibm.com (unknown [9.192.253.14]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 19 May 2023 06:29:58 +0000 (GMT) Received: from [10.61.2.107] (haven.au.ibm.com [9.192.254.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.au.ibm.com (Postfix) with ESMTPSA id 514E2600A8; Fri, 19 May 2023 16:29:55 +1000 (AEST) Message-ID: Subject: Re: [PATCH] mm: kfence: Fix false positives on big endian From: Benjamin Gray To: Michael Ellerman , Andrew Morton , David Laight Cc: "zhangpeng.00@bytedance.com" , "elver@google.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "glider@google.com" , "linuxppc-dev@lists.ozlabs.org" Date: Fri, 19 May 2023 16:29:43 +1000 In-Reply-To: <87o7mgzyw1.fsf@mail.lhotse> References: <20230505035127.195387-1-mpe@ellerman.id.au> <826f836f41db41eeb0fc32061994ac39@AcuMS.aculab.com> <20230517152028.86b6d2d5afa4541b4269131b@linux-foundation.org> <87o7mgzyw1.fsf@mail.lhotse> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: p0t0azZCbbe8nBx9wVLF6WwuwZif2W3Z X-Proofpoint-GUID: 2e0BP1duRbj9IgAbPgXGuR7mm33ijuw0 Content-Transfer-Encoding: quoted-printable X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-05-19_03,2023-05-17_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 adultscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305190052 X-Rspamd-Queue-Id: D802812001F X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: xmw44myci79jw6dgmkeeqg7x13fg7hkn X-HE-Tag: 1684477853-373717 X-HE-Meta: U2FsdGVkX1/hB1r2RPIb953Z5sLvwUYjJvug6c+dbpLOlw0eIzN8qdszJ6w5bIZWXGkbJzLp89Dj//a1qRyjSbvx3LJVAkMFjyrD++vVCxDrhJ8LpdR2Q3zSv9706kkPhzRXkztiu/SpNA4ZBaR5IaI5XqKnJS5iZ7IxhnpxY1w+oYZ2ea+sY33kxqO4725LL9oggWbrW45vTMITht/X1Rz4E17Zjy0QNGuOdljecPLeT2o3gJjJ6Jt5qqYbJdPNO9uaNXrHbF4TaEuH67ir1wm3OF5mAB/JF5xi/svYybFDjFuCULQJHg7nxiolBqxScUOaEEk1hAJyouJbJkmEVz0jT3CkyiuWOyjxiG/4W+BzNoGAeiGnhFwNULM6BF7cxy1uS1spFqRHpiqghOSa7giOhynkxS2LTl6Pswh4IQQULF/pmWdeYCErdNn5iHlZzWWOSIW3v2DCVD855N7wQo0TMOxeL4UxJnTB3eMN1RqfP9jRc2CkIwqQIfTaiWbesYaCe3SCxX9q6VMfb23XRsdPQXLsypOukpToM2bGl3fX+U6RxoDlsm9YpTo/XNUUwcYQvp+M/hVQm+NgZ1yRJUdP33kPAe6Z551dv49yvC66BfInTGSRAwOvh1u2cjOfnHyNJ1xqjmJ1lVxuX09q4t+rUL8SNNjGSIzIhQjyjAn6F7wZiqFnv7NbAiNYQJrYwy2hI9WuEAQ0WduXobcw+yvMpyTLsDxckAY3eenQO+xKyyCAv+wIMbFQDLZYiQewGXdWBVL2aeV2gx6nPTT7QcZJleyGBo7+xHV6mtOHnkzpQ0Fi/ehkJEJJFi7x2jtlFeGrYl4cz2uhX7Oratzmm46PZQ6Gta3R9w6pHeqZcfjQE/J9hxMVwivSG/3ihZ1GhM5Kgt7BdfwyqMJN7V4CyDuwRuZPzUQfSTDugs8jR8v8PBh6x5YepKmhNwoKUgmfduKZbw6ucCWYx3cWRxM hIOBtCi7 BdShblt2BZgpc47NP+QA5PZth5KEa1dOnx3jQvA5c5ufshB0PUL6yiK//hqir5l1FHg98mFa6PbYaxY/ljKvBCS2fdA6+nLy0VCJhPXbX230KNf5DPBB1c2ckyNhdGyA6wz2DXZmhDKVpPfWeCaeTQmj5NpwJyWV5I/bNdQHlqFpYbN0PBy7YjV+MGQSMtdjoKAJnp9qNgHJyjT46xs03GCA6FJsO7zZzi3PS9KE5KvjEUfY7grHXA/B2nSIH3yBWrQ41TjMagFB7n7A2Vv8s/s/N+gSPN2JWFLovPUrQSzl9Gzs7dpgO2AwCI6PySxNlMXVu83LWDclr0U2RwLrNZsMqpMRh/YO4x+DXlMBNuFAEuQa2UKxUwGoRCHKnPf3yNn+9SRUQT1ws76QYwL7DPzUElvlwrmwa8ycS 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, 2023-05-19 at 15:14 +1000, Michael Ellerman wrote: > Andrew Morton writes: > > On Fri, 5 May 2023 16:02:17 +0000 David Laight > > wrote: > >=20 > > > From: Michael Ellerman > > > > Sent: 05 May 2023 04:51 > > > >=20 > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > The compiler is smart enough to do the le64_to_cpu() at compile > > > > time, so > > > > there is no runtime overhead. > > > >=20 > > > > Fixes: 1ba3cbf3ec3b ("mm: kfence: improve the performance of > > > > __kfence_alloc() and __kfence_free()") > > > > Signed-off-by: Michael Ellerman > > > > --- > > > > =C2=A0mm/kfence/kfence.h | 2 +- > > > > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) > > > >=20 > > > > 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 @@ > > > > =C2=A0 * canary of every 8 bytes is the same. 64-bit memory can be > > > > filled and checked > > > > =C2=A0 * at a time instead of byte by byte to improve performance. > > > > =C2=A0 */ > > > > -#define KFENCE_CANARY_PATTERN_U64 ((u64)0xaaaaaaaaaaaaaaaa ^ > > > > (u64)(0x0706050403020100)) > > > > +#define KFENCE_CANARY_PATTERN_U64 ((u64)0xaaaaaaaaaaaaaaaa ^ > > > > (u64)(le64_to_cpu(0x0706050403020100))) > > >=20 > > > What at the (u64) casts for? > > > The constants should probably have a ul (or ull) suffix. > > >=20 > >=20 > > I tried that, didn't fix the sparse warnings described at > > https://lkml.kernel.org/r/202305132244.DwzBUcUd-lkp@intel.com. > >=20 > > Michael, have you looked into this? >=20 > I haven't sorry, been chasing other bugs. >=20 > > I'll merge it upstream - I guess we can live with the warnings for > > a while. >=20 > Thanks, yeah spurious WARNs are more of a pain than some sparse > warnings. >=20 > Maybe using le64_to_cpu() is too fancy, could just do it with an > ifdef? eg. >=20 > diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h > index 392fb273e7bd..510355a5382b 100644 > --- a/mm/kfence/kfence.h > +++ b/mm/kfence/kfence.h > @@ -29,7 +29,11 @@ > =C2=A0 * canary of every 8 bytes is the same. 64-bit memory can be filled > and checked > =C2=A0 * at a time instead of byte by byte to improve performance. > =C2=A0 */ > -#define KFENCE_CANARY_PATTERN_U64 ((u64)0xaaaaaaaaaaaaaaaa ^ > (u64)(le64_to_cpu(0x0706050403020100))) > +#ifdef __LITTLE_ENDIAN__ > +#define KFENCE_CANARY_PATTERN_U64 (0xaaaaaaaaaaaaaaaaULL ^ > 0x0706050403020100ULL) > +#else > +#define KFENCE_CANARY_PATTERN_U64 (0xaaaaaaaaaaaaaaaaULL ^ > 0x0001020304050607ULL) > +#endif > =C2=A0 > =C2=A0/* Maximum stack depth for reports. */ > =C2=A0#define KFENCE_STACK_DEPTH 64 >=20 >=20 > cheers (for the sparse errors) As I understand, we require memory to look like "00 01 02 03 04 05 06 07" such that iterating byte-by-byte gives 00, 01, etc. (with everything XORed with aaa...) I think it would be most semantically correct to use cpu_to_le64 on KFENCE_CANARY_PATTERN_U64 and annotate the values being compared against it as __le64.=C2=A0This is because we want the integer literal 0x0706050403020100 to be stored as "00 01 02 03 04 05 06 07", which is the definition of little endian. Masking this with an #ifdef leaves the type as cpu endian, which could result in future issues. (or I've just misunderstood and can disregard this)