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 63603C3DA4A for ; Tue, 20 Aug 2024 01:49:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECE436B007B; Mon, 19 Aug 2024 21:49:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7D126B0082; Mon, 19 Aug 2024 21:49:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF7406B0083; Mon, 19 Aug 2024 21:49:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A59CA6B007B for ; Mon, 19 Aug 2024 21:49:19 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4047FA7DDD for ; Tue, 20 Aug 2024 01:49:19 +0000 (UTC) X-FDA: 82470941238.05.ECDBF6B Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01olkn2106.outbound.protection.outlook.com [40.92.62.106]) by imf13.hostedemail.com (Postfix) with ESMTP id 18B5020014 for ; Tue, 20 Aug 2024 01:49:15 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=outlook.com header.s=selector1 header.b=JpRu7o4B; spf=pass (imf13.hostedemail.com: domain of rsworktech@outlook.com designates 40.92.62.106 as permitted sender) smtp.mailfrom=rsworktech@outlook.com; dmarc=pass (policy=none) header.from=outlook.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724118452; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vi3HX3ekQK7lQQfhaICrn0ZdD0e/nTlwTIexqD7DNEI=; b=sBl4GVq7tK9JNAhNxNBGyJ1FbnEDzhpJMHEJ60dEE+MGOnfyHdcDTPx9IdnedPEMURX5hx HCOawkgn3NLejMJ1J4YuHKHs8taqU++tT/0Mq6bGyC8eKb9z6kfIWwjUN+oHRo2DQA+AtQ Q2t2z2DV5g4To10yQuYo/kHW+tu1eR4= ARC-Authentication-Results: i=2; imf13.hostedemail.com; dkim=pass header.d=outlook.com header.s=selector1 header.b=JpRu7o4B; spf=pass (imf13.hostedemail.com: domain of rsworktech@outlook.com designates 40.92.62.106 as permitted sender) smtp.mailfrom=rsworktech@outlook.com; dmarc=pass (policy=none) header.from=outlook.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1724118452; a=rsa-sha256; cv=pass; b=7FmAcMXDWvCgwzAYehDppzKJ2oxKwJP/MdO94W36/cYm78C7S8kVDIMn9L00HSuWiLb/c6 yn71lHJO2ddi9MfYypmr7UZzC/mSc7f7la3mPd4DV9Qy7Z7uLkIU5NRyLAcd+l6JRrSm4K 8UnVyWPx6cZfFPSIeeN1j8VXgt1GELA= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wP3yoY3AgN6JQ6USST9BmP5v1/VIMVtcxFeYruQbTnCpjlh0WeB+hVNyuOGpFdyL6XciNtYmbHaqu2ZjZeL+u/L07MB0H1WUZD/zYQ+Vr7wivt+3DNJFgmMm8HL4QGpHNUF2+4BR9d+Q9tq6n3pTA2R3z0MuM6PTXAKVrXjf7uDK9zxT4QPxMYLg+ccO4oWhMZsl8GlcdPbAWOutpUyg8DJQs/3+FPSktk4vI+YWOMCp9CA2ypxVVIM7eLas8KZqQAA4GTFr/zCeKlbF1UXpL8xE0V6EDCSWOJueE65rVSNcfcSl8bosBiIxU91hRTxgqadXLxPrUTLLfq93NpbsAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vi3HX3ekQK7lQQfhaICrn0ZdD0e/nTlwTIexqD7DNEI=; b=Y2imKr2gG7n2gbbyEH2PKODu260OYGQdy2dxOjrj20a+PALMNMMokhNvp1lh0pnHGDkReYGG3ea967GqX7RnpBfbaWH7RaCAqvWKWgtKA1cL2OpvdxT/R1g59ewV9vap/56aONe7R0heosc25kQNaXx8ICNn9iPfZo9D4nHAy8HC18DynsZZpOhyE1w5RGuosR5mV0+FxKMhUw6kzPXzGl6O/EzIfjpy9MalR2ylsKxh2wkoQdEIa2abBGwnQ1lRgV5lKaHNWIw+mxM2R+H0UTV3Bkb2w+I4IrKt1lSZkjL7LQkbAScUgmYk9ROxwC9JZoociiCKFTyFEQloudnNfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vi3HX3ekQK7lQQfhaICrn0ZdD0e/nTlwTIexqD7DNEI=; b=JpRu7o4BsX7f4ew0zpnvSUEXeXst6p2iqGxLHNttRDyxA90buFPSMK0JX5o2ajuacm9QZBfZL6ASj1KjIt4mBCIasBzEU8inW7I0ZAuNC0h56lVNPLcALGHx5+kOyYmAYXK0N9VxrkqJGq+CKRK4/Au4ZwDk/ZGSHT+r7ZCmXQB77DsehNBI8v8j72nYx30pe+xYcVS3BeXteWWq36n0prcBMvIcD1qgpg7Wdv67g8ruEw0ykGHZW1t6PtzWFbu5ntQupqcXPfp8QWnWwq+zpG9VTfFogFFrr2TCYyhyr7MivePfaBKzcpRTVOGS5ThT54YM04st+HLoR16ZeSJ8Kg== Received: from MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:ff::9) by SYYP282MB1983.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:de::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.20; Tue, 20 Aug 2024 01:49:04 +0000 Received: from MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM ([fe80::6174:52de:9210:9165]) by MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM ([fe80::6174:52de:9210:9165%4]) with mapi id 15.20.7875.019; Tue, 20 Aug 2024 01:49:04 +0000 Content-Type: multipart/alternative; boundary="------------mwugVDVVD20kUkyXDmG0E6Hq" Message-ID: Date: Tue, 20 Aug 2024 09:48:50 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available To: Charlie Jenkins Cc: Palmer Dabbelt , cyy@cyyself.name, alexghiti@rivosinc.com, Paul Walmsley , aou@eecs.berkeley.edu, shuah@kernel.org, corbet@lwn.net, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-api@vger.kernel.org References: Content-Language: en-US From: Levi Zim In-Reply-To: X-TMN: [VB3VA/7kXECq794J+cOuXsXGkeRQfUQ0Rhvbt1bEkDdvZUlHLqgOAt4gHK6JCftK] X-ClientProxiedBy: SG2PR01CA0122.apcprd01.prod.exchangelabs.com (2603:1096:4:40::26) To MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:ff::9) X-Microsoft-Original-Message-ID: <8ddb4df0-dbc3-4880-bb44-f7827be037d1@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MEYP282MB2312:EE_|SYYP282MB1983:EE_ X-MS-Office365-Filtering-Correlation-Id: d06c919c-c8b4-4862-5f04-08dcc0ba456d X-Microsoft-Antispam: BCL:0;ARA:14566002|12050799009|461199028|9400799024|15080799003|19110799003|8060799006|5072599009|440099028|3412199025|4302099013|1602099012; X-Microsoft-Antispam-Message-Info: lSmzPwbiHEuFAx96RUneAiyNcYC653+RfszkcQwcVrIviH0jq0l9BJzxb8Vt4Zk4yaZQ0lteCFygY0O+bNOwXzyJSy+p7n8up1ayX0jY9b+LrWmCpIkx6o6UBCG0BTj9yhTZgSbyxqTiwAN924EIzYwwI6N+r/J4L44lzavTN3PU2/on4JkeheQas88lHKnEKliRXn0srotcytrJZE+76mRYkyP4mli3BpjiaGXjxm1ZeY3KkX4cDLit5tYBbhf1NFPHoqBTwyeoWFHTBsJDmPWeBMN+Ze6mIh7bYf8ITAvWIkIs/Kqfuh8kBRmi6T/QbVULLfTcV1QDizgD9Fu3gtfuQ58NRDXmknNb83VFE+pTU4cMh4OcDVaGHhcCWT0dNa+v9DqOtGc5zYZ9c2cwtcAWz/gnvMmI+Zt+F6nuTEYeRmIWLX+8mWcUXZMPtVobNoyhigTl68tPDD+8aLUP8O1wZb9qdhOB/CTZYdSdBQFA/6T80u4cWRDZ0/2JayRAuw6KG0hfH2u3Dqy8GDM8xH05Ad14ZARhzotrzX5+mYfC282k1/fQRiofkvluLOP0ENOZnsKXLn5ep8G5WFV5G05nHa03iPEvbd0NzqYjMT/S7fmQI5Ln2nrt5mLIEzfWfaAdNtgHi4vSPqoCFVljQL+boO5+JRvF7/X2K1ccvR8gWgCH4KER2Uec0f19O3SpUAjxarELpuMXFEBvJZ9ML/tLDR40JiG4HU0RWrknKAOQBANfKtqAmT/7FUjDA3l7+R0icb+2nsRb0gzadx8+KkXOOv5vYlSp0iT5eovrXfFCHq7aV1f+3FYLqTsMxjnMpfjfGYb/VDG2F3r6YL8CdsRG4PEekQOVMb+rDwcNNmHTYl1vb/jXlx2nMx1/PJVi X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WDR2WnR4dkFHMlBYbHY2bFpCSjR0NzVkc0NuczM3ZUhMZGRIcm5ZNk1ORnVh?= =?utf-8?B?RFUxUXV2NHJ1ZForL1ZsMG5IYVVoS1hybGRwSXAxcXVhWFk3Z3I5eFQweExl?= =?utf-8?B?ZnBLQk9TSVFicXJraGloR05JMWFPVFRKMFpuMkw0SDQ3OEowSkkzKzhSMWVV?= =?utf-8?B?U2tqcXRMaE0vN3htVDIzWHVsNmg2c1JJaWVZcFArdGhDWGxHY2lNa2dxWVls?= =?utf-8?B?d0Y3SWxXS2dJVElpa2dQUzQvSmJ4L25WdFdpaHNqd1lmTHEveGE1NzVRUUZO?= =?utf-8?B?WDREcWEzekdOS3p2bFA4dVJnZk9vcDhyY2o4d3R1QXJseTFpMFd2OUc1a2Jp?= =?utf-8?B?YXh0Q2xRaWs5MzFOSXdMNEp2ckIzQ0RsSlRRcFBzaTU3ZlR0SmhyS2pRVXRL?= =?utf-8?B?bkxRZ0tUQjZEL0V1OGVxMmUxc2krekJ0dVFJN1I5cEdJZHJ5WTIyYXlRRjZE?= =?utf-8?B?RGR1eHY4N00yWkhZVXpWREg5b3IvUzBjU253UVB1TmtQdHEwdlJXSzE2dkdE?= =?utf-8?B?SHl1NHlKWnIyWXpoVi9JYm84QUlqR2lqTzFKdlhYQ2JJU1Q5d000NXBUMDlL?= =?utf-8?B?VDNVdTZnRUhPNHM2cmlrT25MTW9NYTYrb0gxd084ZXdtRlRtZDJTN214ZUFF?= =?utf-8?B?Zm8wRnk0ay96SDc4RFlLSWcwbkNDWVRDMDdKU29MMUphR2VxandxVmh3UTlp?= =?utf-8?B?VmxxNktsZkFPUkdvdXBxa1UxUmlnbmpnOHlNQ2Z3MHZCdEpBY2RpRnFUTld5?= =?utf-8?B?c2k0RTZMWm9yUGtXQTNhU3RvYVVnVzloOUtIYzJ6bkFtcHpPampEOGhnSFR2?= =?utf-8?B?dVBWZmRua01XbkVwS3o1dXo5SlRaYmVHMy9PSmVlWWNGc1FNUkNvNTI2dkpy?= =?utf-8?B?NFlEVUpVTmYydDJ1WDE0UFhEd0xmbWF0Y1Z1YlpuYWkrczhQYVNhUzdQdlFG?= =?utf-8?B?OGpyZ2Z1aDVrd1BxRDdrdWZvU21zbDRDWXZpbURzMTRrWGJFUlpaclpXb0FF?= =?utf-8?B?a1NSQTNNb2NzSVRyRW1TQ0RFam85WXltYVpRazR1dGl3Q0I0bEw3RFgxRGlr?= =?utf-8?B?dllBWDZBTkdwZXNtTkt4UVVBNGRHNTlpVXFwVzAwbElINGZEc2xHeVRhQTNL?= =?utf-8?B?WDNtcjg0QTJwRVlBWWtyZjZpck9yZUZkZXRGWjViZkl6V0lVWE1GVDg1aUlQ?= =?utf-8?B?cFFPa0VIZjF2dUlWaVFNTUVWbS95ckFIMDJtS2doZldkdWlVNGl0RmFwZW4v?= =?utf-8?B?eXVKb0ptNUJVUEhsbEFDSkhkU1JsL3pOclpWTGFUOExuUUhsMmtpSS9ld2Mx?= =?utf-8?B?eU1YbTV6ZlBXc0c4bkZVRDcxcWNvVFEwMXo2MUdrY1RKTEY1ZStvMGJHTWpE?= =?utf-8?B?OVVwRFNuR3ZKN0FBdzNZUndIdC9USHhsdWorNnAvck5DU0ZXNEg5RVIxQXMw?= =?utf-8?B?MlkxbFYwTU1lS1JoVW1JYitpSnVlRVRuditEUmEvNWVGMFJNaDVKd28rVDln?= =?utf-8?B?WkdRTEVWYTlJNUpCdUtLclNyNmJMM2hWSGtSekEwYXlQTkJsb0licHNGMXJn?= =?utf-8?B?SHRjaml6bmdNKytEUFFGT2JnbnFnVFhoV3RrY292Z0k5YjNTdm1Td0tlTGJu?= =?utf-8?B?Zkh3N1h3YXd3MGF3YnJqa0NBNlhLclNZeU55Ylg0a0xTWEpiYmhPRGF5ZTIv?= =?utf-8?B?U0ZVeDRxTUNaQmYyb1VEVGlEeVNkZW10R2lnRXg3U2xzaUM4a1piQWgrNmNq?= =?utf-8?Q?BUV0qzLik1LJ4AZ6JJv8kR7RXLvrpzy0pn0Y8eK?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d06c919c-c8b4-4862-5f04-08dcc0ba456d X-MS-Exchange-CrossTenant-AuthSource: MEYP282MB2312.AUSP282.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Aug 2024 01:49:04.4949 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYYP282MB1983 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 18B5020014 X-Stat-Signature: jsib5psob4enffur5zuuianxnspgx4s7 X-Rspam-User: X-HE-Tag: 1724118555-450605 X-HE-Meta: U2FsdGVkX18UVU+DpyIsXuPue27XtU54yrgV4aD21P0P9F39pmwTO7/oCimKsVZas1egqv3ICRZU33Ik9PAIVm/ktv4UAcnU8+vbsyPAZV62ruo5OqvfDxDp2qK+9w7T7nXB0qn8Ypuail1HpbvJFhK8duOTBCLqo9isPSDOvS0AI51y1tH1NkxVhwxEyEXTXCgbk+PQvN8t98DqoiN3aa0/wE8x2siB8W3JS043jSaYbEj9uCV7lKNNI5LWjACY8P+9lq9qdKZWNqmPnNFbdpPByZPVGe63X2N2FyLJuYbq29BqHBKW3/ieK+EwJbhZLteN3Xv0sFs1KbJDoWKFUuDYs7nrbwY25AzCQE63R8ASWd31Fufg7TuVWkuKV884mYkIu7TN583MGi+dofoXWA55OF93ULPvD168q7ltqTSB2xmNgiTO8/ehWeaZkWt7ZySeaqI0bwGHo28MV1WaZFioHOnbMQ37wDEOY9bnTvvfE7TQ9e7MJt4fvNowJHNx9D5Yv1qeanlI9biQBK3V9LIcqOfhqJxFKgH4X7VqbtdRIii4veGnmliyvO+ALx60w2rOjFVwhwtWUtPYhczoKy56FlM80B8jyOyw5/WcWMgPmHo/wyeQs/BRqE75Ctbh0l2UVY2Lt12YP+in/b06scS4hc/Yqdbd8ldN34MOEp/fgXwVmy8P+DGt0bw4Sr4sV+Pl2FCZVgX5zlS1s2eerhnnC5iuW8kJkE9k98ox+iwgJfEUNjZfToNkWMzA/ijEdROoM+MtwS9g5EHc1hOjgkwKNkGag21TBZ2MDqZUNXyU95zo5QKZxUGz1kghAvYkWWT/GKOj0weRkLhEmpQrVXgZEdIAqsI/R1sXTR8pykJwFRf2ritr6lb/F7+1C5Tpx7kTD66kVgRaUEqzL1UIIJByJUcc5wRf9EtVyzzMYRWGdEiX27OeUR9qUKzP0x9cBWcxr8arTExtr8W3uuJ d9N+kyZo omFa23L8BQJoJccT2MNk5cWUldClUHv5HI2BeAoZ6Xqa/55W5XDZoMQ2K60dXgUzeRVt8kHQ31R6VnKNBY8P612cs+8xF8sudQcIClZV/wWwncvWge4nSXF79Vij9Ce6JIDBzwqzvFpoXbR7ABvDo/Ap8xj75CEBhTkeyVKtwBDT+qzISu14lf3MlgOeNRRBdgyXwUvPbjuyQJkNyTR2mSo6eUXJmi/2YbEbzUg5ib1WhdBV5glxltze9B2KUCg7KT4SZ2eCo/VAQ1J/9yt4VvvINCqboLAJwHR2StIZY6i9PzOwNmZkpaMWETefMacMQ8pyFpY12kQja2R/7lqpktbMkRVjVSej9f3yIeDhMPxsr2AfVLks3B/5RKubY8UoYQPPE6LVDnhAnV7mO1qVfHPppM8W9jLxrGnD8pcScI3+qSjdPcDEZtp+ViNAzjXmMlS+eV3viT1EziuZR5QiylUmL+I4vcjXTIofmOPujPKF+XXMYCXkum8QzV2RmOh0cUoiMsm2vaMXMlNnlr+VETWoPG5cVj5cd5eTjLO7xq+Wmbs9AxJqgYCbiWK/pwUbklGKE9EWxLNQ13ZfYcO47isGn+b6ufzbXmfHqcpdwom+7gAyii1GdRTK9hSPjHddQqpSlb7GuJDSW01tXsDg2yczEFrLlW3NfEbZTJCIlgBsxHZpG28xMVwyk93HNe1pYdcPU1JVmdflFMV0= 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: --------------mwugVDVVD20kUkyXDmG0E6Hq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2024-08-20 01:00, Charlie Jenkins wrote: > On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote: >> On 2024-03-22 22:06, Palmer Dabbelt wrote: >>> On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote: >>>> On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote: >>>>> On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote: >>>>>> On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote: >>>>>>> On riscv it is guaranteed that the address returned by mmap is less >>>>>>> than >>>>>>> the hint address. Allow mmap to return an address all the way up to >>>>>>> addr, if provided, rather than just up to the lower address space. >>>>>>>>> This provides a performance benefit as well, allowing >>>>> mmap to exit >>>>>>> after >>>>>>> checking that the address is in range rather than searching for a >>>>>>> valid >>>>>>> address. >>>>>>>>> It is possible to provide an address that uses at most the same >>>>>>> number >>>>>>> of bits, however it is significantly more computationally expensive >>>>>>> to >>>>>>> provide that number rather than setting the max to be the hint >>>>>>> address. >>>>>>> There is the instruction clz/clzw in Zbb that returns the highest >>>>>>> set >>>>>>> bit >>>>>>> which could be used to performantly implement this, but it would >>>>>>> still >>>>>>> be slower than the current implementation. At worst case, half of >>>>>>> the >>>>>>> address would not be able to be allocated when a hint address is >>>>>>> provided. >>>>>>>>> Signed-off-by: Charlie Jenkins >>>>>>> --- >>>>>>>  arch/riscv/include/asm/processor.h | 27 +++++++++++--------------- >>>>>>> - >>>>>>>  1 file changed, 11 insertions(+), 16 deletions(-) >>>>>>>>> diff --git a/arch/riscv/include/asm/processor.h >>>>>>> b/arch/riscv/include/asm/processor.h >>>>>>> index f19f861cda54..8ece7a8f0e18 100644 >>>>>>> --- a/arch/riscv/include/asm/processor.h >>>>>>> +++ b/arch/riscv/include/asm/processor.h >>>>>>> @@ -14,22 +14,16 @@ >>>>>>> >>>>>>>  #include >>>>>>> >>>>>>> -#ifdef CONFIG_64BIT >>>>>>> -#define DEFAULT_MAP_WINDOW    (UL(1) << (MMAP_VA_BITS - 1)) >>>>>>> -#define STACK_TOP_MAX        TASK_SIZE_64 >>>>>>> - >>>>>>>  #define arch_get_mmap_end(addr, len, flags)            \ >>>>>>>  ({                                \ >>>>>>>      unsigned long >>>>>>> mmap_end;                    \ >>>>>>>      typeof(addr) _addr = (addr);                \ >>>>>>> -    if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && >>>>>>> is_compat_task())) \ >>>>>>> +    if ((_addr) == 0 ||                    \ >>>>>>> +        (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) ||    \ >>>>>>> +        ((_addr + len) > BIT(VA_BITS - >>>>>>> 1)))            \ >>>>>>>          mmap_end = STACK_TOP_MAX;            \ >>>>>>> -    else if ((_addr) >= VA_USER_SV57) \ >>>>>>> -        mmap_end = STACK_TOP_MAX;            \ >>>>>>> -    else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= >>>>>>> VA_BITS_SV48)) \ >>>>>>> -        mmap_end = VA_USER_SV48;            \ >>>>>>>      else                            \ >>>>>>> -        mmap_end = VA_USER_SV39;            \ >>>>>>> +        mmap_end = (_addr + len);            \ >>>>>>>      mmap_end;                        \ >>>>>>>  }) >>>>>>> >>>>>>> @@ -39,17 +33,18 @@ >>>>>>>      typeof(addr) _addr = (addr);                \ >>>>>>>      typeof(base) _base = (base);                \ >>>>>>>      unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base);    \ >>>>>>> -    if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) && >>>>>>> is_compat_task())) \ >>>>>>> +    if ((_addr) == 0 ||                    \ >>>>>>> +        (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) ||    \ >>>>>>> +        ((_addr + len) > BIT(VA_BITS - >>>>>>> 1)))            \ >>>>>>>          mmap_base = (_base);                \ >>>>>>> -    else if (((_addr) >= VA_USER_SV57) && (VA_BITS >= >>>>>>> VA_BITS_SV57)) \ >>>>>>> -        mmap_base = VA_USER_SV57 - rnd_gap; \ >>>>>>> -    else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >= >>>>>>> VA_BITS_SV48)) \ >>>>>>> -        mmap_base = VA_USER_SV48 - rnd_gap; \ >>>>>>>      else                            \ >>>>>>> -        mmap_base = VA_USER_SV39 - rnd_gap; \ >>>>>>> +        mmap_base = (_addr + len) - rnd_gap; \ >>>>>>>      mmap_base;                        \ >>>>>>>  }) >>>>>>> >>>>>>> +#ifdef CONFIG_64BIT >>>>>>> +#define DEFAULT_MAP_WINDOW    (UL(1) << (MMAP_VA_BITS - 1)) >>>>>>> +#define STACK_TOP_MAX        TASK_SIZE_64 >>>>>>>  #else >>>>>>>  #define DEFAULT_MAP_WINDOW    TASK_SIZE >>>>>>>  #define STACK_TOP_MAX        TASK_SIZE >>>>>>>>> I have carefully tested your patch on qemu with sv57. A >>>>> bug that >>>>>> needs >>>>>> to be solved is that mmap with the same hint address without >>>>>> MAP_FIXED >>>>>> set will fail the second time. >>>>>>> Userspace code to reproduce the bug: >>>>>>> #include >>>>>> #include >>>>>> #include >>>>>>> void test(char *addr) { >>>>>>     char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE, >>>>>> MAP_ANONYMOUS >>>>>>> MAP_PRIVATE, -1, 0); >>>>>>     printf("hint %p got %p.\n", addr, res); >>>>>> } >>>>>>> int main (void) { >>>>>>     test(1<<30); >>>>>>     test(1<<30); >>>>>>     test(1<<30); >>>>>>     return 0; >>>>>> } >>>>>>> output: >>>>>>> hint 0x40000000 got 0x40000000. >>>>>> hint 0x40000000 got 0xffffffffffffffff. >>>>>> hint 0x40000000 got 0xffffffffffffffff. >>>>>>> output on x86: >>>>>>> hint 0x40000000 got 0x40000000. >>>>>> hint 0x40000000 got 0x7f9171363000. >>>>>> hint 0x40000000 got 0x7f9171362000. >>>>>>> It may need to implement a special arch_get_unmapped_area and >>>>>> arch_get_unmapped_area_topdown function. >>>>>> >>>>> This is because hint address < rnd_gap. I have tried to let mmap_base = >>>>> min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it >>>>> does not work for bottom-up while ulimit -s is unlimited. You said this >>>>> behavior is expected from patch v2 review. However it brings a new >>>>> regression even on sv39 systems. >>>>> >>>>> I still don't know the reason why use addr+len as the upper-bound. I >>>>> think solution like x86/arm64/powerpc provide two address space switch >>>>> based on whether hint address above the default map window is enough. >>>>> >>>> Yep this is expected. It is up to the maintainers to decide. >>> Sorry I forgot to reply to this, I had a buffer sitting around somewhere >>> but I must have lost it. >>> >>> I think Charlie's approach is the right way to go.  Putting my userspace >>> hat on, I'd much rather have my allocations fail rather than silently >>> ignore the hint when there's memory pressure. >>> >>> If there's some real use case that needs these low hints to be silently >>> ignored under VA pressure then we can try and figure something out that >>> makes those applications work. >> I could confirm that this patch has broken chromium's partition allocator on >> riscv64. The minimal reproduction I use is chromium-mmap.c: >> >> #include >> #include >> >> int main() { >>     void* expected = (void*)0x400000000; >>     void* addr = mmap(expected, 17179869184, PROT_NONE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); >>     if (addr != expected) { > It is not valid to assume that the address returned by mmap will be the > hint address. If the hint address is not available, mmap will return a > different address. Oh, sorry I didn't make it clear what is the expected behavior. The printf here is solely for debugging purpose and I don't mean that chromium expect it will get the hint address. The expected behavior is that both the two mmap calls will succeed. >>         printf("Not expected address: %p != %p\n", addr, expected); >>     } >>     expected = (void*)0x3fffff000; >>     addr = mmap(expected, 17179873280, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, >> -1, 0); >>     if (addr != expected) { >>         printf("Not expected address: %p != %p\n", addr, expected); >>     } >>     return 0; >> } >> >> The second mmap fails with ENOMEM. Manually reverting this commit fixes the >> issue for me. So I think it's clearly a regression and breaks userspace. >> > The issue here is that overlapping memory is being requested. This > second mmap will never be able to provide an address at 0x3fffff000 with > a size of 0x400001000 since mmap just provided an address at 0x400000000 > with a size of 0x400000000. > > Before this patch, this request causes mmap to return a completely > arbitrary value. There is no reason to use a hint address in this manner > because the hint can never be respected. Since an arbitrary address is > desired, a hint of zero should be used. > > This patch causes the behavior to be more deterministic. Instead of > providing an arbitrary address, it causes the address to be less than or > equal to the hint address. This allows for applications to make > assumptions about the returned address. About the overlap, of course the partition allocator's request for overlapped vma seems unreasonable. But I still don't quite understand why mmap cannot use an address higher than the hint address. The hint address, after all, is a hint, not a requirement. Quoting the man page: > If another mapping already exists there, the kernel picks > a new address that may or may not depend on the hint. The > address of the new mapping is returned as the result of the call. So for casual programmers that only reads man page but not architecture specific kernel documentation, the current behavior of mmap on riscv64 failing on overlapped address ranges are quite surprising IMO. And quoting the man page again about the errno: >       ENOMEM No memory is available. > >       ENOMEM The process's maximum number of mappings would have been >              exceeded.  This error can also occur for munmap(), when >              unmapping a region in the middle of an existing mapping, >              since this results in two smaller mappings on either side >              of the region being unmapped. > >       ENOMEM (since Linux 4.7) The process's RLIMIT_DATA limit, >              described in getrlimit(2), would have been exceeded. > >       ENOMEM We don't like addr, because it exceeds the virtual address >              space of the CPU. > There's no matching description for the ENOMEM returned here. I would suggest removing "because it exceeds the virtual address space of the CPU." from the last item if the ENOMEM behavior here is expected. > This code is unfortunately relying on the previously mostly undefined > behavior of the hint address in mmap. Although I haven't read the code of chromium's partition allocator to judge whether it should be improved or fixed for riscv64, I do know that the kernel "don't break userspace" and "never EVER blame the user programs". > The goal of this patch is to help > developers have more consistent mmap behavior, but maybe it is necessary > to hide this behavior behind an mmap flag. Thank you for helping to shape a more consistent mmap behavior. I think this should be fixed ASAP either by allowing the hint address to be ignored (as suggested by the Linux man page), or hide this behavior behind an mmap flag as you said. > - Charlie > >> See alsohttps://github.com/riscv-forks/electron/issues/4 >> >>>> - Charlie >> Sincerely, >> Levi >> --------------mwugVDVVD20kUkyXDmG0E6Hq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2024-08-20 01:00, Charlie Jenkins wrote:
On Mon, Aug 19, 2024 at 01:55:57PM +0800, Levi Zim wrote:

