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 C3EC7C47077 for ; Tue, 16 Jan 2024 21:58:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2693C6B009F; Tue, 16 Jan 2024 16:58:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21A6B6B00AA; Tue, 16 Jan 2024 16:58:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E3176B00AB; Tue, 16 Jan 2024 16:58:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EAA176B009F for ; Tue, 16 Jan 2024 16:58:07 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BF18140A43 for ; Tue, 16 Jan 2024 21:58:07 +0000 (UTC) X-FDA: 81686537814.23.A12CDF2 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf12.hostedemail.com (Postfix) with ESMTP id 0F36140003 for ; Tue, 16 Jan 2024 21:58:05 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2WP8SzUI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705442286; a=rsa-sha256; cv=none; b=tAMQUlwOwh8IAo1YMYrXCzPuK8g4C1ZvDrfC2la6PjTlKkk0hGkeahIP4z854xRRAfYWPg BihVAz4rrYM46dW56UpSKVDuvJXJ95hvbZ/JAcjfFvoL6Qu0KItXX6KY5Te05VWYztA7J4 TYQV3BBwMTkLZsNHo1km6c7b8RP3j8I= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2WP8SzUI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705442286; 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=y5EIKchs1VAjD0fWApUQn73nGGFLSeKVzKK9a2evomA=; b=PNVbe1wqW2Frsk5OxpJ99bPXa/hHBQbvkeZtp0IDiyfy6sOQVF2LFhFHjmzdZgCCJvE5EM k2uAedJLwz90W0gfPoUjG6ZA+ulBPRoronwMHLOxDcNuiLzvPuq4A6dJVKkIWbiT78ku72 hhf3TI+DNbrpA81MLa6R6JatjU5YH9M= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-5e54d40cca2so79404457b3.3 for ; Tue, 16 Jan 2024 13:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705442284; x=1706047084; 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=y5EIKchs1VAjD0fWApUQn73nGGFLSeKVzKK9a2evomA=; b=2WP8SzUIdmEsbXMkJJ4ooP0Y51tX58VjQ5RONUH3wb0uLIaWGwoYR4uNyaCfqGM9dO w51A6Dj1rrugiZbDDt3KmZQr+4lz7B67WM7VBtLJyrKHDnNzEzWF59NpvIpfRzSwrjI6 AGil8j6ztRm2d52LAnDBLgsTvsrzRqjqfLEWLuupevQt2vdoIu5rlmXsomG6pe+2vHEJ ySITHwZHgxn7TTeun3Y1pqUxcA778k5myIq7+rG7qfi2EYZQrvqclayORtZD4ErXPfNt DL7pEWjhwHiO2pJTmxWbQ4zOAA52vhI4ZQDFkf1ZqmMmkHOy+10c3okQY1zVx0eWDqZO nhkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705442284; x=1706047084; 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=y5EIKchs1VAjD0fWApUQn73nGGFLSeKVzKK9a2evomA=; b=JAXi6tyLuweAqnHpuKtEq3aU5DRe2/+ISrfSNbGvgBUKM+KoAJ3UCNwxTq7R/x94Ph zqmBzQ9VYsNVK9n34/tZNGiI5Sdu0dMIFjPnHl1+nPV6+oG6uxF4m/S9v9qTKo56ZIjI GxsM+TYbtan0VIwPKXd6muSdv1Vy4WIyJBrVG1AGJRRw118jaGWq/MYUqyQpeh4ai/y0 +HxiCQXGW9BomTV8lvnCZxC+tpWyFSvxFvFc1/DUU8moFj8agxVc0Ro6G1iQRgLoBEgf tvbOtrl7S7Z4Rw0AsTRLLDyPaOPO3YxZGQUN1kkzUBSRuCggMiZOaV6wbL8t0dMibR2u WZ5Q== X-Gm-Message-State: AOJu0YxScvcB2Wj6lTlOSGh0k4mDobCrBvppiCnB026HpuK8n9zKQ2CV RsoePNwU+zE7KYkvt5iDbnOpltX0dPxYZNpvxZ6TR5tMGea9 X-Google-Smtp-Source: AGHT+IHSLdmfAQB+KscAa57I8uCekxyfrJgKP+h7BH6GjVSJQ78/sUgcmCZzKsgN5EU0XNpmXTZt0KvdtCvKOA9VOTI= X-Received: by 2002:a81:57c3:0:b0:5e8:e0c7:f8d7 with SMTP id l186-20020a8157c3000000b005e8e0c7f8d7mr3956417ywb.93.1705442283734; Tue, 16 Jan 2024 13:58:03 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 16 Jan 2024 13:57:51 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Yang Shi 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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0F36140003 X-Stat-Signature: g5uxrom5sopwh9ceidwg17mrneu1mbxq X-HE-Tag: 1705442285-535673 X-HE-Meta: U2FsdGVkX1/3Zc0UFSNnTmiaNheS9FLTt79QE0VRGeVre79e6MjUOEcYtykcmf8H0JTKbeENe/vGbh7YXe3ogBKhYQ8mIO0JZh8N3w64lOP2b0Q7DaJQoSXSMxVf0S0nFbukfoMbIUEJOInVy+MZr8XIUotTKUUeyfkpiY6Np9+WdSr3GYsLiuXWQcBs2+nwFIf75W72d/pfFwCOdMr87f+VV0cUcYB+X29vA+4sQm5BkUmV51lL69v1ESyUFLRWb3T1Lj7s+go/BnpCaFPrvWFcp9P9e9faJWc5F3JYgOaOst/pHAu6UIQTrzNIZy/9EuAEOg2PhJ8d7W+tBgUGrbpNlk9KSEYpDp+z60sv7SjRgmqZz9qT9ivVaXxvmAxbIxrVS+kEZLNN0sWmMbgTQ6LWxh1e+iFKttdohO1oQMwcQwzhbKVsi60iTiJ/PO3qwZDlsIb573pcQbykTydi+1JsNMDanvvUjcqh89u/qddHxR1kgI8tKfs48R3udsmAP/Tr/Bk+4Sudu4vpbOAujU7NAZYzJrSj6abrm77d5k6QyzFs2/clv4RZKgZicUpU8tx4qnJtaAMTSqiPziin9nBBLAyOXODC6Apl4MYbAy3Kr1DzcmdDJXlH/KqZdInDalEmQsnWfoJcVrByM2TMp9lwI/WkCWbVLuPS+B60IqT1pTHm0Rc37u0G91idiRQYBgkllMYtgCgCQ3omxkQ3jwyOye1iB+yweKCjZtjKpqWgn4p5N4qzBorw+47rljilhsz1Wf1s78FMxhI1oVBb6B7wcb0WNHiE5zJ1UTQfL3LmHkB8TqWCM9/em3jzqTlLJmvxJSX602eyCIKI6O+GQNAjdykUJ076hmGf3F9WD/Wpyr3YkMNqePUF3raOevRuqvJ2vqq0mW0SdnJlsHMrJqVt4j4TAf6cnaMT35Bv0DOd8N1gggduWicLv7HKA+i2OX8f9n/nzH9Hf4Urb6U RK9ym72Z JP63sZ6Hfid46885q3wzwGUqrQ4lRym4GErz6tYV1ItRDxOZfHOs+O5kvnSgK7oOK+h6IZqiK3BssIJmcb5KTNwF0cvp/OjOKXX2MRxMepFQgI10xd+ejkOcTRLjXk03uQypd8xT/EdUo7+5JQSWq5IvwNa9whHzyQHl5AdRTUMIq/3WfRLB31r0ypm95GjPiLHDhgvcwieleVVRvcwUf9iaaMNYfqNx7laXv/mIpedqBWgFediY5IYA2zFRKGISwQUmG7LNp1Jkw2V72emc0MiTaG7eqNua2/YkQEzSIQuQqoihr7Wu9viCflxSF0tc9EBwyCvGdU0rWXofQy//0ykWNc310fiZ2jsezQrDo+4mHVRc/Q1Gnke3dSlnrJdZoT22dWiDmce90r8topcUTm/dLFryHh7VGp2ZPFtw0VyZWofZExLAE+sjQdU3hDfKeZMgIcpt9SDO2RDfxTS6ZNmTs4Ia+3YEl/rIx 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 12:56=E2=80=AFPM Yang Shi wro= te: > > 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_vml= inux.btf > > > > > > > > crashes or errors out with some random errors: > > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_size=3D0 ty= pe=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 alloc= ate > > > > 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 fi= x): > > > > > > --- a/mm/mmap.c > > > +++ b/mm/mmap.c > > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file *file, unsigned l= ong > > > 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? Yes, correct, the test expects a certain level of address randomization. The test failure was reported while running kernel_virt_x86_64 target (Android emulator on x86), so it does impact 64bit 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:ct= s/tests/aslr/src/AslrMallocTest.cpp;l=3D130 > > > > > > > > regards, > > > -- > > > js > > > suse labs > > > > > >