From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CWXP265CU010.outbound.protection.outlook.com (mail-ukwestazon11022083.outbound.protection.outlook.com [52.101.101.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D182338925; Fri, 30 Jan 2026 15:48:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.101.83 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769788113; cv=fail; b=ZeUo82N96RNgZqCEWj7ZUaZWmQH3OsnjPJ86HMB/HFjuUK8VxlgGO8EjWx3wJnaURaQtDJqwxkUVAYBV0e/TqK4DS2m/vdo32MyzOoyzYUWb55PJMMFlujpG8lJv06NAHvBJZpKbBMwCaApXWCsAU3ETALC+oMzvVEQSh7oBuWw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769788113; c=relaxed/simple; bh=BAGEbPB2Pn/jSTTSE8N1Y4GzLDdtAKTQOJ7uOaDPvrQ=; h=Content-Type:Date:Message-Id:To:Cc:Subject:From:References: In-Reply-To:MIME-Version; b=RuO2rr+TSIk88x4F4N0EUCDp1Y/TRMKAEvb7cHJttRC/2FdHNn9NbYnHqvFZQsRB/bQPwJGN5Yi7+nn21EynygibV4oluwXaBHrWt9MQnPUav/gWn3QdCyFgBYzeEB8vBjoWZpRZp1JgHVWbQTwD0hLuL+GVwoqnQAEOXcoeDB0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=garyguo.net; spf=pass smtp.mailfrom=garyguo.net; dkim=pass (1024-bit key) header.d=garyguo.net header.i=@garyguo.net header.b=hU/Bz5g6; arc=fail smtp.client-ip=52.101.101.83 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=garyguo.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=garyguo.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=garyguo.net header.i=@garyguo.net header.b="hU/Bz5g6" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AGcjmXkE8T9Y+mnGAuj98yEfQjDti/sFLw9pEAxp13/CCY5RS+GuKVChIJ1HwKhpHp8geqMA9QwCaqnQum/H08lAz6HCB/QQ/2RCDJMvtrzQkRROHDsWeiJ9J2pTAsOsq88fOkC4Ybe8c1Hfv94dlhNi/HDU+LRiT36X9myrqxkLuqy1nXyzXv0NAzpSvc1bbymP3ihLiiBfFmLtU4qbKivrqJFrQ5w26CL1KoOSfYbS6fRERBt8waIZ8fONVOc+sebykCYlPLAZqBThRLEo2dHOqoY8vyvwIgYbaeIdUr24Mcc5XNIOlSTa2nuJdXgOR80CypPW54IDWyhpxDK6UA== 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=kXH+Kz2NwfGJv8R6ERCguaViescrMMJDuxq1CNUPrp4=; b=ho3qgeGBAxFABZ4g03ngPwhn+H2MYI6CthBQ4jnis9R0GPglCI1MBv8fmqJrWdM67ZCR4RFZFEEXHWXgwSWmgmYZx+r9uAa/Cjn+W6ISzGHss9l53Mz+U0dqkG7qRVKwK2ruqVAtkf3yTs/ey0Hp0kivviTUXB3YKUY066MOmYPEx81yUMyPd/JssD7c/amZN0Go/iSHoNyzbQAh0oK0QMdB1nhsu07UyvMuWmcYpsn9sp7RbLh+6M2rqqCGyBcyZEL9LBqqAohQ7/taNyqm4CozsHoMWTG8N0h/V/phGAgfJz6lX/p2lWy5yQ0w3iYfEuYFQr4bkOH++xBmUYnK6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=garyguo.net; dmarc=pass action=none header.from=garyguo.net; dkim=pass header.d=garyguo.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=garyguo.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kXH+Kz2NwfGJv8R6ERCguaViescrMMJDuxq1CNUPrp4=; b=hU/Bz5g6QKc7RP67GkLTJUwsOVwUY0YHaLPFgW0EpqPH1Pi15qelRg7F/63ZSRtKW9Dt0gxc9yLbkdJsYrrDM21KzIoNjRM7oSNzddpHm4CsiHdJTK8IvLUjqfXuUKfqbciJBAUjyVAP/E5hxKH6zHHNWnTnh9td6NN5JjIIgfA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=garyguo.net; Received: from LOVP265MB8871.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:488::16) by LO2P265MB3545.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:1b4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.11; Fri, 30 Jan 2026 15:48:27 +0000 Received: from LOVP265MB8871.GBRP265.PROD.OUTLOOK.COM ([fe80::1c3:ceba:21b4:9986]) by LOVP265MB8871.GBRP265.PROD.OUTLOOK.COM ([fe80::1c3:ceba:21b4:9986%5]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 15:48:27 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 30 Jan 2026 15:48:26 +0000 Message-Id: To: "Andreas Hindborg" , "Gary Guo" , "Alice Ryhl" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Miguel Ojeda" , "Boqun Feng" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Trevor Gross" , "Danilo Krummrich" Cc: , , Subject: Re: [PATCH] rust: page: add volatile memory copy methods From: "Gary Guo" X-Mailer: aerc 0.21.0 References: <20260130-page-volatile-io-v1-1-19f3d3e8f265@kernel.org> <877bszrz37.fsf@t14s.mail-host-address-is-not-set> <874io3rwl3.fsf@t14s.mail-host-address-is-not-set> <871pj7ruok.fsf@t14s.mail-host-address-is-not-set> In-Reply-To: <871pj7ruok.fsf@t14s.mail-host-address-is-not-set> X-ClientProxiedBy: LO2P123CA0039.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::27) To LOVP265MB8871.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:488::16) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: LOVP265MB8871:EE_|LO2P265MB3545:EE_ X-MS-Office365-Filtering-Correlation-Id: c58c49f7-8ad6-4cc8-0bca-08de60170223 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|366016|376014|1800799024|921020|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SmV4VG5GZ0FFY00rbkpvK0hPbC8xNFJCd01STHFGditXakY2VjRLcjJBc1FW?= =?utf-8?B?UVBjR2w2TEx0T3prRXlKNGZDWFZqM011aWdGbHpvc2g0OWd6WGF1bE9VSUFX?= =?utf-8?B?NjE2cDQ3ZEoxK090R1A4RlJ1SUgrYitEOUMybFQrSWdaMWtHeG5mb2xlNkV0?= =?utf-8?B?VG9MRWdiTmJwUkRFd3l0a1lDT2NBWHVsajBzbUFRbTZrS1NHbStrVUw4bFRv?= =?utf-8?B?ODBucFNZU2ZvcVAyT091c1JqcjJYKzAyaTdnMlVoQnlUc3htelNucFpoT3pQ?= =?utf-8?B?YW1NMVErcE9yc1lmQlRvRG05enQzejF0VG9EWEYvVDFlUlR1SUFKZWVRSU84?= =?utf-8?B?bFFXdjhDUEVEWm5mYkk3NXVNeHNRM2lEMWdQV0gyRmQyR08zUE5wWnBJODNo?= =?utf-8?B?UEFIeVBqVDZuQWpveGE5c3lOQ3lWYXNJS29hWHlOY2F2Smc0WmovaGVRU01X?= =?utf-8?B?bzhlUGw5TXJNL3ovb3NuUmJUcTBVME10RmJrbTN5MWZwRWlqd1FZUUdiVDRv?= =?utf-8?B?aHcwMXZWczViWjZjaGg4bnh3bGxkTDlxdHphMkVEaTZKVGV1cGdZMTBzMTVX?= =?utf-8?B?ZzBTVDIwaGJnMXQwWHJNVmZneHF0Q0RvOWdLalpoNE96bStrL2pKUUJYckps?= =?utf-8?B?ZnRjMDlhZVhYL1RwNjhEbldjVkxVQ0l0YlRFSmNPdno1clVYeXVhSy9CWm5E?= =?utf-8?B?MTBVNFAxVTFlNndPamRWMElJZExJNW5PbnUyeWZsQlRoeXBWR3Y3cExvcmhm?= =?utf-8?B?SXhIclk1QmlGU21yTEtTWEdUTGtKWmtXOG4xSzB2S1oySWlxMG1qSTZjSzBq?= =?utf-8?B?dEVZMXZLczE1QXc3c1pETVEyY3ZGYWRrL1hEM1Q3Mk9VK2FPeEJmeCtmS2Fs?= =?utf-8?B?S09RU29oTE4ySXJNWm9CL0xvREx4aTA1YVpBUlRKaDNtbFpJT2MzSDJjODh3?= =?utf-8?B?K2Eya01nVldDZnZvVGZsemliMENLK3QwSUhZVG5OREViT2FYRnhHUmlVSXlk?= =?utf-8?B?aksrZ0E4ZllkUUdmR09oRHUwVHVwVk1pM2x1VU1sUkVQMFZBVzZHdWNxODRO?= =?utf-8?B?V1psT3N6cDdndjdCWGNQd3JXTkJ3aGdkenk5aWlTdlFTbk0vV0x6b2JnTy85?= =?utf-8?B?T3ZmQWdDN01KTmJveThMTU5rTG1yaWp3bElhM1JZS1FxTUhWYmNGQjA4aWI5?= =?utf-8?B?amJTK1Fpd3M1ZjZsMUdrZkhCeThEUGFnWE5QQTd5aXUveHhhTWtpTVdML2RM?= =?utf-8?B?bXpNUERwSFpSNkUzclNMQVdKTTRPQkxrQWVIMHMydkdJcUJZakZsM05uM3p1?= =?utf-8?B?VGtlWnZScU8yb0lnM0VTTGFlb2kvMzNqbnBYU3V1SW5QNW9aSko1dnJQbk5R?= =?utf-8?B?RHI3SWxNQlp3V09PSjRtRytYdkZwZGd2Ukp0TXpsVDFmMzNFM3BPeTY3Vmgy?= =?utf-8?B?a2haeFVFYncvL1hEY1F6Y0p6di9XNVhlOTE2dDVndHBpa0N0Q2gwQ0NkVUV5?= =?utf-8?B?S2dKVWIxREJnNDdSbm5OeFZXRElHeGFBdTMxeWw4M056T01vanJ3VzF3VWxm?= =?utf-8?B?NFFhU2dnaFBhT3A3Qkx0bWZtd0h3SXBkWWJPSkdsejJXZXVCZ3BoSmlBVEdy?= =?utf-8?B?bW82RG4xMlZrSUxlb1pmUkw1M09VYUNMNDBJMm9XYjdGcGsxTVRPanF3QXEv?= =?utf-8?B?UTZOeTBPS3g3dHhBMGVlcDNvaWI4bHd0YWN4YTBITFg2bC9nelg0akN0d2R1?= =?utf-8?B?Z0Z5MFZBOUhYY1NMZlZKem10VlErYm9zR2hwOW5xenhsZ01RV0J6T3A2WXV5?= =?utf-8?B?RUE4Z1dQYnRhNjU0ejFoZmlWOHNsclpibmhMNGNHTFNQeFowOGkvWC9GK1lW?= =?utf-8?B?YThLL05pb3ZHR0syZklydHJEc3NxZzNHeXZDb2Joc0w1dkpITngzQWVOQjNx?= =?utf-8?B?b1h5ZC9COHhneVBvTDRIM3NyQm8wQWxVWisxQkJ6Nmx6Ni83Z1l1bkxEUkwx?= =?utf-8?B?SFpMdnY4dXJxcmFOcnIxdHR4T1U2NTQya1JPZllyL3RSRnp6MS9YRmhKaFlE?= =?utf-8?B?cEhqbUptVlFzZ2V6eDhJWUJoUW1KTkswT1Y2OU92WlFuNWJKaXFhSW1LcnV1?= =?utf-8?B?VXd4TnNQOE9aOVV3dkxRdThuSzF4Q3FZTUhQUitpYTlLeTBzRllBUm5VNjBX?= =?utf-8?B?TVE9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LOVP265MB8871.GBRP265.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(7416014)(366016)(376014)(1800799024)(921020)(7053199007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dUx3SmdhMjV2dVllT3lqa0lSTFhPYVRicTgwNU5mZnFPMGhIZ211OTlkOWtU?= =?utf-8?B?WTNsbElkUHpoZ3FzVFpCSldaMTZJR2tGN2JWMHZnakpsRFlSOUdHd3BJeVp1?= =?utf-8?B?U0t5Q2pxWTlYVGpEYWVqY3lob3psVklpb1cxYXVSRXljS0NmMGhpWUV6QlhI?= =?utf-8?B?enZ2dTRZa2NZUmVvdVRZbWJuYmY5bnFPSTNka1RNM013YkJUQ1ZPdlQ2N2tl?= =?utf-8?B?Ty9KVzBsNEx0VnRIcHdRaFlnMTJlWi90RDlJT0lBUkx5T3A5T0h1bGFuV3dw?= =?utf-8?B?MFZiRXJ1N2R2WXo3N3cxQmJRODhRbVhXbjhrYm9tYi9zZWlIU1MzWERXZXVH?= =?utf-8?B?S2F6ckVxNldTajhMQ0g3Y1hGajdwT24rM1dJYUFKVFVuS3c5UnVOakVwRC8y?= =?utf-8?B?YkEzV1ZZS1AxUHF5My9HWHA5ZXJOemhaRHVyVXRLUmRVWmVMM09aVk1aeVFl?= =?utf-8?B?Z2pLQTFuanF6QzFsT3RnbGVHY2JMc29rYjBPeDArd0NJY2pIbVBhSVdMbTJy?= =?utf-8?B?ci9ibjBmb3VNU3JvZ3g2eFNnNVAzZ1NOc0pZR2w4Y1lFWnR3eVZPQ0p6czV5?= =?utf-8?B?VWFTOExjQ0JOMDFCOHVqU3huK0FHZk5JUXdER3J3MitZTFJUSE9OU3kzNXpv?= =?utf-8?B?ZWFya0hZVTNJNTAvRHpxbEYvTVB6Q1hXT2xYVG83MjZVMXBvS05XVlh6OFpF?= =?utf-8?B?Z29UZHE4OVRiMDhUd3Y0MUY2WkVNRjFDdnhtZGZWekpyaytYNTNkM1B5c3NN?= =?utf-8?B?L2hmSDU2ZjM4N0FoeEtidFQ0T3RjSXRtSFZnT29JT1NFV2wwSW0zNi9KRU9l?= =?utf-8?B?OGJLZFJXSGN4OTk0WVVJLzFEZGZweHVHbGMydklZT3FVMDFFWVprUU1uMU5J?= =?utf-8?B?UTRHNjhrYjJxVWx2N0hPN3RhMER5YTBGQUtFSUViOWhXdXpqaXFTTGdKMlZn?= =?utf-8?B?RzhBc1E5YzRteXRPekVLaExNeEViMk8wVzlKd3VZSnJJeTlpN3ByS2FEaTBM?= =?utf-8?B?cjdKT2doQytSRURIVk5PRllKeXFlMnRIQ2hVY0tQQWRGTG91dXVuRklLZjNa?= =?utf-8?B?ZGRHNWhqd1RHbEd5SHo0RnhvWTNwL3MrY3p3UEtyaUc3RGN6ZUNCRklUVDlw?= =?utf-8?B?ZDZ3aFdpY2w0YjhlMk9id3hOYlljV2hyN3ZLZUhyZkVpOEpONE0vUUttZDEy?= =?utf-8?B?L1lzQnVyeE5meEdlaEJ1cFZYN245SVBycjV2dVpqeDIyY2FCaThINnBCOVZy?= =?utf-8?B?MVhvbURQYlNaRm9Pd1RkajM4TFVKWjl3ekZtVlVFUFdNQ2RpYk1HMEtKM1dv?= =?utf-8?B?NXk1cEhhQVQrUXg1cXlySTRKMFJrazlYVk0rSDNTT3J5MGl6bldjV3NuSVFX?= =?utf-8?B?aGpHaEpZK3RpTDh0dFNrTjNkUk5CSVEwa3hKcG1rQkJYeW10a3k0eG8rZjVk?= =?utf-8?B?T2kzZEpKS0FwRk44RXZUMnNRUTdsRVFWL2dyQUtxNkdkOXRuQ0IwZDRRTGt0?= =?utf-8?B?Y3lCZDJicXRiWko0anI1dnQxelEwcHdQR2E3alViMTlIbFNxYlY5WUo4bGZi?= =?utf-8?B?Ky9FYS8zM09HdEZxQk5YSHBxeWwrTWxjQkxiSHNyZGpSY2JQT29VZGV6L3VD?= =?utf-8?B?QkYxYTdrcjUxSlozL2wvZ3hxNTl5MDJ1TW51elZyaTg1aTU2cXNpTGYyN1BE?= =?utf-8?B?SW5WN2JkWFdmMFY4SC9ERFdGdXhzM3YrWWVDQ1RHMnQwTC9ZYW9LbTFEZUQ2?= =?utf-8?B?MTRqWmVSOTBNcnN2K3JnM1c4MURSNldqV0E3YTdSSDlvVW5kQzdwNTNhWmNS?= =?utf-8?B?WG9acHpSWnh5OTBoL3h0Tk1SMjF0aXplK2hCWnFJWDI0WFJxWDRYclFCa21K?= =?utf-8?B?MVRYV05LeVBRcmZSNDVUVjErUEd0dTlBN1VSSTY5TUVGM3NpQlpWSEkzejBa?= =?utf-8?B?VnI5WWRZMHYyTU5iNWJ4V3VvKzdLTE8vcTlIT1pSQVJad3d6TWJzaFVtcFlL?= =?utf-8?B?S1QvWDhRK202T1Qxd1Z2eUJycHpuU1JHS0FUVktvSGgzaDBaK0FsNkFFQmFG?= =?utf-8?B?dGlKNGdXMC84dGF0TDlxcWlITHVuNGEvWFgzU1Nwa0F4YWlNc01jekphUVY3?= =?utf-8?B?dWN6VEk5cGdrUmJFL1hWV29Rektva2dBc2d1ZmhxZndwY1dYMnYyWG0zb3R1?= =?utf-8?B?cFBQczlEVVpjQmFPeGZHeDdQS2NQN2FvbzQrRWhCZGYvSWNsSHdpM2Jha2tV?= =?utf-8?B?QmVGNHBDUVBkVkZnQnJCNm95SkJvOEhuaHhiUXphNURBRmdPczhkSjB0aXRp?= =?utf-8?Q?y0XUHCj/uvRE1c04Hs?= X-OriginatorOrg: garyguo.net X-MS-Exchange-CrossTenant-Network-Message-Id: c58c49f7-8ad6-4cc8-0bca-08de60170223 X-MS-Exchange-CrossTenant-AuthSource: LOVP265MB8871.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 15:48:27.0477 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bbc898ad-b10f-4e10-8552-d9377b823d45 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ji7xhCs78WJwSrTio+pRcCXsjAR65zg0CdiZjSf3ikBL3F372PEKK+i5SbNvmlZ++DjvpjncN51aZ/9KZPjQdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3545 On Fri Jan 30, 2026 at 3:23 PM GMT, Andreas Hindborg wrote: > "Gary Guo" writes: > >> On Fri Jan 30, 2026 at 2:42 PM GMT, Andreas Hindborg wrote: >>> "Gary Guo" writes: >>> >>>> On Fri Jan 30, 2026 at 1:48 PM GMT, Andreas Hindborg wrote: >>>>> "Gary Guo" writes: >>>>> >>>>>> On Fri Jan 30, 2026 at 12:33 PM GMT, Andreas Hindborg wrote: >>>>>>> When copying data from buffers that are mapped to user space, or fr= om >>>>>>> buffers that are used for dma, it is impossible to guarantee absenc= e of >>>>>>> concurrent memory operations on those buffers. Copying data to/from= `Page` >>>>>>> from/to these buffers would be undefined behavior if regular memcpy >>>>>>> operations are used. >>>>>>> >>>>>>> The operation can be made well defined, if the buffers that potenti= ally >>>>>>> observe racy operations can be said to exist outside of any Rust >>>>>>> allocation. For this to be true, the kernel must only interact with= the >>>>>>> buffers using raw volatile reads and writes. >>>>>>> >>>>>>> Add methods on `Page` to read and write the contents using volatile >>>>>>> operations. >>>>>>> >>>>>>> Also improve clarity by specifying additional requirements on >>>>>>> `read_raw`/`write_raw` methods regarding concurrent operations on i= nvolved >>>>>>> buffers. >>>>>>> >>>>>>> Signed-off-by: Andreas Hindborg >>>>>>> --- >>>>>>> rust/kernel/page.rs | 53 +++++++++++++++++++++++++++++++++++++++++= ++++++++++++ >>>>>>> 1 file changed, 53 insertions(+) >>>>>>> >>>>>>> diff --git a/rust/kernel/page.rs b/rust/kernel/page.rs >>>>>>> index 432fc0297d4a8..6568a0d3b3baa 100644 >>>>>>> --- a/rust/kernel/page.rs >>>>>>> +++ b/rust/kernel/page.rs >>>>>>> @@ -7,6 +7,7 @@ >>>>>>> bindings, >>>>>>> error::code::*, >>>>>>> error::Result, >>>>>>> + ffi::c_void, >>>>>>> uaccess::UserSliceReader, >>>>>>> }; >>>>>>> use core::{ >>>>>>> @@ -260,6 +261,8 @@ fn with_pointer_into_page( >>>>>>> /// # Safety >>>>>>> /// >>>>>>> /// * Callers must ensure that `dst` is valid for writing `len= ` bytes. >>>>>>> + /// * Callers must ensure that there are no other concurrent r= eads or writes to/from the >>>>>>> + /// destination memory region. >>>>>>> /// * Callers must ensure that this call does not race with a = write to the same page that >>>>>>> /// overlaps with this read. >>>>>>> pub unsafe fn read_raw(&self, dst: *mut u8, offset: usize, len= : usize) -> Result { >>>>>>> @@ -274,6 +277,30 @@ pub unsafe fn read_raw(&self, dst: *mut u8, of= fset: usize, len: usize) -> Result >>>>>>> }) >>>>>>> } >>>>>>> >>>>>>> + /// Maps the page and reads from it into the given IO memory r= egion using volatile memory >>>>>>> + /// operations. >>>>>>> + /// >>>>>>> + /// This method will perform bounds checks on the page offset.= If `offset .. offset+len` goes >>>>>>> + /// outside of the page, then this call returns [`EINVAL`]. >>>>>>> + /// >>>>>>> + /// # Safety >>>>>>> + /// Callers must ensure that: >>>>>>> + /// >>>>>>> + /// * The destination memory region is outside of any Rust mem= ory allocation. >>>>>>> + /// * The destination memory region is writable. >>>>>>> + /// * This call does not race with a write to the same source = page that overlaps with this read. >>>>>>> + pub unsafe fn read_raw_toio(&self, dst: *mut u8, offset: usize= , len: usize) -> Result { >>>>>>> + self.with_pointer_into_page(offset, len, move |src| { >>>>>>> + // SAFETY: If `with_pointer_into_page` calls into this= closure, then >>>>>>> + // it has performed a bounds check and guarantees that= `src` is >>>>>>> + // valid for `len` bytes. >>>>>>> + // >>>>>>> + // There caller guarantees that there is no data race = at the source. >>>>>>> + unsafe { bindings::memcpy_toio(dst.cast::(), s= rc.cast::(), len) }; >>>>>> >>>>>> I feel that this should be a generic utility that integrates with ou= r IO infra >>>>>> that allows you to copy/from IO to a slice. >>>>> >>>>> While that might also be useful, for my particular use case I am copy= ing >>>>> between two pages. One is mapped from user space, the other one is >>>>> allocated by a driver. No slices involved. Pasting for reference [1]: >>>> >>>> Then what you need is a byte-wise atomic memcpy, not memcpy_{from,to}i= o. >>> >>> Can you elaborate on how you get to this requirement? >> >> Memory that is possibly mapped into userspace is still normal memory, it= is not >> I/O. I/O accessors (and IO memcpy) are specifically used for MMIO, and y= ou >> should not be using them for userspace memory. >> >> For memory that can be mutated from userspace you can just treat them as= a >> potentially concurrent accessor hence all accesses should be using atomi= c. When >> tearing is acceptable, byte-wise atomic is sufficient. > > I would treat them the same as DMA regions and MMIO regions. As these > regions are outside of any Rust allocation, if we never make references > to them and if we only operate on them with volatile operations, > behavior of the copy operations like these are defined, as far as I > understand. I don't find the argument about these being outside Rust allocation very us= eful. Apart from MMIO, I view all other types of memory still within purview of t= he abstract machine. > > In the last discussions we had on this, the conclusion was to use > `volatile_copy_memory` whenever that is available, or write a volatile > copy function in assembly. > > Using memcpy_{from,to}io is the latter solution. These functions are > simply volatile memcpy implemented in assembly. > > There is nothing special about MMIO. These functions are name as they > are because they are useful for MMIO. No. MMIO are really special. A few architectures require them to be accesse= d completely differently compared to normal memory. We also have things like INDIRECT_IOMEM. memory_{from,to}io are special as they use MMIO accessor su= ch as readb to perform access on the __iomem pointer. They should not be mixed wi= th normal memory. They must be treated as if they're from a completely separat= e address space. Normal memory vs DMA vs MMIO are all distinct, and this is demonstrated by = the different types of barriers needed to order things correctly for each type = of memory region. Userspace-mapped memory (that is also mapped in the kernel space, not __use= r) is the least special one out of these. They could practically share all atomic= infra available for the kernel, hence the suggestion of using byte-wise atomic me= mcpy. Best, Gary > > > Best regards, > Andreas Hindborg