On 2024-03-22 22:06, Palmer Dabbelt wrote:

On Thu, 01 Feb 2024 18:28:06 PST (-0800), Charlie Jenkins wrote:

On Wed, Jan 31, 2024 at 11:59:43PM +0800, Yangyu Chen wrote:

On Wed, 2024-01-31 at 22:41 +0800, Yangyu Chen wrote:

On Tue, 2024-01-30 at 17:07 -0800, Charlie Jenkins wrote:

On riscv it is guaranteed that the address returned by mmap is less
than
the hint address. Allow mmap to return an address all the way up to
addr, if provided, rather than just up to the lower address space.

This provides a performance benefit as well, allowing

mmap to exit

after
checking that the address is in range rather than searching for a
valid
address.

It is possible to provide an address that uses at most the same

number
of bits, however it is significantly more computationally expensive
to
provide that number rather than setting the max to be the hint
address.
There is the instruction clz/clzw in Zbb that returns the highest
set
bit
which could be used to performantly implement this, but it would
still
be slower than the current implementation. At worst case, half of
the
address would not be able to be allocated when a hint address is
provided.

Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>

---
 arch/riscv/include/asm/processor.h | 27 +++++++++++---------------
-
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/arch/riscv/include/asm/processor.h

b/arch/riscv/include/asm/processor.h
index f19f861cda54..8ece7a8f0e18 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -14,22 +14,16 @@

 #include <asm/ptrace.h>

