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 8807DC47077 for ; Tue, 16 Jan 2024 22:25:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2D396B009B; Tue, 16 Jan 2024 17:25:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDD0B6B009D; Tue, 16 Jan 2024 17:25:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA4F86B00A2; Tue, 16 Jan 2024 17:25:50 -0500 (EST) 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 CBB7B6B009B for ; Tue, 16 Jan 2024 17:25:50 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A358616062B for ; Tue, 16 Jan 2024 22:25:50 +0000 (UTC) X-FDA: 81686607660.20.BC8BE7E Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf06.hostedemail.com (Postfix) with ESMTP id D3E61180007 for ; Tue, 16 Jan 2024 22:25:48 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L43NfwXq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705443948; a=rsa-sha256; cv=none; b=ynIIViAPUkxef2+ew8x/+hJCA9fVVp88psFA/Nx+zYPtXOx1X2dFxA0SLEbThTTeaE0Snz lV3eTMMbvwWgDFhJXgZ/1grB2KxDtIYBmRyf3mf4FBC8DAYcaVoHqkV8juh9h2+HA0XzuT Q362ugi0k29LGE6BlvQVopgpag8vdlk= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L43NfwXq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.180 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=1705443948; 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=LRh1CurecANVkvRJGBkdwWHI7bM8Gc7Yz61bIrES0H8=; b=i8szFm8u+6NYeYiPFRPhG1ID9SK4lEXCUTjY2AC2foT4owh0wZ8vbdKfEHKXf7uyBvayrp SNizNgA67IbbUU/jdA8IgA15Q9P6jR6/pcNHCPlrdq9CjW9vbrpZxOzm8vJfhRQ8BJBhXC jqZV7n0e41+qHW9m2VwZEJ8LK/Cn7Mw= Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-517ab9a4a13so8026638a12.1 for ; Tue, 16 Jan 2024 14:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705443947; x=1706048747; 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=LRh1CurecANVkvRJGBkdwWHI7bM8Gc7Yz61bIrES0H8=; b=L43NfwXqBgb4B5ED9moPIP5UgH0AeltimQeYfdJVZkOPblaZSgV6gc8cor8dflvxvu EQNDd0al8Z+GgVy4yjk+LltEVk/BuPSvxso/2cEMj1fCedTqtksoqdzAenPenG6a00vT Uowe5uRJkxzdii0EIa7PYlndN+gGqeC3hyOiFfojSp7Iha7gaHn/5DeHGYK4HI5dODlb ThXZG+29UXpg139Pk6A/6qcfgivhTXGnG7MYnQpBBtWJQAJqYcrkgd6CJyiSpQzs9vCe tq76WMqjQ49Vk8pBwk3WubNOPSy/vMasDeLiIyvt4Nakyq4SRpa7UHu3HxoWcPY7sMgI D1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705443947; x=1706048747; 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=LRh1CurecANVkvRJGBkdwWHI7bM8Gc7Yz61bIrES0H8=; b=nqeNcbWZFD5Bf7A5P+08vE/OGTI89edEZ+keCQ2ExwMVfeD0iBgwVwhrcOhiYDcn9t odaOqpALmKK9vxZ1oHbWnz/aHae7n5jbUV5S0JjxChQ4ASXtfC+pAJoBZiRdTtHKfpV4 Y894+ibveNGctZi1ZoBBS6tFhNMYGmBGThFrSXw46iPoOWTaQ+9cseh5kHjbkiRpGyvk KDTzWl/rVVHyR2Y8XIbiI9C/hqL7fnQlZpsEvXynxNw0trZqK7zoqT0RFkLaG5H/+GnU Z8EJ+rjBm0C55Xu7CiMr0G9Rj2toAy5Z4pLyY79eHVr9iWd9Ze99kcAC5Low/Q4iFFoS uYdg== X-Gm-Message-State: AOJu0YwSow3TbuqOcYTo62r6RK0s4jnd/vntNgO1E9+jolMzNtvGZeqY wS7X5sCImvuOQv1hazHX9488xaZbjCbx+uNVwbk= X-Google-Smtp-Source: AGHT+IFRJrXrsEiSzRZsaY2lvUUDkwVxrHV1KPZaSHGPXLa2aejHsvO36aUDAkpoOrlLhOI7KT4qG6q0aL15hxl5jmY= X-Received: by 2002:a05:6a20:182a:b0:19a:589d:498d with SMTP id bk42-20020a056a20182a00b0019a589d498dmr6840121pzb.48.1705443947638; Tue, 16 Jan 2024 14:25:47 -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 14:25:35 -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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D3E61180007 X-Stat-Signature: 6xqnqutcfazju4yy3bdch6hrwrf87wuj X-HE-Tag: 1705443948-382806 X-HE-Meta: U2FsdGVkX1+N0RON3gIyz/3xU24EhGNUzYB+5en/KeS8d395cxXyG6XiFFMGL8LuDFeXLsJxMvWyWub2KSNTCP+KWRr0Tnf19noVvWn8wm01px9IREx4oLArRXJHG8IA7oki2ym5gNLuSBoMzp+qC4tHZsDp6ZqopcoFLnqHfz8Uswz796lN0vMUvD7qH+lOhYKwhspItasxcL7meqYciBd4aySFkUuIAg74ge/Taz6fPRgMrN52p+Ofw0Pxj9UMdZN4gndEeSM8sDu1zqMD4iyBJkb95t4KAQrpVe9eibBahkW1a5U6qhCp/d4KkDj8a2ch0rz3/5EY6EATCCVoO8lz++mYCh5729qcrv+1+V9wIVq+IplFmo6+7smvRHBWhu9EmuEQZhWW2OX9ivvGyQGICoPf/IM205pEq9elOM+/dXpTDbRjRRVDjKRIgf5x5nYjA/ijtfciiJ4jjku38UHFsVf416LLwHR6jTzMlE7Myo3cc28mbFNoSmjkrTuslvTg6No33SlKNlNp79FiuHdkV7/80bah/aWZqj6Zf0yTa0ih1RVeq1ezIqL66N1A8DneNL/lKXWMKbcPh6TdJLn6ELj8+cyRoQWO0PL2eEf5snEwgpIqsC1u/wUnLzL4WqVH5aSkTZR+c7Sah44lQRZWpvxWSlRVSqoe5T4tL7asI3ySsnhf7aFQiEBJ1SJyK5GL8X7Ua4hlzrKxl2Uv/FGBCz8mQYMrfwTEHZ9nDKg5zS8AKSPjgL1XNOrWWN0xRPIgowEr7YlJpvewC3kMt3Ixi9VeiX0InYYtMTKgYXT/wkYrTBAsfNbjCtZ/D8CSVDUCHro6N/FgA+DNlCVBtfiUOkR51uyhzuUD4OKfzi43FFORLwVe984C0AIabD4zwWXkK3K8WYXjYFobkY+qanCDZAYmxCYUQ4DXmQUZ/G1GMcPq/Wf4Wr1CyqKNXXK5n7PYdWk6vnte+k039Un Z3GY48o/ j3vmAFYh0oRYsWraKEO1Ruw8L2gO3J0SZ11ZlErNBHvim5VjTDMoS7OP0gIMYMHVE01MOFw/1RlivG7XxtHB9H/Wbmnox58RCEuDaH39lyrzfpWKkl+0Vp04bfZ9E4GTvYs9b7LrtvpEM1Ti8dDud+FBpU81mye71CAlrXVpUAQ/473p5vydI8MrjvTePm3OGRO6qRvi/G2ObwhxDTBQGaKUK0ulPRYIV9GB99qRwTKpg2EmCIO37rPHq/WfuazesZjCiQY4oA+qrg0rBI8WgW3soLJGwu6I1Mw7sk0vQODZFiAhAuulx553qUxZ6g2D3Wp+1W3m31hf6n5hCGJeUNUYuIOh1j2fAtmoqHUpg0U1eYf6WV0UxUQ0dOrH2xM5KShkwOrTb9nJPEyzh7g0Pz3LcKlfoSfpKqywT9cSGRcSC8d6I5fgMRIa+Y2a7diImVnOA5NTqbSdRFK2saWvUjwoZLi9SBpylzPVy1XPwDO8pYEW/7/Jr+5ge1BHmUAlBlLXlp16VVvJL56+rFa7BLuofmTjreR2JBdC4tHYxhGwL6r9RNlVhdOsVZg2x2R4XGtjsRICuGPwJle2AEd9ic79L2k5iXrvd/fQV 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 1:58=E2=80=AFPM Suren Baghdasaryan wrote: > > On Tue, Jan 16, 2024 at 12:56=E2=80=AFPM Yang Shi w= rote: > > > > 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_v= mlinux.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 all= ocate > > > > > memory) > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely larg= e > > > > > 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 fo= r > > > 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. IIUC this breaks the "expectation" for randomized addresses returned by malloc(), but it doesn't break any real Android application, right? So this is a security concern instead of a real regression. I think we can make this opt-in with a knob. Anyone who outweighs security could opt this feature out. However I'm wondering whether Android should implement a general address randomization mechanism instead of depending on "luck" if you do care about it. > > > > > > > > > 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 > > > > > > > >