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 B943DC47077 for ; Tue, 16 Jan 2024 19:16:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E44CC6B0075; Tue, 16 Jan 2024 14:16:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF4BD6B0078; Tue, 16 Jan 2024 14:16:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C95BC6B007B; Tue, 16 Jan 2024 14:16:30 -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 B21A46B0075 for ; Tue, 16 Jan 2024 14:16:30 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 82B1BC096D for ; Tue, 16 Jan 2024 19:16:30 +0000 (UTC) X-FDA: 81686130540.08.95BE02F Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf30.hostedemail.com (Postfix) with ESMTP id E92C180022 for ; Tue, 16 Jan 2024 19:16:28 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RfJs85Po; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705432589; 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=ZgBHmnfd7ftHo1oCGQ72PVUXCJag4GsreqtntUHFIw4=; b=Dss5zXPOmlb7DJbO1sOapD1WYUD9sXp+SVU617licQKoKDPOi2ePPANzGJmhFuW4x2TcVR FlPFWfb4zvDE4vCSBwd5tpOFXZLwo6zFQEIe79+Xur5yjmi3FYdMw5oVZ8UezpdckSoWeL t4JC+0KkxCOuHaw0r9lXd6Nh/XAMrj4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705432589; a=rsa-sha256; cv=none; b=RIEcF+BHV9Sci6gZjrqRzA7b5qoXll6x6jmA9caSULYjIWYQ7gfkV4AhucdMiXPQ1hzlUh Z/zgLdnxfYLvf31HieXShqn4OFI1+FC0bh6d6d3Z5aB0lNRZMjxH1twVjTF90eHzymdeay TFJXuaAmq5XnheLksC2hAWElHWjgvjU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RfJs85Po; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-5ff45c65e60so13901097b3.0 for ; Tue, 16 Jan 2024 11:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705432587; x=1706037387; 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=ZgBHmnfd7ftHo1oCGQ72PVUXCJag4GsreqtntUHFIw4=; b=RfJs85PoeKedp2VnQv9QTHqy2a/Qui5C7J6F7XxHp7G79KIzEfBqGkNWsprNvc31sw heHgWoi6vTIy+UWu6a7aH3SOJTMokmvOP71ef8aHPtSskxIR72rHtfl2hetE46lFqoKs UTVCV2R/9h54ICJ7T1XPprTS1K2THh8Avfc+Azt6hJ80zdVV7+wV/sCA2Wm/h6H6PKzx bLdHBXvx3dQeEnD8+BCdaNDoGGFYT+wFaCgTPdK5rQ1h0xUGaLEcvpZB4Z44AOoiTBfA LhvACIepu/xtEMylFgm/l5AhMywAEbIva7y3we5jT9aCwe+5yLl6tyxxxzCtE3phsGPe eNng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705432587; x=1706037387; 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=ZgBHmnfd7ftHo1oCGQ72PVUXCJag4GsreqtntUHFIw4=; b=e1B5Ke5s2yq0BJFaXutt9EPTDUOYfQTvQ27IrggrGh5yW1Nn/4vlNETaMSQqK04ux3 56edUZwviV7UB/pO41fqZo0TjI29eyizsX5dpTcFZ65TWzqZpF0t7cqb4Y4WY91STxsD Zh2xWV3N98Mpbn6bk1wgx8TiD90p8zao1vfX4iBX0+ZW6h1ccW8BALZpPO0d21O96iHG UwWjiofl4YXlrgq3IUWKd0wsXEdHd4mLs21hrNIU99v9U7bIo2+0zkzbB4iZBgx2RJX/ tFzEQNPnsfVbjdMEXpYKguzvtNR3srCvfj22PcCqpWAoURAmISTpriQlsfg3ax6EBJyV 4vug== X-Gm-Message-State: AOJu0YwdSPtnV8I2mY4BBmw33Cy82z6cOhPwjOJvVwCyspCR5XajY+oH Caig/l0upB29BAYiKlx/t0Ioh5ziPb/5bKY2T/wx5XCgaoCX X-Google-Smtp-Source: AGHT+IGE+FOK6HQRzkgJqrsc3p8e3hGFho/tTwQoWKzbujvJDU+6W6pENfSWZeoQafy82GNtxLC8nq3gG6yA15oD0jk= X-Received: by 2002:a0d:d88d:0:b0:5ff:4572:a30b with SMTP id a135-20020a0dd88d000000b005ff4572a30bmr1642636ywe.59.1705432586654; Tue, 16 Jan 2024 11:16:26 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> From: Suren Baghdasaryan Date: Tue, 16 Jan 2024 11:16:15 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Jiri Slaby Cc: Rik van Riel , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Matthew Wilcox , Yang Shi , Christoph Lameter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E92C180022 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rmmtkhkf4d9155ryas945zibsrk5ikwm X-HE-Tag: 1705432588-887515 X-HE-Meta: U2FsdGVkX1/jbIby0/Jot+Zv3DgzHEFce670IhY/zA1Eq5K0ys9ag9Ct8Yz5AjUcFYWy0U+XcmNKwdhjHykvoi3lAVEyoDkusWLAL0MB9s8LpxYmJLaqDWfZDqhM9uZjeXQMvw1HtwV+MJ9tibH9eXe+7pONTAzl6TqvoNFgRASJEHfgB/ggA8Q/Qy58ifOJeew8T9xCHxlgRlyMKmOo8OrxgmgvlS6k9/b7/tj9fxIKFFZXNN3DwVL75itN+XN7u1IFS5NpyLW9s5/jiA9OdTYOIFu6lXcmnr06v235OjU9nuzPtxyd1i68c8H6EL5GYgcvJM6FmzB2dqAj/ZnKosKL47mb1YB9daIRew0utXRFHmx4U7bsgUt7cBpqFZq81/CAnDI3v85fcKQNoovTOoA1ZFoQal7B6Zwos10MLjU9Xe0jQcq/RA6tB2nCFNsrIHlB5EsZ4hWE4urDNAri2jrK5eWpIEAlRh9aaTc6hVb+lL3RVCiyTmL5uyipN/yFdpYG/VJBqItl+iH3E+TQZv4P4GdFzl4tW30h5vjJN5nvAfqb3Slhjhrax+Ws/w5889lOqpjQ80UWlmfCoINuowEss1ero8cXO0JScll2Eu2rYWl31I7cJgH2Kr23MYgNS6djH7c+cdlQ35kd3Kw50TBH4fxZqstWa7bWD4x6SPIk219DIvreW3VgIQXza7q2mhFVsS+JANIivX9N/sW2MX78bx9HluCbOsO3b1FQcz8PfoHBuL+oTV2DXl0wdH0t1cQYUnIYqAA5jOdJTWqc330klFLCGiDMUKR3yTVRUSIB6CEs4DLzHy0QJx1pWW2umvsXyyhwfY38bGMKCvhro2muXjaH7z2J00PHTCnYoRkLncGj0gzEEAVjHFuC5p4ZhTSOz4paEqN6reO1Zuja9QmpnSm7N4GozIlfrfgil3ScTfGz8YmUTR0IOGR2/3+cgKgNUhr1ChKqBjlrPre sLg== 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 4:09=E2=80=AFAM Jiri Slaby w= rote: > > 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_vmlinux= .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 allocate > > 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 long > 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. 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/te= sts/aslr/src/AslrMallocTest.cpp;l=3D130 > > regards, > -- > js > suse labs > >