-#ifdef CONFIG_64BIT
-#define DEFAULT_MAP_WINDOW    (UL(1) << (MMAP_VA_BITS - 1))
-#define STACK_TOP_MAX        TASK_SIZE_64
-
 #define arch_get_mmap_end(addr, len, flags)            \
 ({                                \
     unsigned long
mmap_end;                    \
     typeof(addr) _addr = (addr);                \
-    if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
is_compat_task())) \
+    if ((_addr) == 0 ||                    \
+        (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) ||    \
+        ((_addr + len) > BIT(VA_BITS -
1)))            \
         mmap_end = STACK_TOP_MAX;            \
-    else if ((_addr) >= VA_USER_SV57) \
-        mmap_end = STACK_TOP_MAX;            \
-    else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
VA_BITS_SV48)) \
-        mmap_end = VA_USER_SV48;            \
     else                            \
-        mmap_end = VA_USER_SV39;            \
+        mmap_end = (_addr + len);            \
     mmap_end;                        \
 })

@@ -39,17 +33,18 @@
     typeof(addr) _addr = (addr);                \
     typeof(base) _base = (base);                \
     unsigned long rnd_gap = DEFAULT_MAP_WINDOW - (_base);    \
-    if ((_addr) == 0 || (IS_ENABLED(CONFIG_COMPAT) &&
is_compat_task())) \
+    if ((_addr) == 0 ||                    \
+        (IS_ENABLED(CONFIG_COMPAT) && is_compat_task()) ||    \
+        ((_addr + len) > BIT(VA_BITS -
1)))            \
         mmap_base = (_base);                \
