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 84E3CC47258 for ; Tue, 16 Jan 2024 20:56:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A3406B0098; Tue, 16 Jan 2024 15:56:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17BD96B00A0; Tue, 16 Jan 2024 15:56:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0427F6B00A1; Tue, 16 Jan 2024 15:56:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E91106B0098 for ; Tue, 16 Jan 2024 15:56:54 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C5C771A048E for ; Tue, 16 Jan 2024 20:56:54 +0000 (UTC) X-FDA: 81686383548.24.A49C759 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by imf21.hostedemail.com (Postfix) with ESMTP id EEA141C000C for ; Tue, 16 Jan 2024 20:56:52 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="VPBJEn+/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705438613; 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=ZXa6+TpZrtg87/kEjfGIsGhnnsc5MTVIdja7FTE/y+I=; b=GauvMRgeWMXL6QNuWb4LkiUU5qh4Dqos0dWyj1HDmHu3fFIDFiIwNEmk8PLx6il6xTYubN Z9eSSGdd1tXBu3BJrFFbyk3XI6FFdJzywL7838sJ7X2h32Z1Mz8NP9QgugnhPuYkdT6wgm IGwk5bhX25V/UJ8AOTBN908phbu8pcs= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="VPBJEn+/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705438613; a=rsa-sha256; cv=none; b=jMjCE9yErrfVBMc/tnmSgZgyhGF8PNwM2CWp+Il1IV+WPjv526Ko3l9b4L706WEUKLZD93 RGeT9jrvYtfhydVe1sDiQ7sEgm8eAh2nfqqWGUVUL5Jicx7klnFgXTVdNfJQ+loS51nlJr QZZk73sWUdc6aJHxUf9oCHjF0DXsJvM= Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-28e81a5266aso669109a91.3 for ; Tue, 16 Jan 2024 12:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705438612; x=1706043412; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZXa6+TpZrtg87/kEjfGIsGhnnsc5MTVIdja7FTE/y+I=; b=VPBJEn+/KyOTDjZ/+lnmn+jT3J/FrmbZhfjJEhI2lR61mnZuxcf+3dwKqfuMiewYIx 0R56et/+UR4bbHDBrMXETHRWMuNenFKpa5N24qhAyUjJSa2W6+OPtLWXFYsoqYtGaZZP V471yZ8SEvyyJWnr0jbL9o/6DJSeTUfIPv1qZytB7a5uzvEbk7IuwfOe2FWT9u2ZLm+q 3iUqV8aGhQi4vZOfLEMNiBmS+Ng98i1vKlELZMcsw3nKj9h4GTPUfj2gARuemRFk7bu2 BiES3GKZ7ACJDGzpkRwHNjdge96xAZxypUi+Px+55xUOYJ3TTB57AjutjkhLy20BIh5f CaMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705438612; x=1706043412; h=content-transfer-encoding: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=ZXa6+TpZrtg87/kEjfGIsGhnnsc5MTVIdja7FTE/y+I=; b=D86/RHVDpdZpDaJS3Fum/Lox3DOQURzEAPdgfhnGgY9m+Hfvo+/RTdtDX/YnbgxWuG nD6eEvglURucFKC0wU326bz2DS8+h4n7/pYHhn/SHUJiGPIN/F4GluEBMfI4DPeZRvfx e32a+Gqx4bS806g8oO49KI+KA7nst5BbU1R4lZte1F0CzUEMCVWJz1pWlotY6ul79RMi BC/hB9SyOtfu3w6zjUfIZPc3hEx6zO3CRx4x5ODGmhzHhn1NpOJR9Qij0s2TZqKya5XE CTv0ZEahUDBhx/l5TKQAwM4XCaaCRaaMe+754JzTcZ8m4JOtH83fgOFjJ1ixDNobYOT5 1wIQ== X-Gm-Message-State: AOJu0Yw1TXD3BI9ezETClxamTSxEljGXRZYWnIFRUDhHrhoqKgikfrE5 TD8Ah+5NQWxT8m8E/W1sBICeKAoDAm3zSLIntM0= X-Google-Smtp-Source: AGHT+IHwi5fr9VKyP4HZdqlhg4wbFo7sU598VraNXGHYnq2J7Ci9/FA875680Ks7HPxj+FDyjtfAlLI+dLnBJ2PaXHU= X-Received: by 2002:a17:90b:1086:b0:28e:1b1b:6239 with SMTP id gj6-20020a17090b108600b0028e1b1b6239mr2861673pjb.38.1705438611936; Tue, 16 Jan 2024 12:56:51 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: From: Yang Shi Date: Tue, 16 Jan 2024 12:56:40 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Suren Baghdasaryan Cc: Jiri Slaby , Rik van Riel , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Matthew Wilcox , Christoph Lameter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: effs7a5gfdf6tqopydafwh3mtrdpx3ss X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: EEA141C000C X-HE-Tag: 1705438612-695562 X-HE-Meta: U2FsdGVkX18KMfCFIVSWnvbqI0B0cytJ7hppDdBWgSFi8kZUqibHayf3r2qgBovQyRzoEVVjLHvBtujJKcaM1WafJsvT+pB2yE/p7ssVssyqwpGsoO4DO7q4+ShUAZ5vI7cqabYx6T5pQoOgGXN+UAGsv56GZme3Hh5jF2dGHZm2HVXUX53cM4iyvTEobnmDpwWtqkufUGPIVPEcYJkEGnBoEgpO98RVQATeLfb/6vxj8d/C8299j2j84KKiHmlST8Okoe2gV8HcBNTahkGk1Nqpv4baxQXdDPvZla78bWEZCECpJY0znhmQJzMG0CSK+nhzNFiP6J2o97z/1X0RZ/0khiB7WKYfejT1qBp1AerXZvxslFhb5eWJ27JcVasdV93EyLwOK0K5EILI/0XXQx2rwg+E1wUI/2qTHFHQ8wR/nkzGawXRObNzlT/8Itkd1eiyt09V2n5JX9x9sLhQlki4X+KhWUs0cX+sc+gQacYfcZD2SQS3yJsj2nel/2e/GBNHqibVXBk7w2DLPW0AmdzEbM/2r6OE6B2u7l4X9Dkj0yoZXUCt6rFz7Mul6CO5TsbhYT0XMTXGrKJ9A+AVpbIXtnMv7MYq85fHAOMAmUuQtHgxFQWb//xrt+H0nd6t5DUA1JIpGQMtyDsF5Davzz5cpimEOtc7w8H5qFKQhXY5K1ATbOecd2jAhfyUwlkYOUQYBqz6TiCB6hC0DbAXwsM/DIYzOPUxDZR7/pqOC77edmtoqiDmpFWx5WwSHmbYsMYXcjl57Msrinn53QsluFw3ovOGr2hnljrdfI+Ol7YIfxjdOyqthQ/URSVbGHjRIu8NLuR37SxvSV2Kr+c8b4AsV6lsfao+8CAFZ1cf6WXZiGYosflznS/FtPiPNEm4tT0chEmORTVyRZdf2S0zfX2yiyenRKZgvuLzLOMmjlpWx8XLRGMqKa36WP8C2JXtSVzaXYUFP2eunirFzEe tG4UJ1tb OQtSH3iu9VzzNEbFWkuysDKHNLppBLgtXzuXBi1pRlWc5Hqn+5xvyY5SUzWGShwXP65v9LlCiqEcj2E5q9OobF6CcHHURKkK7CA1p4rlWGdW1C+ilBxiiIQNm48h6ygJvqU6RbfY6ZdFQGISh01HNZMVcIQctGXK9mgpNtdpUEsjRhY6PDvmnGiD3k/VqPK6Y17V0f4Ic8fCmkeIdHR+8j+yKleyA3gM+nSHdY9Jpq/IGSi1A6VG2Y8BDLUxn3tMaSBeEM9V+3jN9QBSS5kQzIMKs6/csxLEGXvPH2Wdq7uO6urk32CVIOkhpnWHL4BLT+pJjvhXD8WcfALY41+KqfaxyaiPacAdC470SlBap+GYgdbwOksko5DB8iPg03rDzLW7gvhASaIH7Pcdw2yQ/mbGmNpXMimgOaY/JW0/78pLe4D3vFgykmHgUGsOinv+m2bjppD3JEiuFMJsOrCEznBR0a/GPnMlNatLAxWd6rBEPVyqGqHOy9vSUd3YD75xYtifnE/v28e7KIDbTCfOrVRbLpOw6YHWrSS24pt1wna6jxSq5SLBjwfoTPrB5OLaypkra 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: List-Subscribe: List-Unsubscribe: On Tue, Jan 16, 2024 at 11:16=E2=80=AFAM Suren Baghdasaryan wrote: > > On Tue, Jan 16, 2024 at 4:09=E2=80=AFAM Jiri Slaby = wrote: > > > > On 16. 01. 24, 12:53, Jiri Slaby wrote: > > > Hi, > > > > > > On 09. 08. 22, 20:24, Rik van Riel wrote: > > >> Align larger anonymous memory mappings on THP boundaries by > > >> going through thp_get_unmapped_area if THPs are enabled for > > >> the current process. > > >> > > >> With this patch, larger anonymous mappings are now THP aligned. > > >> When a malloc library allocates a 2MB or larger arena, that > > >> arena can now be mapped with THPs right from the start, which > > >> can result in better TLB hit rates and execution time. > > > > > > This appears to break 32bit processes on x86_64 (at least). In > > > particular, 32bit kernel or firefox builds in our build system. > > > > > > Reverting this on top of 6.7 makes it work again. > > > > > > Downstream report: > > > https://bugzilla.suse.com/show_bug.cgi?id=3D1218841 > > > > > > So running: > > > pahole -J --btf_gen_floats -j --lang_exclude=3Drust > > > --skip_encoding_btf_inconsistent_proto --btf_gen_optimized .tmp_vmlin= ux.btf > > > > > > crashes or errors out with some random errors: > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_size=3D0 type= =3D181346 > > > Error emitting field > > > > > > strace shows mmap() fails with ENOMEM right before the errors: > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > ... > > > 1223 <... mmap2 resumed>) =3D -1 ENOMEM (Cannot allocat= e > > > memory) > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely large > > > enough. For reference, one is available at: > > > https://decibel.fi.muni.cz/~xslaby/n/btf > > > > > > Any ideas? > > > > This works around the problem, of course (but is a band-aid, not a fix)= : > > > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file *file, unsigned lon= g > > addr, unsigned long len, > > */ > > pgoff =3D 0; > > get_area =3D shmem_get_unmapped_area; > > - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { > > + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > > !in_32bit_syscall()) { > > /* Ensures that larger anonymous mappings are THP > > aligned. */ > > get_area =3D thp_get_unmapped_area; > > } > > > > > > thp_get_unmapped_area() does not take care of the legacy stuff... > > This change also affects the entropy of allocations. With this patch > Android test [1] started failing and it requires only 8 bits of > entropy. The feedback from our security team: > > 8 bits of entropy is already embarrassingly low, but was necessary for > 32 bit ARM targets with low RAM at the time. It's definitely not > acceptable for 64 bit targets. Thanks for the report. Is it 32 bit only or 64 bit is also impacted? If I understand the code correctly, it expects the address allocated by malloc() is kind of randomized, right? > > Could this change be either reverted or made optional (opt-in/opt-out)? > Thanks, > Suren. > > [1] https://cs.android.com/android/platform/superproject/main/+/main:cts/= tests/aslr/src/AslrMallocTest.cpp;l=3D130 > > > > > regards, > > -- > > js > > suse labs > > > >