-    else if (((_addr) >= VA_USER_SV57) && (VA_BITS >=
VA_BITS_SV57)) \
-        mmap_base = VA_USER_SV57 - rnd_gap; \
-    else if ((((_addr) >= VA_USER_SV48)) && (VA_BITS >=
VA_BITS_SV48)) \
-        mmap_base = VA_USER_SV48 - rnd_gap; \
     else                            \
-        mmap_base = VA_USER_SV39 - rnd_gap; \
+        mmap_base = (_addr + len) - rnd_gap; \
     mmap_base;                        \
 })

+#ifdef CONFIG_64BIT
+#define DEFAULT_MAP_WINDOW    (UL(1) << (MMAP_VA_BITS - 1))
+#define STACK_TOP_MAX        TASK_SIZE_64
 #else
 #define DEFAULT_MAP_WINDOW    TASK_SIZE
 #define STACK_TOP_MAX        TASK_SIZE

I have carefully tested your patch on qemu with sv57. A

bug that

needs
to be solved is that mmap with the same hint address without
MAP_FIXED
set will fail the second time.

Userspace code to reproduce the bug:
#include <sys/mman.h>

#include <stdio.h>
#include <stdint.h>

void test(char *addr) {

    char *res = mmap(addr, 4096, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS

MAP_PRIVATE, -1, 0);

    printf("hint %p got %p.\n", addr, res);
}

int main (void) {

    test(1<<30);
    test(1<<30);
    test(1<<30);
    return 0;
}

output:
hint 0x40000000 got 0x40000000.

hint 0x40000000 got 0xffffffffffffffff.
hint 0x40000000 got 0xffffffffffffffff.

output on x86:
hint 0x40000000 got 0x40000000.

hint 0x40000000 got 0x7f9171363000.
hint 0x40000000 got 0x7f9171362000.

It may need to implement a special arch_get_unmapped_area and

arch_get_unmapped_area_topdown function.


This is because hint address < rnd_gap. I have tried to let mmap_base =
min((_addr + len), (base) + TASK_SIZE - DEFAULT_MAP_WINDOW). However it
does not work for bottom-up while ulimit -s is unlimited. You said this
behavior is expected from patch v2 review. However it brings a new
regression even on sv39 systems.

I still don't know the reason why use addr+len as the upper-bound. I
think solution like x86/arm64/powerpc provide two address space switch
based on whether hint address above the default map window is enough.


Yep this is expected. It is up to the maintainers to decide.

Sorry I forgot to reply to this, I had a buffer sitting around somewhere
but I must have lost it.

I think Charlie's approach is the right way to go.  Putting my userspace
hat on, I'd much rather have my allocations fail rather than silently
ignore the hint when there's memory pressure.

If there's some real use case that needs these low hints to be silently
ignored under VA pressure then we can try and figure something out that
makes those applications work.

I could confirm that this patch has broken chromium's partition allocator on
riscv64. The minimal reproduction I use is chromium-mmap.c:

#include <stdio.h>
#include <sys/mman.h>

int main() {
    void* expected = (void*)0x400000000;
    void* addr = mmap(expected, 17179869184, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    if (addr != expected) {

It is not valid to assume that the address returned by mmap will be the
hint address. If the hint address is not available, mmap will return a
different address.

Oh, sorry I didn't make it clear what is the expected behavior.
The printf here is solely for debugging purpose and I don't mean that
chromium expect it will get the hint address. The expected behavior is that
both the two mmap calls will succeed.


      

        
        printf("Not expected address: %p != %p\n", addr, expected);
    }
    expected = (void*)0x3fffff000;
    addr = mmap(expected, 17179873280, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0);
    if (addr != expected) {
        printf("Not expected address: %p != %p\n", addr, expected);
    }
    return 0;
}

The second mmap fails with ENOMEM. Manually reverting this commit fixes the
issue for me. So I think it's clearly a regression and breaks userspace.



      

      
The issue here is that overlapping memory is being requested. This
second mmap will never be able to provide an address at 0x3fffff000 with
a size of 0x400001000 since mmap just provided an address at 0x400000000
with a size of 0x400000000.

Before this patch, this request causes mmap to return a completely
arbitrary value. There is no reason to use a hint address in this manner
because the hint can never be respected. Since an arbitrary address is
desired, a hint of zero should be used.

This patch causes the behavior to be more deterministic. Instead of
providing an arbitrary address, it causes the address to be less than or
equal to the hint address. This allows for applications to make
assumptions about the returned address.


    

    
About the overlap, of course the partition allocator's request
      for overlapped vma seems unreasonable.

    

    
But I still don't quite understand why mmap cannot use an address
      higher than the hint address.

      The hint address, after all, is a hint, not a requirement.

      

      Quoting the man page:

      

        
  If another mapping already exists there, the kernel picks
       a new address that may or may not depend on the hint.  The
       address of the new mapping is returned as the result of the call.

      

      So for casual programmers that only reads man page but not
      architecture specific kernel

      documentation, the current behavior of mmap on riscv64 failing on
      overlapped address ranges

      are quite surprising IMO. 

      

      And quoting the man page again about the errno:

      

      
      ENOMEM No
          memory is available.
          

          

                ENOMEM The process's maximum number of mappings would
          have been
          

                       exceeded.  This error can also occur for
          munmap(), when
          

                       unmapping a region in the middle of an existing
          mapping,
          

                       since this results in two smaller mappings on
          either side
          

                       of the region being unmapped.
          

        
        

                ENOMEM (since Linux 4.7) The process's RLIMIT_DATA
          limit,
          

                       described in getrlimit(2), would have been
          exceeded.
          

        
        

                ENOMEM We don't like addr, because it exceeds the
          virtual address
          

                       space of the CPU.

        

        

      

      There's no matching description for the ENOMEM returned here.

      I would suggest removing "because it
        exceeds the virtual address 

        space of the CPU." from the last item if the ENOMEM
      behavior here

      is expected.

      

      
    

    

      
This code is unfortunately relying on the previously mostly undefined
behavior of the hint address in mmap. 

    

    Although I haven't read the code of chromium's partition allocator
    to judge whether it should

    be improved or fixed for riscv64, I do know that the kernel "don't
    break userspace" and 

    "never EVER blame the user programs".

    

      
The goal of this patch is to help
developers have more consistent mmap behavior, but maybe it is necessary
to hide this behavior behind an mmap flag.


    

    Thank you for helping to shape a more consistent mmap behavior.

    I think this should be fixed ASAP either by allowing the hint
    address to be ignored

    (as suggested by the Linux man page), or hide this behavior behind
    an mmap flag as you said.

    

    

      
- Charlie



      

        
See also https://github.com/riscv-forks/electron/issues/4



        

          

            
- Charlie


          

        

        
Sincerely,
Levi



      

    

  


--------------mwugVDVVD20kUkyXDmG0E6Hq--